Infinity Core Turns Six Kernel Bugs Into a Patch-Pipeline Test, and Five Days After the Exploit Code Ubuntu and Amazon Linux Still Had No Fix for the Timer Bug

On October 16, the researcher Hyunwoo Kim posted six Linux kernel bugs to the oss-security mailing list under the name Infinity Core and pointed to a GitHub repository for the technical write-ups. The post says the bugs sit in the timer, signal, memory-management, futex, scheduler and SLAB code and can be used for “Linux server LPE, container escape, and Android LPE”, where LPE means local privilege escalation: an unprivileged account becoming root. CloudLinux and TuxCare, two vendors that both sell kernel live patching, say public root exploits exist for five of the six; the sixth only crashes the kernel. TuxCare reported no exploitation in the wild as of October 19, and none of the six is in CISA’s Known Exploited Vulnerabilities catalog as of its October 21 release.

The calendar matters more than the name. On October 21 I read every CVE record, the kernel.org stable changelogs and the public trackers of Red Hat, Debian, Ubuntu and Amazon Linux. All six CVE records, and a stable-kernel fix for each bug, were public before the post: the first stable release carrying a fix came 13 to 50 days earlier. So the post did not reveal six unknown bugs. It gave attackers working exploit code for bugs that distribution pipelines were still turning into packages, and those pipelines run at different speeds. By October 21, Red Hat, Debian and CloudLinux had shipped a fix for the timer bug, the one that reaches the most kernels. Ubuntu and Amazon Linux had not released theirs, the newest releases of the upstream 5.10, 5.15 and 6.1 lines did not contain it, and KernelCare’s live patch for it was still in preparation.

This piece covers what was disclosed, the timeline, which kernels are exposed and why base version numbers mislead, where each vendor stood, why the severity ratings are no guide, and what the vendors say about mitigation. The statuses are a snapshot taken at about 20:10 UTC on October 21 and will have moved since.

The six bugs and where they sit

Kim’s post gives each bug a sentence or two; the table paraphrases them and adds the first affected kernel version and the stable releases that fixed each bug, taken from the CVE records published by the Linux kernel’s CVE numbering authority (CNA). I checked every fix release against the changelog files on kernel.org, and each one contains the fix commit’s subject line. The post’s own heading calls the last subsystem SLAB; its description, and CloudLinux’s, are of the SLUB allocator. The last column repeats the vendors’ claim about exploits; it is not something I tested.

The introducing commits are of very different ages. The timer bug traces to a commit made in March 2020, posix-cpu-timers: Store a reference to a pid not a task, and the CVE record lists 5.7 as the first affected version. The signal bug dates from February 2025, the futex bug from August 2025, and the memory-management, scheduler and SLUB bugs from March, April and May 2026. I took those dates from the commit metadata that GitHub serves for the kernel repository. In the researcher’s write-up the timer bug is also the only one listed for Android; TuxCare reports that Kim is holding back that exploit until Samsung ships a fix.

On exploit availability I am relying on the vendors. CloudLinux writes: “Public root exploits exist for the timer, signal, memory-management, and futex bugs on a newer Ubuntu release, and for the scheduler bug on a rolling-release distribution with kernel 7.2. The SLUB bug has only a public trigger that panics the kernel.” The write-up in the repository that Kim’s post points to lists Ubuntu 26.04 (kernel 7.0.0-30-generic) as the tested target for the timer, signal, memory-management and futex bugs, and Arch Linux (7.2.4) for the scheduler and SLAB bugs. I did not run any of the code, and I do not describe how it works.

A timeline that starts weeks before disclosure day

The kernel’s CVE process explains why every one of these bugs had a public record first. The kernel’s CVE documentation says that “assignment will only automatically happen after a fix is available and applied to a stable kernel tree”. The record therefore appears when the fix does, under a plain commit-style title. The table sets the dates side by side; the last two columns count days to the October 16 post.

Three things stand out. First, the exploit post came after the fix in every case, by 13 to 50 days counted from the first stable release that carried it and by 24 to 63 days counted from the mainline commit. Second, TuxCare’s analysis says four of the six CVE records were public before disclosure day. The records for the SLUB bug (September 25) and the scheduler bug (October 12) were also published before the post, so all six were. Third, the records are easy to overlook. The timer bug’s record, published on October 6, is titled “exec: Cleanup POSIX timers right after de_thread()”. TuxCare puts the problem well: “A CVE that reads like a cleanup patch is easy to park until the next maintenance window.” All six records name Linux 7.3 as the mainline release containing the fix, and kernel.org’s release list shows 7.3 shipping on October 18, two days after the post.

