Infinity Core: Six Linux Kernel Bugs Let Local Users Become Root, and Fixes Are Still Rolling Out

Security researcher Hyunwoo Kim has published "Infinity Core", a set of six Linux kernel vulnerabilities in some of the kernel's most central code: the timer, signal, memory management, futex, scheduler and SLAB allocator subsystems. Kim posted the report to the oss-security mailing list on October 16, 2026, once the embargo agreed with Linux distribution maintainers had expired. According to the report, five of the bugs let an unprivileged local user gain root, and they can also be used to escape containers. The sixth crashes the kernel.

All six require the ability to run code on the machine, so none can be exploited remotely on its own. That still matters a great deal for shared servers, CI runners, hosting platforms and container hosts, where untrusted code running as an ordinary user is part of normal life. Working proof-of-concept code is public: Kim's InfinityCore repository on GitHub describes exploits that open a root shell from an unprivileged account on a stock Ubuntu 26.04 kernel and on Arch Linux. As of October 16, none of the CVEs appear in CISA's Known Exploited Vulnerabilities catalog.

The widest-reaching bug is CVE-2026-98260, a use-after-free in POSIX CPU timer cleanup when a non-leader thread's exec() fails. It affects kernels from 5.7 onward. The kernel CNA rates it CVSS 7.8. Kim's write-up says the same bug can also be used to gain full root on a Samsung Galaxy S26 Ultra from an ordinary app, and that the Android exploit will be held back until Samsung ships a fix. The other bugs reach fewer kernels: CVE-2026-98256 (signal queue use-after-free) arrived in 6.15, CVE-2026-80775 (futex private hash) in 6.17, CVE-2026-89754 (an out-of-bounds write through mincore()) in 7.0, and CVE-2026-98385 and CVE-2026-97941 only in the 7.2 series. The scheduler bug is also only reachable when CONFIG_SCHED_CACHE is enabled, the feature is switched on at runtime, and the machine has more than one last-level cache. For the SLAB bug, the public trigger causes a kernel panic, and Kim notes that a privilege escalation chain has not been written yet, although the kernel CNA still scores it 7.8 as a memory corruption.

"Root (LPE)" means local privilege escalation to root, which the researcher says also enables container escape. Affected and fixed versions come from the kernel CNA's CVE records on CVE.org. Every bug is also fixed in the 7.3 release candidates.

Where the distributions stand

Status as checked on the morning of October 17, 2026 (Manila time):

• Debian: trixie is fixed in linux 6.12.113-1 (DSA-6568-1). Bookworm is only affected by CVE-2026-98260 and is still listed as vulnerable, including the 6.1.187-1 security kernel (Debian tracker). Debian marks the other five as not affecting either release.
• Ubuntu: CVE-2026-98260 is marked "needed" for 22.04 LTS, 24.04 LTS and 26.04 LTS, with no fixed package released yet (Ubuntu CVE page). CVE-2026-89754 and CVE-2026-80775 are "pending" for 26.04.
• Red Hat Enterprise Linux: Red Hat rates CVE-2026-98260 Important and lists RHEL 9 and RHEL 10 as affected. So far, fixes have shipped only for some Extended Update Support and SAP streams, such as RHEL 10.0 EUS (RHSA-2026:83707) and RHEL 9.6 EUS (RHSA-2026:83775) (Red Hat CVE page). CVE-2026-98256 and CVE-2026-80775 also affect RHEL 10. CVE-2026-80775 was fixed for RHEL 9 in RHSA-2026:74438.
• Fedora: kernel 7.2.10, stable for Fedora 43 and 44 since October 14, already includes every upstream fix, and 7.2.11 is now stable on Fedora 43, 44 and 45 (Bodhi).
• Proxmox VE 9: proxmox-kernel 7.0.14-20 moved to Ubuntu's 7.0.0-39.39 kernel source, which carries the mincore fix for CVE-2026-89754 and the futex fix for CVE-2026-80775 (Ubuntu changelog). The timer and signal fixes for CVE-2026-98260 and CVE-2026-98256 followed in 7.0.14-21, so 7.0.14-21 and later include all four (Proxmox changelog). The current build is 7.0.14-24. CVE-2026-98385 and CVE-2026-97941 only exist in 7.2 kernels and do not apply to Proxmox's 7.0 kernel.
• Proxmox VE 8: the latest proxmox-kernel-6.8 build, 6.8.12-43, dates from August 20, before the CVE-2026-98260 fix, so PVE 8 hosts remain exposed to that bug.

Are you affected?

• ☐ Run uname -r. If the running kernel is 5.7 or later and older than the fixed build for your distribution, you are exposed to at least CVE-2026-98260.
• ☐ On Debian, run apt policy linux-image-amd64; on Ubuntu, apt policy linux-image-generic. Compare the installed version with the fixed version on the Debian or Ubuntu tracker. Bookworm and current Ubuntu kernels have no fix yet.
• ☐ On RHEL, Rocky, AlmaLinux or Fedora, run rpm -q kernel. On Fedora, anything older than 7.2.10 needs updating. On RHEL, compare against the fixed kernel in the RHSA for your stream, if one exists yet.
• ☐ On Proxmox VE, run pveversion -v and look at the running kernel line. A 6.8 kernel (PVE 8) is exposed. On PVE 9, a 7.0 kernel older than 7.0.14-21 is missing fixes.
• ☐ If uname -r shows an older kernel than the newest one installed, the fix is on disk but not running yet. Reboot.
• ☐ On 7.2 kernels, run grep CONFIG_SCHED_CACHE /boot/config-$(uname -r). CONFIG_SCHED_CACHE=y means the scheduler bug, CVE-2026-98385, may be reachable. Kernels older than 7.2, including 7.0, are not affected by it or by CVE-2026-97941.
• ☐ If CONFIG_SCHED_CACHE=y is set, check whether scheduler cache is switched on at runtime. Kim's write-up says the bug is only reachable when the kernel's sysctl_sched_cache_user setting is nonzero and the CPU topology has more than one last-level cache. ls /proc/sys/kernel | grep sched_cache shows which scheduler cache controls your kernel exposes.
• ☐ Ask who can run code on the box: shell users you do not fully trust, CI jobs, shared hosting accounts, or containers (for example docker ps or pct list). Containers share the host kernel, so any of these makes the host a priority. Virtual machines run their own kernel, so patch each guest too.

What to do

Install your distribution's fixed kernel as soon as it is available and reboot, since a new kernel package does nothing until the machine boots into it. Neither the researcher nor the CVE records document a workaround. Kim's write-up says the collection deliberately excludes bugs that need user namespaces, so disabling unprivileged user namespaces will not block these. Where a fix has not landed yet, the practical step is to limit who can run code on exposed machines, and to put multi-tenant and container hosts at the front of the queue once patches arrive.

Sources: Hyunwoo Kim's oss-security report and InfinityCore repository, the kernel CNA's CVE records on CVE.org, the Debian security tracker, Ubuntu's CVE tracker, Red Hat's CVE pages, Fedora Bodhi, Proxmox's kernel changelogs, and CISA's KEV catalog.