Infinity Core Proves the Quiet Parts of the Kernel Aren’t Safe

The Short Version

Jump to the Long Version ↓

What it is: Infinity Core is the name Hyunwoo Kim (@v4bel) gave to six bugs in core kernel code, covering POSIX CPU timers, signal delivery, the page table walker, futexes, scheduler cache accounting and the SLUB allocator. Kim posted the details and exploit code to oss-security on October 16, 2026, as soon as the linux-distros embargo ran out. Jump to this section →

Impact: Five of the six come with a public proof of concept that starts from an ordinary unprivileged account and finishes with a root shell. Kim also classes the same five as container escapes. The sixth, in SLUB, only panics the kernel so far. Jump to this section →

Severity: Scores don’t tell this story well. Amazon Linux rates the timer and signal bugs 7.0 under CVSS 3.1 and the MM bug 6.3, all with a local vector and high attack complexity. Those ratings went out before working root exploits were public. Jump to this section →

Who is affected: Ubuntu 26.04 takes the hardest hit. The root exploits for the timer, signal, MM and futex bugs were written and tested on its 7.0.0-30-generic kernel, and TuxCare’s kernel team has reproduced root with all four on Ubuntu 26.04 as well. The timer bug also reaches EL9 and EL10 kernels, Debian 12 and 13, and Ubuntu 24.04, where TuxCare’s testing has produced crashes but not root – not yet, anyway. The scheduler and SLUB bugs only exist in 7.2 and later. Jump to this section →

Status: Upstream fixes exist for all six, and four of the CVE records were already public between September 4 and October 6. Distro kernels are catching up unevenly. Debian, for one, already has fixed security kernels out for both bookworm and trixie, and Red Hat fixed the futex bug for RHEL 9 back on October 1. There’s no report of exploitation in the wild. These are n-days with public exploits, not zero-days.

Do this now: There’s no known sysctl or module to switch off. Get fixed kernels onto Ubuntu 26.04 hosts first, starting with any that run code from people you don’t fully trust, like shared hosting servers, CI runners and multi-tenant container hosts. Where your distro already ships a fix, install it and plan the reboot. Disabling unprivileged user namespaces won’t help, since none of these bugs needs one. To see which kernel is actually running:

uname -r

Compare that against your vendor’s advisory, not against upstream version numbers. Distro kernels backport fixes without bumping the base version.

Jump to this section →

A lot of the kernel privilege escalations that make the news come out of the same few neighborhoods. Networking. Sockets. BPF. perf. Bugs that need an unprivileged user namespace to reach. Hardening guides have spent years teaching admins to fence those off, and plenty of shops did exactly that.

Infinity Core walks around all of it. Kim deliberately left those areas out and went looking in code every process runs without a second thought, such as exec(), signal handling, mincore() and futexes. What came back was four root exploits on a stock Ubuntu 26.04 install, one more on Arch Linux, and no known sysctl or module switch that makes them go away.

The fixes are already upstream. What a lot of hosts are missing is a running kernel that has them.

What Landed on October 16

Kim reported the bugs privately, worked them through the linux-distros list and published once the embargo expired on October 16, 2026. The oss-security post and the InfinityCore repository carry per-bug writeups and the exploit code. This isn’t Kim’s first appearance on this blog, either. The same researcher found Januscape and Zapscape, the KVM escapes from earlier this year.

Four of the six already had public CVE records before disclosure day. The kernel CNA published the futex CVE on September 4, the MM CVE on September 11, and the timer and signal CVEs on October 6. Each one went out under the kind of dry, commit-style title common to kernel CVEs, with nothing in it to suggest a root exploit was coming. A CVE that reads like a cleanup patch is easy to park until the next maintenance window. The same CVE with a root exploit sitting on GitHub isn’t.

One piece is still held back. Kim says the timer bug also gives full root on a Samsung Galaxy S26 Ultra starting from an ordinary app, and that exploit stays private until Samsung ships a fix or somebody else publishes one first.

The timer and signal bugs share a trigger, and it’s an odd one. When a thread that isn’t the process leader calls exec() and gets far enough along, the kernel swaps thread IDs so the calling thread takes over as the new leader. Both bugs live in the cleanup around that swap.

