Samsung KNOX Had a Kernel-Level Security Flaw for 8 Years

Ahmethan Gültekin · Jun 24, 2026 · Newsletter · 5 min read

Samsung markets KNOX as one of the most robust mobile security platforms in the industry. Built into Galaxy devices at the hardware and kernel level, it’s the reason enterprises trust Samsung phones with sensitive data. So when a security research firm quietly discovers that a critical flaw has been sitting inside KNOX for roughly eight years, undetected, it raises some uncomfortable questions.

That’s exactly what happened. LucidBit, a security research outfit, recently disclosed a use-after-free (UAF) vulnerability buried deep within KNOX’s kernel subsystem. Samsung patched it in January 2026, but the bug had reportedly been there since around 2017.

What Is a Use-After-Free Vulnerability?

Before diving into the specifics, a quick primer: a use-after-free flaw occurs when a program continues to reference a block of memory after that memory has been freed and potentially reassigned. In kernel-level code, this is particularly dangerous. The attacker can potentially control what ends up in that reclaimed memory slot, turning a subtle programming oversight into a full device compromise.

Where Was the Bug Hiding?

The vulnerability lived inside a KNOX component called PROCA (Process Authenticator). PROCA’s job is to verify that only trusted processes run on the device, acting as a gatekeeper for process execution integrity.

At the center of the issue is a sub-component called FIVE (File-based Integrity Verification Engine), which sits on top of Linux’s native integrity measurement architecture and tracks the trust state of running processes at the kernel level.

Every process on a Samsung device carries an object called task_integrity, which records its trust status. The problem? Certain entries under /proc/pid/integrity/ were fetching raw pointers to this object without properly holding a reference to it first. This is a dangerous pattern in a fully preemptive kernel where timing windows matter enormously.

Which Devices Were Affected?

The scope here is significant. Researchers confirmed the flaw across Samsung Galaxy S9 through S25, including A-series devices like the A54. Both Exynos and Qualcomm chipset variants were vulnerable, and every Android version tested was affected.

Given that FIVE was introduced into Samsung’s kernel around 2017, the vulnerability appears to have shipped in every KNOX-enabled device since then, sitting dormant inside a security-critical subsystem for nearly a decade.

What Could an Attacker Actually Do?

LucidBit documented three distinct exploitation paths that stem from the UAF condition.

1. Memory Leak (DWORD Read)

The proc_integrity_value_read() handler reads task_integrity->user_value from offset 0 of what may already be freed memory. If an attacker times this correctly, they can extract data from that reclaimed memory region. In practice, this works as a KASLR bypass, a technique attackers use to defeat address space randomization and figure out where kernel code lives in memory. Crucially, this can be done without crashing the device, making it a stealthy first step in a larger attack chain.

2. Arbitrary Call (Blocked by CFI)

The proc_integrity_reset_file() handler eventually triggers a d_dname() function pointer call through a freed struct file. Researchers found a way to exploit this using /system/bin/monkey, a plain-text non-ELF system binary, to force the file’s reference count down to 1 and trigger the UAF condition. However, Android’s Kernel Control Flow Integrity (KCFI) stepped in here. It restricts which functions can be called through a pointer, limiting what an attacker could redirect execution to. This path turned out to be a dead end under modern Android hardening.

3. Constrained Write via Spinlock

The proc_integrity_label_read() handler acquires a spinlock_t on the freed object. When that memory gets reclaimed, the spinlock’s atomic operations produce a constrained write at offset 0x0c. Depending on what object ends up in that slot, this could corrupt pointers, reference counts, or length fields, all of which are useful primitives for further exploitation.

Why Did It Take So Long to Find?

This is the question worth sitting with. FIVE is vendor-modified kernel code, meaning it’s not part of the upstream Linux kernel that thousands of developers and security researchers scrutinize daily. Samsung-specific modifications live in a narrower review bubble, and complex object lifetime management in kernel code is notoriously hard to audit.

The /proc/ interface that exposed this bug isn’t flashy or obvious. It’s a mundane-looking procfs handler that happens to operate on objects with tricky ownership semantics. These kinds of issues don’t usually show up in automated scanning; they require deep, manual kernel analysis.

Is It Fixed? What Should You Do?

Samsung issued a patch in the January 2026 monthly Android security update. If your Galaxy device is running a security patch level of 2026-01-01 or later, you’re covered.

To check: go to Settings > About Phone > Android Security Update and verify the patch date.

If your device hasn’t received the January 2026 update yet, or if you’re on an older device no longer receiving security updates, you should be aware that this vulnerability exists and consider your risk exposure accordingly.

The Bigger Picture

There’s a broader lesson here that extends beyond this specific bug. Security features are code, and code has bugs. The very subsystem designed to enforce process integrity on Samsung devices turned out to be an attack surface in its own right, and one that went unnoticed for the better part of a decade.

It’s a reminder that security architecture and secure implementation are two different things. A well-designed system can still carry dangerous flaws in its execution, especially when the implementation lives outside the reach of the broader open-source security community.

Vendor-specific kernel modifications deserve the same level of scrutiny as the upstream code they’re built on. Incidents like this one make the case for more transparent, externally auditable security subsystems in mobile platforms.

Source: LucidBit Labs disclosure, Samsung January 2026 Security Update

Written by

Ahmethan Gültekin

Security researcher at ByteriaLab.

All posts →

Advanced Mobile App Shielding

Protect your mobile applications with industry-leading obfuscation, RASP, and integrity verification.