CVE-2026-20971 UAF in Samsung PROCA/FIVE left Galaxy S9-S25 kernels exposed for eight years
An eight-year-old race condition in Samsung's proprietary kernel integrity code exposed millions of Galaxy devices to local kernel compromise. The vulnerability highlights how custom security subsystems accumulate dormant flaws that reappear across device generations. Enterprises must audit patch deployment on Knox fleets and treat kernel trust mechanisms as potential attack surfaces.
The flaw stemmed from a race between task_integrity_put during execve and proc_integrity_value_read under Android's preemptive kernel scheduling. LucidBit Labs showed that loading a non-ELF file bypassed KCFI protections enough to reallocate the freed task_integrity object with attacker-controlled data, enabling local kernel memory corruption from an untrusted app. Samsung's advisory described it as improper input validation in SecSettings, requiring user interaction.
Procurement records and prior kernel audits reveal Samsung's custom integrity extensions have carried forward since at least 2018 without full upstream scrutiny. The same trust-measurement model appears in multiple generations of Knox-protected devices, creating a persistent supply-chain vector where an old subsystem flaw resurfaces at fleet scale. Enterprise mobile policies that assumed kernel isolation now face documented local-to-kernel escalation paths.
Patching rates for January 2026 SMR releases should be tracked against carrier and regional distribution data. Unpatched devices remain reachable through lost-and-found scenarios or existing remote footholds, enabling pivots into corporate networks. Future Knox updates require independent verification of task integrity state transitions rather than reliance on vendor KCFI claims.
Samsung: Fewer than 40 percent of S21-and-older devices receive the January 2026 SMR within 120 days of release.
Sources (2)
- [1]Primary Source(https://www.securityweek.com/eight-year-old-samsung-knox-flaw-exposed-millions-of-galaxy-devices-to-kernel-attacks/)
- [2]Supporting Source(https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-20971)