CVE-2026-98260, the timer bug, needs a per-thread POSIX CPU timer armed on that thread. If exec() then fails after the ID exchange, the timer gets freed while its node is still queued on a task that’s alive, and later cleanup walks right into that freed node. Classic use-after-free. The public exploit turns it into a root shell on Ubuntu 26.04, and the fix, acb03d388181, moves timer cleanup to immediately after de_thread() so nothing is left dangling when exec() bails.

CVE-2026-98256, the signal bug, is a race over the same moment. One path flushes the dying leader’s pending signals without taking a lock, while another follows the swapped PID and links a sigqueue entry into the new leader’s queue. Corrupt the links and an entry outlives the object it belongs to. Kim’s exploit uses that leftover entry as an oracle to tell when the freed memory has been reused, then abuses the path that dequeues the crafted signal to get a root shell. The fix is d2710c8d938a.

Programs fail exec() all day long. A bad path, a missing interpreter, a signal at the wrong moment. Neither bug fires on just any of those, though. The timer bug needs the failure to land after the thread ID swap, and the signal bug needs an attacker to win a race around that same swap. From the outside, an attempt still looks like ordinary process churn, which is why there’s no clean way to filter it out short of patching.

CVE-2026-89754 sits in the page table walker. During a race with madvise(MADV_DONTNEED), a retry flag from a lower level leaks upward, and mincore() walks the same range twice. By then its output cursor has already moved on, so the second pass writes past a temporary buffer that’s exactly one page long. Kim’s exploit parks a credential slab in the next physical page and uses the overflow to zero the UID and GID fields of a struct cred. Kernel LPE doesn’t get much more direct than that. The fix is aedf2efd1897.

CVE-2026-80775, the futex bug, needs two tasks sharing one mm_struct, which nested vfork() provides once the middle child gets killed. Both race to install the first reference counter for the private futex hash. Only one store survives, so the references taken against the other counter stop being tracked, and a hash that’s still in use gets freed. The exploit reclaims it with a pipe ring and overwrites the page cache of /usr/bin/passwd. That changes what the kernel serves for the file without writing the change to disk, so the tampering may be gone once the cached page is dropped or the host reboots. Good luck investigating that afterward. The fix is bde023808364.

The last two matter less for most fleets. CVE-2026-98385 is a use-after-free in scheduler cache accounting that needs CONFIG_SCHED_CACHE=y in the build, scheduler cache accounting switched on at runtime, and a CPU topology with more than one last-level cache. Its exploit got root on Arch Linux with a 7.2.4 kernel. CVE-2026-97941 is an ABA race in SLUB object refill that corrupts a partial list. Its public trigger just panics the kernel, and no root exploit has been published for it. Both live in code that first arrived in 7.2, so no distribution kernel that KernelCare supports carries either of them.

NVD scoring was still pending for the timer and signal bugs at the time of writing. Amazon Linux has published scores for three of them, giving 7.0 to the timer and signal bugs with the vector AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H, and 6.3 to the MM bug.

The AC:H part deserves a squint. Most of these are races, and “it’s a race” used to be a fair reason to push something down the queue. A public exploit that has already done the hard work of winning the race changes the math. A 7.0 with a working root shell attached, on a host where untrusted users can run code, deserves a spot near the top of the list. That says more about urgency than the number does.

Who Should Worry First

Every one of these starts from a plain local account, with no capabilities, no user namespace and no special device access. So the real question is who can run code on your hosts that you don’t fully control.

Shared hosting servers with customer SSH or control panel shells are the obvious answer. CI runners that build arbitrary pull requests are another. So is any host running containers for tenants who don’t trust each other. Kim classes all five root bugs as container escapes, and that tracks. Every container shares the host kernel, and the syscalls involved are everyday ones that container workloads use constantly. Unless a seccomp profile or LSM policy happens to block the exact path, don’t count on the container boundary to save you.

A single-purpose database server with three admins on it is a different story. It still needs the fix. It just isn’t first in line.

Is Infinity Core a Zero Day?

No. Every fix was upstream before the exploits went public, and the earliest CVE record predates disclosure by about six weeks. There’s no report of exploitation in the wild. These are n-days with public exploits, and that can put defenders in an even worse position. The clock is now set by how fast distros ship fixed kernels and how fast admins actually boot into them.