One small discrepancy shows how the story spread. Corgea’s write-up dates the disclosure October 17. The post’s header reads Sat, 17 Oct 2026 01:00:19 +0900, which is 16:00 UTC on Friday, October 16, and the Openwall archive files it under 10/16. CloudLinux and TuxCare both use October 16.

Which kernels the bugs reach, and why the base version misleads

What the version ranges predict

The first-affected versions explain why the exploits were written for the systems they were. Ubuntu 26.04 ships a 7.0 kernel, which falls inside the ranges of four bugs: timer from 5.7, signal from 6.15, futex from 6.17 and memory management from 7.0. Arch Linux’s 7.2 kernel falls inside the scheduler and SLUB ranges, which start at 7.2. Only the timer bug reaches the long-term lines that most enterprise and hosting distributions build on (5.10, 5.15, 6.1, 6.6 and 6.12); the other five need 6.15 or later according to their records.

Backports break the rule

Vendor kernels carry code from newer releases, so the version number on the box says little. Red Hat’s tracker shows it. RHEL 10 ships a 6.12-based kernel, yet RHSA-2026:85321 fixes the signal bug that upstream says starts in 6.15, and the tracker still lists RHEL 10 as affected by the futex bug that starts in 6.17. RHEL 9 is built on 5.14, and Red Hat issued RHSA-2026:74438 on October 1 to fix that same futex bug in it. CloudLinux makes the same point about its own kernels: “The futex bug is present in the CloudLinux 9 and 10 kernels but already fixed there”. Its advice is to “do not judge exposure from the base kernel number.”

The older long-term lines

The CVE record lists fixed stable releases for 6.6, 6.12, 6.18 and 7.2 only. I scanned the kernel.org changelogs of the ten most recent releases of each of the 5.10, 5.15 and 6.1 lines. The newest, 5.10.272, 5.15.223 and 6.1.190, are dated October 15, and none of the thirty changelogs contains the timer fix’s subject line. Distributions on those lines have to backport the fix themselves. Debian lists its 6.1-based bookworm kernel as fixed in 6.1.190-1, a version built on an upstream release that, by my scan, does not carry the fix, so that looks like Debian’s own backport. Ubuntu 22.04’s 5.15 kernel and Amazon Linux 2’s 5.10 and 5.15 kernels were still waiting.

Where each vendor stood on October 21

The table covers the timer bug, CVE-2026-98260, because it is the one that reaches the most kernels. I read each vendor’s public tracker at about 20:10 UTC on October 21, and the wording in the state column is each vendor’s own where it has one.

Red Hat and CloudLinux

Red Hat issued RHSA-2026:85321 for RHEL 10 on October 19 and RHSA-2026:86033 for RHEL 9 on October 20: 13 and 14 days after the CVE record, and three and four days after the exploit post. The real-time kernel for RHEL 9 (kernel-rt) is still listed as affected, and RHEL 7 and 8 are listed as not affected by any of the six bugs. Red Hat rates the timer bug Important, and its CVE page says mitigation “is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.”

CloudLinux’s fixed kernels carry the same version strings as Red Hat’s advisories. The CloudLinux advisory, last updated at 18:40 UTC on October 21 when I read it, lists the CloudLinux 8 LTS and 9 LTS kernels (TuxCare Endless Lifecycle Support builds) as carrying the vulnerable timer code, found by code review, with fixed kernels pending. It lists CloudLinux for Ubuntu 22.04 as waiting on Canonical. Its CloudLinux 7, 7h and 8 rows say “Under analysis”, while Red Hat lists the matching RHEL 7 and 8 kernels as not affected. That is not a contradiction: CloudLinux kernels carry vendor patches of their own, and CloudLinux says that on CloudLinux 8 “the timer reproducer did not fire, and the vulnerable ordering has not been confirmed on 4.18.” It does mean operators on those rows are waiting for a verdict that Red Hat has already given for its own kernels.

Debian

Debian’s tracker lists the timer bug as fixed in bookworm-security (6.1.190-1, DLA-4841-1), in trixie-security (6.12.113-1, DSA-6568-1) and in unstable (7.2.11-1). The plain bookworm and trixie suites still show 6.1.176-1 and 6.12.107-1 as vulnerable, so machines have to take the update from the security archive. Debian’s fixed kernels are out for both suites.

Ubuntu

