Cloudanix VulnDB

CVE-2026-98258

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A timing flaw in the Linux kernel can let a local program corrupt memory during timer operations, potentially crashing the system or allowing an attacker to gain more control.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Full Compromise
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Medium

What it actually does

Use-after-free in POSIX CPU timer expiry handling caused by incorrect firing-state tracking that allows a timer to be freed while still referenced on the private firing list.

Why it matters to the business

Local attackers can trigger kernel memory corruption leading to crashes, denial of service, or potential privilege escalation on Linux systems; the issue affects any workload using POSIX CPU timers and requires prompt kernel updates.

How an attack unfolds

An attacker with local access concurrently invokes timer_settime and timer_delete while the expiry handler is collecting timers onto its private list; the flawed firing boolean lets deletion free the timer object, after which the handler dereferences the freed list entry.

How to fix it

Upgrade to a Linux kernel containing the fix for posix-cpu-timers that checks list membership instead of the firing boolean; apply the stable-branch patch that restores proper TIMER_RETRY handling before the timer is unhashed.

How to confirm the fix worked

Confirm the kernel source contains the check for timer presence on the expiry list rather than relying on the firing flag; run existing POSIX timer stress tests and verify no UAF reports under concurrent set/delete/expiry workloads.

Typical attack path

  1. Obtain local code execution on the target Linux system
  2. Create and arm a POSIX CPU timer
  3. Trigger concurrent timer_settime, timer_delete, and timer expiry paths
  4. Force the expiry handler to traverse the now-freed list entry
  5. Achieve use-after-free for crash or memory corruption

How to detect it

Inspect kernel logs for use-after-free reports or slab corruption mentioning posix-cpu-timers or cpu_timer structures; correlate with processes performing rapid timer_create, timer_settime, and timer_delete calls.

What your security team should do

  • Prioritize kernel updates on all multi-user and exposed Linux hosts within the next patch cycle
  • Enable kernel hardening features such as KASAN or SLUB_DEBUG to increase exploit difficulty until patched
  • Review workloads that rely on POSIX CPU timers for possible alternative implementations
  • Monitor for related timer-handling patches in future stable releases

The record

In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent freeing a timer which is queued on the expiry list Kijo analyzed another race in the POSIX CPU timer code: Commit bf635681c906 converted cpu_timer::firing from a tristate value to a boolean. This lost the distinction between "not owned by the firing list" and "still owned, but delivery was canceled". The resulting race is: expiry handler timer_settime() timer_delete() -------------- --------------- -------------- collect timer onto private firing list firing = true observes firing = true firing = false return TIMER_RETRY wait for handler observes firing = false finish deletion unhash and free timer resume list traversal read freed elist.next -> UAF The firing bit is clearly the wrong indicator since that commit. Check whether the timer is queued on the expiry list or not instead. If it is queued clear the firing bit to prevent signal delivery as before and return TIMER_RETRY so the caller unlocks the timer which allows the expiry code to make progress and remove it from the list.

Affected packages

Ecosystem Package Introduced Fixed