Exposure of KernelCare-supported distributions as of October 19, 2026, from TuxCare’s own analysis and separate from each vendor’s kernel status:

“Crash so far” needs a caveat. A working root exploit on one kernel build is a big head start toward the next one, even if adapting it still takes real effort. Root hasn’t been shown on those distributions, but local privilege escalation is a credible risk there, and patching priority should reflect that.

As mentioned up top, a version string by itself settles nothing here. Only a vendor advisory or a verified patch for that exact kernel does.

Get KernelCare today →

Why There’s No Quick Mitigation

For a lot of recent kernel LPEs, the stopgap was a one-liner. Blacklist a module, flip a sysctl, shut off unprivileged user namespaces. None of that works this time. Kim left out bugs that need a user namespace on purpose, and the rest sit in exec(), signal handling, mincore() and futex code that no working system can unload or turn off. TuxCare hasn’t identified a reliable workaround. The usual moves, like disabling unprivileged user namespaces or blacklisting a module, don’t touch the vulnerable code paths, and no separate workaround has been verified for each bug.

That leaves the less satisfying options. Cut down who has a local shell on exposed hosts until they’re patched. Move tenants who truly don’t trust each other into separate VMs instead of containers on a shared kernel. And keep an eye on the kernel log. Several of these are races, and a failed attempt can oops or panic the kernel rather than fail quietly, though a clean log doesn’t prove nothing happened:

journalctl -k | grep -iE 'BUG:|Oops|general protection'

An unexplained oops on a multi-user host this week is worth a closer look.

The permanent fix is a kernel carrying the upstream patches, from your distribution or your own build. Installing the package doesn’t touch the kernel already running in memory, so until the host boots into the new one, nothing has changed. Check what’s actually running:

uname -r

A host that installed a fixed kernel and never rebooted is still running the vulnerable one. Shared hosting servers and CI pools tend to be the worst offenders, because rebooting them means warning customers or draining jobs.

Once released for your kernel, KernelCare rebootless patches apply the fix to the running kernel without that reboot. Where automatic updates are enabled, a patch gets picked up on the next scheduled check once it’s in the feed for the running kernel, and kcarectl --update requests it on demand. To check coverage for the four bugs that affect supported distro kernels:

kcarectl --patch-info | grep -E 'CVE-2026-(98260|98256|89754|80775)'

The scheduler and SLUB CVEs are left out of that pattern on purpose, since no supported distro kernel carries them. As of October 19, 2026, the only Infinity Core patch released is the futex fix for an AlmaLinux 9 kernel stream. Nothing has shipped yet for the timer bug on any distribution, or for the four bugs on Ubuntu 26.04. Check this post for updates in the coming days. Once a patch reaches your stream, confirm KernelCare has actually applied it to the running kernel, and keep access tight until coverage for the relevant CVEs is verified.

Why Infinity Core Matters

Hardening by subtraction has a ceiling. Admins have gotten good at stripping out attack surface they don’t need, and that work pays off. But nobody gets to remove exec(). Kim went hunting in subsystems with a quiet security track record and came back with six bugs. Mature, heavily used code isn’t the same thing as safe code, and hardening alone won’t close that gap.

If you run Ubuntu 26.04 with untrusted local users, that’s the first patching job this week. On EL, Debian and Ubuntu 24.04 hosts, give the timer bug real priority even though testing has only produced crashes there so far, since the public Ubuntu exploit makes root a credible next step. And when a reboot means draining a CI pool or emailing a few hundred hosting customers, KernelCare rebootless patches are meant to close these bugs in the running kernel as coverage arrives, without the maintenance window.

Get KernelCare today →

Timeline

References

Kim’s Infinity Core post on oss-security (October 16, 2026), the InfinityCore repository with exploit code and per-bug writeups, the CVE records for CVE-2026-98260, CVE-2026-98256, CVE-2026-89754, CVE-2026-80775, CVE-2026-98385 and CVE-2026-97941, the full set of upstream fix commits listed in Kim’s repository, including the timer fix acb03d388181 and the futex fix bde023808364, the Debian security tracker entry for CVE-2026-98260, Red Hat’s RHSA-2026:74438, and Amazon Linux’s scoring for CVE-2026-98260, CVE-2026-98256 and CVE-2026-89754.