Ubuntu rates the timer bug High priority and, on October 21, had published no security notice for it. Its CVE page reads “Vulnerable work in progress in 7.0.0-42.42” for 26.04 LTS, “Vulnerable work in progress in 6.8.0-148.148” for 24.04 LTS and plain “Vulnerable” for 22.04 LTS. The main kernels of 20.04 and 26.10 are not affected, although the 5.15 hardware-enablement kernel on 20.04 is listed as Vulnerable. On 22.04 the 6.8 hardware-enablement kernel is also in progress (6.8.0-148.148~22.04.1), and the AWS, GCP and Oracle kernels follow the same pattern: vulnerable on 22.04, in progress on 24.04 and 26.04. The 26.04 Azure kernel is plain Vulnerable. Ubuntu’s status page defines the in-progress label as the package being affected and “the Ubuntu security team is currently working on a fix”. It does not say when a package will ship.

Ubuntu 26.04: four bugs, all in progress

Ubuntu 26.04 is the release on which the write-up tested the timer, signal, memory-management and futex exploits, and TuxCare says its kernel team “has reproduced root with all four on Ubuntu 26.04 as well.” Ubuntu’s tracker lists all four as work in progress: the timer and signal fixes in 7.0.0-42.42 and the memory-management and futex fixes in 7.0.0-39.39. The futex fix has been in stable kernels since August 27, 55 days before I looked.

Amazon Linux

Amazon’s CVE page rates the timer bug Important with a CVSS 3.1 score of 7.0 and lists every affected kernel as “Pending Fix”: kernel, kernel6.12 and kernel6.18 on Amazon Linux 2023, and the 5.10 and 5.15 “Extra” kernels on Amazon Linux 2, which Amazon’s own site now labels EOS. The pipeline does work: the same kernel6.18 package received the futex fix on September 29 (ALAS2023-2026-3139) and the memory-management fix on October 12 (ALAS2023-2026-3187). The timer fix was 15 days past its CVE record when I looked.

Live patching

For hosts that cannot reboot quickly the usual answer is a live patch, and coverage is thin. TuxCare’s analysis says KernelCare shipped a futex patch on October 16 and that the timer patch, prioritized across EL9, EL10, Debian 12 and 13 and Ubuntu 24.04 and 26.04, comes next. CloudLinux’s October 21 status still reads “timer livepatch in preparation”. Both vendors sell KernelCare, so this is also their product pitch. I did not check Canonical’s own Livepatch service.

The ratings do not track exploit availability

The scores attached to these bugs disagree with one another and with the exploit situation.

The one bug with no public root exploit, SLUB, carries a 7.8 in the kernel CNA’s record and an Important rating from Red Hat. The futex bug, which has one, has no score in the CNA record and a Moderate rating from Red Hat. Ubuntu rates the signal, memory-management and futex bugs Medium even though its newest LTS release is the platform where the root exploits were written. NVD lists all six as “Received”, its first status, with no analysis of its own; where it shows a score, it repeats the CNA’s 7.8 and vector. The two vectors in play differ only in attack complexity: the CNA’s CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H scores 7.8 and Amazon’s attack-complexity-high version scores 7.0, and I recomputed both with the CVSS 3.1 formula. TuxCare’s comment is that “Scores don’t tell this story well”, and it adds that Amazon’s ratings “went out before working root exploits were public.”

What the vendors say about mitigation

There is no switch to flip. CloudLinux’s summary reads “Mitigation: none reliable.” and its advisory explains: “No sysctl, module blacklist, or switch that disables unprivileged user namespaces touches these code paths. CageFS does not help either: it isolates the file system view, but it does not filter the system calls involved, so a caged user can still trigger the bugs.” TuxCare agrees that “There’s no known sysctl or module to switch off” and notes that disabling unprivileged user namespaces will not help because none of the bugs needs one. Red Hat’s statement quoted above says the same in its own terms. I could not test any of these claims.

A practical order of work for this week

This is my synthesis of the vendor guidance and the tracker data above, not a vendor checklist. The commands come from CloudLinux’s advisory for CloudLinux 9 and 10. I checked their options against the DNF command reference, which lists upgrade as the command and update as a deprecated alias, the RPM manual, the journalctl manual and the GNU coreutils manual for uname, and both Red Hat advisories list kernel-core packages. Adapt the commands for other distributions.

