Researcher Hyunwoo Kim has published full details and working proof-of-concept exploits for six Linux kernel vulnerabilities he calls Infinity Core. Five of the six lead to local privilege escalation and container escape, taking an unprivileged account to a root shell, and the sixth crashes the kernel. The release appeared shortly before October 19; the source does not give an exact date.
Six Memory-Safety Bugs Across Timers, Signals, Futex and the Scheduler
Kim reported the flaws under embargo to the linux-distros list and then posted the details to oss-security and GitHub. The affected kernel areas are timers, signals, memory management, futex, the scheduler and the SLAB allocator. All six are memory-safety flaws arising from races or edge cases.
Kim tested the exploits on Ubuntu 26.04 running kernel 7.0.0-30-generic and on Arch Linux running 7.2.4-arch1-2. He also tested the timer flaw on a Samsung Galaxy S26 Ultra running Android.
Hardening That Does Not Block Infinity Core
The research excludes networking, BPF and user-namespace-dependent bugs. That choice means common hardening steps, such as restricting user namespaces or BPF, do not block these flaws. Any local user, or any code running inside a container, can reach them.
On shared hosts, that reach matters: a single compromised container could become a takeover of the host. An attacker needs local code execution first, so these are not remotely exploitable by themselves. They are the second stage of an attack, used after an initial foothold.
Samsung Galaxy S26 Ultra Root From an App Sandbox
Kim says the timer flaw gives full root on a Samsung Galaxy S26 Ultra from a normal app sandbox. He withheld that Android exploit until Samsung patches the device, publishing only a hash of it. Publishing a hash lets him later prove the exploit existed at the time of disclosure without handing attackers a working tool.
Why the Withheld Android Exploit Matters for Patch Timing
Upstream fixes already exist in stable kernels, so Linux distributions can ship patched builds. Android vendors depend on their own update pipelines, and the timer flaw’s reach from an ordinary app sandbox makes the gap between upstream fix and device update the period of greatest exposure.
Exposure, Fixes and Priorities for Defenders
No exploitation in the wild has been reported, and none of the six flaws appear in CISA’s Known Exploited Vulnerabilities catalog. Upstream fixes exist in stable kernels, and the kernel’s CVE records list the fixed stable releases. The immediate task is to install patched kernels.
The highest exposure sits in three environments: containers, multi-tenant systems and Android builds that lag upstream. In each, an attacker or malicious tenant already has the local code execution the exploits require.
Prioritizing Container Hosts and Shared Infrastructure
For operators, the public availability of working exploits shortens the time between disclosure and potential abuse. Anyone who can run code on a host, including a customer workload in a shared cluster, has a ready-made route to root. Teams running container platforms should identify which nodes run kernels without the stable fixes and schedule those updates ahead of single-tenant machines, where the attacker would need a separate foothold.
Because mitigations like disabling user namespaces do not help, patching is the only reliable control named in the research. Security teams should also confirm with vendors whether their kernel builds include the fixes, since distribution kernels often carry backported patches under version numbers that differ from upstream stable releases.
Kim’s disclosure sequence, an embargoed report to linux-distros followed by public release on oss-security and GitHub, gave distributions time to prepare fixes before the exploits appeared. The one deliberate omission, the Samsung exploit, shows that disclosure timing for Android depends on a separate vendor. Until Samsung ships a patch, the Galaxy S26 Ultra timer flaw remains the item defenders cannot test against publicly available code.
