Samsung has patched a serious flaw in Knox, its built-in security framework for Galaxy devices. The bug, tracked as CVE-2026-20971, lived in a Knox-related kernel component called PROCA and could allow a local attacker to corrupt kernel memory or potentially execute code.
That alone would be enough to make it worth patching. The worse part is the age of the bug. Researchers say the vulnerable logic may have been present for years, affecting devices from the Galaxy S9 generation up to newer Galaxy S25 models, along with some Galaxy A-series phones.
Samsung fixed the issue in its January 2026 security update. Anyone using an affected Galaxy device should check that their Android security patch level is January 2026 or newer.
This is not a normal app bug. It sits much lower, close to the Android kernel. That matters because the kernel is where Android enforces many of the boundaries that keep apps boxed in. A bug at that level can become useful to attackers after they already have some kind of foothold on the phone.
What happened?
CVE-2026-20971 is a use-after-free vulnerability in Samsung’s PROCA driver.
PROCA stands for Process Authenticator. It is part of Samsung’s Knox security stack and helps verify whether a process running on the device should be trusted. Samsung describes the issue as a local vulnerability that could potentially allow arbitrary code execution before the January 2026 Security Maintenance Release.
The bug affected Samsung Android devices running Android 13, Android 14, Android 15, and Android 16 before the fix. Reports linked the issue to several Galaxy generations, including Galaxy S9 to Galaxy S25, A-series devices, and both Exynos and Qualcomm variants.
That is a wide blast radius. It also shows how long vendor-specific Android kernel code can remain in circulation. A bug can survive model changes, chipset changes, Android version changes, and years of monthly patch cycles if the vulnerable code path does not get the right kind of review.
What’s Samsung Knox
Samsung Knox is not just Secure Folder, although that is where many users first see the name.
Knox is Samsung’s security platform for Galaxy devices. It covers hardware-backed security, secure boot, device integrity checks, enterprise controls, encryption, app separation, device management, and policy enforcement.
For regular users, Knox helps protect private data, app storage, credentials, and secure areas on the phone. For businesses, it is much more central. Companies use Knox to manage employee phones, enforce work profiles, push policies, restrict risky settings, lock lost devices, and keep corporate data separate from personal data.
That is why this vulnerability is uncomfortable. The flaw was not in some abandoned utility app. It was in a security component that exists to help decide whether code should be trusted.
Security features reduce risk, but they are still software. When they sit close to the kernel, bugs inside them become high-value attack surface.
PROCA and FIVE, in plain English
The bug involves two Samsung security components: PROCA and FIVE.
PROCA is the Process Authenticator. Its job is to help decide whether a process should be allowed to run as trusted code.
FIVE is the File-based Integrity Verification Engine. It tracks integrity information for files and running processes. Think of it as a system that helps Knox keep track of whether something has changed and whether the process still matches the trust state Samsung expects.
For this to work, the kernel uses a structure called task_integrity. That object stores integrity-related information for a running process.
If a process changes, for example by executing a new file through execve(), the integrity state may need to change too. The old task_integrity object can be dropped and replaced with a new one.
That is normal. The bug appears when one kernel path keeps using the old object after it has already been freed.
What is a use-after-free bug?
A use-after-free bug happens when software releases a memory object but later continues to use it.
Imagine a hotel room. One guest checks out. The hotel gives the room to someone else. Then the old guest walks back in with a key that still works. They are now inside a room that no longer belongs to them.
In memory terms, the room is a memory slot. The first object is gone. The system may reuse that same memory for a different object. If old code still has a stale pointer to that memory, it may read or modify the wrong thing.
In user-space software, this can crash an app or leak data. In the kernel, it can be much worse. A kernel use-after-free can help an attacker leak memory addresses, bypass protections, corrupt kernel objects, escalate privileges, or build toward code execution.
Not every use-after-free leads to full compromise. Android has several defenses. But a use-after-free in a privileged Knox kernel component is not something to shrug off.
Where the race condition appears
The vulnerable path involved process integrity data exposed through procfs entries such as:
/proc/pid/integrity/
Procfs is a virtual filesystem that lets user-space tools read information from the kernel. In this case, Samsung had handlers that exposed integrity-related data for processes.
The issue was object lifetime.
One thread could read a pointer to a task_integrity object. Then the kernel could pause that thread. Another path could run, free the object, and reuse the memory. When the first thread resumed, it could continue using the stale pointer.
That is the race.
Android’s kernel is preemptive, which means this kind of scheduling interruption is normal. Kernel code must be written with that in mind. If the code reads a pointer without safely holding a reference, a tiny timing gap can turn into a use-after-free.
The gap may be tiny. Attackers like tiny gaps if they can hit them over and over.
Why exploitation was difficult
The vulnerability was real, but it was not a simple “open file, root phone” situation.
Modern Galaxy devices include kernel hardening. One of the relevant protections here is Kernel Control Flow Integrity, or KCFI. KCFI makes it harder for attackers to hijack kernel execution by corrupting function pointers.
Older kernel exploits often abused corrupted function pointers to redirect execution. KCFI restricts indirect calls so they must match expected function types. That does not fix the underlying memory bug, but it closes off some of the most direct exploitation routes.
The researchers still found useful primitives. Some leaked data. Some looked promising but were blocked. One gave a constrained write. That is the kind of messy middle ground kernel exploitation often lives in: not impossible, not easy, and very dependent on memory layout, timing, allocator behavior, and mitigations.
The three primitives researchers found
Researchers described three main primitives from the use-after-free condition. These do not form a copy-paste exploit by themselves, but they explain why the bug was more than a harmless crash.
Primitive 1: memory leak through proc_integrity_value_read()
The first primitive was a memory leak.
The handler proc_integrity_value_read() reads task_integrity->user_value at offset 0. If the task_integrity object is still valid, the handler returns the expected integrity value.
If the object has been freed and the same memory slot has already been reused, the handler may read whatever now sits at that address.
That turns the stale pointer into a DWORD read from reclaimed kernel memory.
A four-byte leak may sound small, but kernel exploit work often starts with small leaks. Even limited disclosure can help defeat KASLR, the kernel address randomization feature that tries to hide where important kernel memory lives.
The useful part here is that this leak could happen without immediately crashing the device. A quiet leak is often more useful than a noisy bug that panics the kernel every time.
Primitive 2: an arbitrary call path blocked by KCFI
The second primitive involved proc_integrity_reset_file().
That path could eventually reach a d_dname() function pointer call through a freed struct file. In a weaker kernel environment, a freed object leading into a function pointer call can be dangerous. If an attacker controls the reclaimed memory well enough, they may try to redirect execution.
Researchers found a way to make this path easier to reach by using /system/bin/monkey, a plain-text, non-ELF system binary. Because it is not a normal ELF executable, it changed the reset_file reference count behavior and helped remove a blocker that otherwise made this route harder to use.
This is where KCFI mattered.
Android’s Kernel Control Flow Integrity blocked arbitrary redirection. The attacker could not simply point the function call wherever they wanted. KCFI limited calls to type-compatible targets, which made this path much less useful.
So this primitive showed a possible control-flow route, but modern Android hardening cut off the dangerous version of it.
Primitive 3: constrained write through proc_integrity_label_read()
The third primitive came from proc_integrity_label_read().
That handler acquires a spinlock_t on the task_integrity object. A spinlock is a low-level kernel lock used to protect shared data.
If the object is valid, that is normal.
If the object has already been freed and reclaimed as something else, the spinlock operation can perform atomic writes on memory that now belongs to another kernel object. Researchers observed a constrained write at offset 0x0c.
This is not the same as an attacker getting full “write anything anywhere” control. It is limited. But limited writes can still matter in the kernel.
If that offset overlaps with a pointer, refcount, length field, flag, or other sensitive field in the reclaimed object, the kernel may behave in a way the attacker can use. This is especially interesting in cross-cache reclaim situations, where memory from one object type is reused for a different object type.
This is why use-after-free bugs are so annoying to defend against. The attacker is not always trying to control the old object. Sometimes the goal is to make the freed slot become a different object, then let normal kernel code damage it.
Why those primitives matter
The three primitives explain why CVE-2026-20971 deserved attention.
The first could leak kernel memory. The second showed a route toward a function pointer call, although KCFI blocked the obvious attack. The third gave a constrained write that could corrupt a reclaimed object.
That is the shape of many kernel exploit attempts: leak something, learn the layout, shape memory, then corrupt something useful.
Android’s mitigations made this harder. Good. That is what they are there for. But the bug still existed in a privileged Samsung security path, and researchers showed that it could produce meaningful exploitation building blocks.
What an attacker could do with it
Samsung described the bug as local. That means an attacker typically needs some access to the device first. It could be a malicious app, physical access, or another vulnerability that gets code running with limited privileges.
Once that local foothold exists, a kernel vulnerability becomes much more valuable.
A normal Android app is boxed in by permissions and sandboxing. A kernel exploit can try to move beyond that box. Depending on the exploit chain, an attacker may try to corrupt kernel memory, bypass integrity checks, escalate privileges, weaken security controls, or reach data that should not be available to a normal app.
For a personal phone, that can put private data, accounts, app sessions, and secure storage at risk.
For a company phone, the risk can spread. Employee phones often carry work email, SaaS sessions, MFA prompts, VPN profiles, corporate chats, and internal documents. A compromised mobile device can become a useful foothold for a larger intrusion.
That is why “local” does not mean “low risk.” It means the bug may be one step in a chain.
Why local bugs still matter
People often dismiss local vulnerabilities because they are not remote zero-click bugs. That is too simple.
Attackers chain bugs. A malicious app may start with limited permissions and then use a local kernel bug to climb higher. A stolen or briefly accessed phone may give an attacker enough time to try a local exploit. A compromised user account may lead to a mobile foothold, and a mobile foothold may lead to deeper device access.
This is especially true for Android kernel bugs. They are valuable because they can turn a weak starting point into something stronger.
CVE-2026-20971 is not the front door by itself. It is more like the locked stairwell inside the building. If someone already gets into the lobby, this kind of bug may help them reach floors they were never supposed to access.
Affected devices and versions
The vulnerability reportedly affected multiple Galaxy generations, including devices from the Galaxy S9 line through the Galaxy S25 line. Some Galaxy A-series devices were also affected, and reports mention both Exynos and Qualcomm/Snapdragon variants.
Samsung lists the affected Android versions as:
- Android 13
- Android 14
- Android 15
- Android 16
The fixed release is SMR Jan-2026 Release 1 or newer.
Because Samsung updates vary by model, carrier, region, and support window, users should check the patch level on the device itself instead of assuming they are protected.
Go to:
Settings → About phone → Software information → Android security patch level
If the phone shows January 2026 or later, it should include the fix. If it shows an older patch level, update it.
Do not confuse it with CVE-2026-20969
Samsung’s January 2026 advisory included multiple vulnerabilities, which has caused some confusion.
The Knox PROCA use-after-free is:
SVE-2025-2103 / CVE-2026-20971
A separate issue in the same monthly release is:
SVE-2025-1716 / CVE-2026-20969
That one involved improper input validation in SecSettings. It is not the Knox PROCA use-after-free discussed here.
For this article, the relevant bug is CVE-2026-20971.
The eight-year problem
The age of the bug may be the most worrying part.
If the researchers are right about the timeline, this flaw lived across several Samsung device generations. That means the same vulnerable security logic may have shipped again and again while the rest of the phone changed around it.
That can happen in vendor Android kernels. Device makers add their own drivers, security features, hardware hooks, and management logic on top of Android and Linux. Some of that code is proprietary. Some of it is highly privileged. Much of it does not get the same broad review as upstream Linux code.
Knox is meant to improve security. In many ways, it does. But the closer security code sits to the kernel, the more carefully it needs to be audited. A bug in a normal app is one thing. A bug in a kernel security component is different.
Defensive code can become attack surface. That is the lesson here.
What users should do
Samsung already patched CVE-2026-20971. The practical advice is simple: update the phone.
Go to:
Settings → Software update → Download and install
Then check:
Settings → About phone → Software information → Android security patch level
Users should also avoid random APKs, keep Google Play Protect enabled, remove apps they no longer use, and avoid sideloading apps from Telegram channels, file-sharing sites, forums, or “mod APK” pages.
If a phone no longer receives security updates, it should not be used for sensitive work. That is especially true for banking, work email, crypto wallets, admin dashboards, and MFA approval apps.
Final thoughts
CVE-2026-20971 does not mean Knox is useless. It means Knox is software, and software needs pressure testing.
The bug is fixed. That is good. But the research is still worth paying attention to because it shows how a security feature can carry its own risk when it lives deep in the kernel.
For users, the answer is patching.
For enterprises, it is patch verification.
For vendors, it is more aggressive review of proprietary kernel security code, especially code that tracks process integrity, exposes procfs handlers, or manages object lifetimes.
Samsung built Knox to make Galaxy devices harder to compromise. This bug shows how high the bar has to be when the protection layer itself runs with kernel-level power.
FAQ
What is CVE-2026-20971?
CVE-2026-20971 is a use-after-free vulnerability in Samsung’s PROCA driver, part of the Knox security framework. Samsung fixed it in the January 2026 security release.
What is Samsung Knox?
Samsung Knox is Samsung’s security platform for Galaxy devices. It includes hardware-backed security, secure boot, integrity checks, app isolation, encryption, enterprise controls, and mobile device management features.
What is PROCA?
PROCA stands for Process Authenticator. It is a Samsung kernel component that helps verify whether a process should be trusted.
What is FIVE?
FIVE stands for File-based Integrity Verification Engine. It tracks integrity information for files and processes on Samsung devices.
What is a use-after-free vulnerability?
A use-after-free bug happens when software keeps using memory after it has already been freed. In kernel code, this can lead to memory leaks, memory corruption, privilege escalation, or code execution.
Is this remotely exploitable?
Samsung describes the issue as local. An attacker would usually need code already running on the device, physical access, or another vulnerability in the chain.
Which devices were affected?
Reports link the issue to Galaxy S9 through Galaxy S25 generations, some A-series devices, and both Exynos and Qualcomm variants. Samsung lists affected Android versions as Android 13, 14, 15, and 16 before the January 2026 patch.
How do I check if my phone is patched?
Go to Settings → About phone → Software information → Android security patch level. January 2026 or later should include the fix.
Does this mean Knox is unsafe?
No. It means Knox, like any complex security system, can have bugs. The issue has been patched, but users and companies still need to verify that the patch is installed.
