Experts found a nasty kernel flaw in Samsung’s KNOX stack, and the uncomfortable part is where it lived: inside the software designed to raise the bar for attackers. CVE-2026-20971 is a use-after-free in the interaction between PROCA and FIVE, two kernel-side subsystems that help Samsung validate process integrity.
The bug sits in a race. FIVE tracks a process through a task_integrity object, and when a process changes state, such as by forking or calling execve(), the old integrity object gets dropped and a new one takes its place. That handoff should be clean, but Android’s preemptive kernel gives an attacker just enough breathing room to hit the gap. One thread can read a pointer, get suspended, and then come back to use memory that’s already been freed.
That’s the core problem LucidBit Labs describes:
The target task executes execve(), specifically task_integrity_put(old_tint), freeing the original struct. The next step is just as bad: “proc_integrity_value_read() resumes and calls task_integrity_user_read() with a pointer to freed memory.
“While relatively straightforward, the race window is tiny – the process running proc_integrity_value_read() needs to be scheduled out just at the right time (within a window consisting of a couple of opcodes), and be scheduled out for long enough to gain control of the memory.” states the report published by Lucidbit Labs
Once that happens, the bug is no longer a theory. It’s a live UAF with a real corruption path.
Samsung’s KCFI helps, but it doesn’t save the day. It narrows the abuse surface by blocking arbitrary function calls, which is good news, but not enough to kill the flaw. The researchers still found a route by making the process load a file that can’t be executed, a non-ELF file, which removes the reset_file refcount blocker. From there, reallocate the freed memory in a fully controlled manner. That’s the kind of sentence that makes kernel engineers reach for coffee.
This wasn’t an academic stunt. LucidBit Labs says the issue could be triggered from an untrusted app and could lead to kernel memory corruption, which is exactly the sort of foothold attackers love.
“The vulnerability could be exploited from any untrusted app, and allowed attackers to obtain multiple memory corruption primitives, potentially leading to complete device takeover.” continues the report.
Samsung fixed it in the January 2026 update, and the affected range is broad: Galaxy S9 through Galaxy S25, plus A-series devices and both Exynos- and Qualcomm-based models across Android 13, 14, 15, and 16.
Samsung’s own advisory frames the issue as improper input validation in SecSettings before SMR Jan-2026 Release 1, and it notes that local access plus user interaction are required. That sounds less scary until you remember how often “local” really means “one careless tap away” on a device people trust with everything. Lost phones, borrowed phones, unattended phones, sold phones that weren’t fully wiped. The attack surface gets bigger fast.
The more interesting lesson is broader than one Samsung bug. Security controls don’t get a free pass just because they’re labeled defensive. If they sit in the kernel, inspect process state, or mediate trust decisions, they’re part of the attack surface too. Defenders don’t get to assume the guardrail can’t be used as a handhold. That assumption gets expensive.
This case also fits a pattern enterprise defenders know too well. A flaw that starts as a mobile kernel issue can still matter to the business if a staff device is compromised and the attacker uses it as a launch point into the network. Mobile endpoints are always on, usually trusted, and often less watched than laptops. That’s a bad combo. The punchline is simple: patch fast, and don’t treat security tooling as if it’s automatically safe just because it’s called security.
“Modified code, especially one related to complex mechanisms, is always an interesting area to look for vulnerabilities in. FIVE is a part of the Samsung KNOX security suite, and as we saw, protections can increase the attack surface.” concludes the report. “This research also demonstrated common difficulties related to kernel exploitation of race conditions – short race windows combined with the need to reallocate freed memory in a different cache. It also shows how kernel CFI was a highly effective mitigation in this case, practically blocking an arbitrary call primitive. In spite of that, other powerful primitives did exist.”
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, CVE-2026-20971)
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。