1. Find out what you run, by package. Run uname -r on each host and compare the result with your vendor’s advisory, not with upstream version numbers; the backport examples above show why.
2. Order hosts by who can run code on them. TuxCare’s advice is to get fixed kernels onto Ubuntu 26.04 hosts first, starting with any that run code from people you do not fully trust, such as shared hosting servers, CI runners and multi-tenant container hosts. Ubuntu has not released that kernel yet, so the same ordering applies to whichever fix reaches you first. CloudLinux’s scenario is a compromised WordPress site whose attacker gets code execution as that site’s user. A kernel privilege-escalation bug is the step from that foothold to root.
3. Install the fixed kernel and reboot where a fix exists. Red Hat Enterprise Linux 9 and 10, CloudLinux 9 and 10, and Debian 12 and 13 have one now. CloudLinux gives these commands for CloudLinux 9 and 10:

   dnf update 'kernel*'
   reboot

4. Confirm the running kernel carries the fix. Because distribution kernels backport fixes, check the changelog of the running kernel. CloudLinux says that on CloudLinux 9 and 10 empty output from this command means the host is still exposed:

   rpm -q --changelog kernel-core-$(uname -r) | grep -E 'CVE-2026-(98260|98256)'

5. Where no fix exists yet, shrink the exposure. That means Ubuntu, Amazon Linux and the CloudLinux LTS kernels today. CloudLinux suggests limiting who has a local shell on exposed hosts, putting tenants who distrust each other in separate virtual machines instead of containers on a shared kernel, and watching the kernel log, since a failed race can crash the kernel (“A clean log does not prove nothing happened”):

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

6. Watch the trackers. The status table will be out of date soon. The Red Hat, Debian, Ubuntu and Amazon pages linked above are the places to look, along with CloudLinux’s advisory, which it says it will update.

What the pattern says

The record is the early warning. The kernel CNA publishes when a fix reaches a stable tree, so a feed of its records gave 4 to 42 days of lead time on these six bugs, and stable release notes gave 13 to 50. Watching only distribution notices gave less: Red Hat’s RHEL 10 and 9 notices arrived on October 19 and 20, and Ubuntu and Amazon Linux had none for the timer bug on October 21.

Older lines depend on the vendor. The timer bug is the only one that reaches the 5.10 to 6.12 lines, and upstream had not shipped a fix for 5.10, 5.15 or 6.1 in its latest releases. Debian backported its own for bookworm, while Ubuntu 22.04 and Amazon Linux 2 were still waiting.

This is not new here. We covered pedit COW in June, where a public proof of concept appeared on June 17 and CloudLinux’s advisory followed on June 26, and Januscape in July, a KVM escape that Kim also disclosed through oss-security.

The web tier is how an attacker gets the local account. This week’s coverage shows how that first step happens. The PHP2Shell flaws can give an unauthenticated attacker code execution on a web server, and attackers holding UpdraftCentral keys are installing backdoor plugins on WordPress sites. Nobody has linked either to Infinity Core, and I am not suggesting a link. The point is the order of events CloudLinux describes: a web foothold is code running as one site’s user, and on a shared host a working kernel exploit turns that into root for every account on the server.

What I could not verify

• I did not run any exploit or test any kernel. Everything about exploit availability comes from the researcher’s write-up as summarized by CloudLinux and TuxCare, and the Android claim comes from the researcher through TuxCare.
• The statuses are snapshots from public trackers taken at about 20:10 UTC on October 21. I did not check SUSE, Oracle Linux, AlmaLinux, Rocky Linux or Android vendors.
• CloudLinux’s and TuxCare’s statements about CageFS, KernelCare and their own kernels are theirs. Both sell KernelCare, and both pages promote it.
• Whether any host has been attacked. TuxCare reported none as of October 19 and none of the six is in CISA’s catalog, but absence from those sources is not proof of safety.
• The older-line result rests on my scan of released kernel.org changelogs, not on the stable queue, so a fix may be queued for the next releases of those lines.

Sources

• Hyunwoo Kim’s Infinity Core post on oss-security (header dated Sat, 17 Oct 2026 01:00:19 +0900)
• CloudLinux advisory (status of October 21, 18:40 UTC) and TuxCare analysis (October 20)
• NVD records: CVE-2026-98260, CVE-2026-98256, CVE-2026-89754, CVE-2026-80775, CVE-2026-98385 and CVE-2026-97941
• Linux kernel CVE process, kernel.org release list and the stable ChangeLog files
• Vendor trackers: Red Hat, Debian, Ubuntu and Amazon Linux
• CISA Known Exploited Vulnerabilities feed (catalog 2026.10.21)
• Corgea’s Infinity Core write-up (October 19)