Description
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.
Published: 2026-10-06
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: Use‑after‑free leading to memory corruption or kernel crash
Action: Apply patch
AI Analysis

Impact

A race condition exists in the Linux kernel’s POSIX CPU timer subsystem where a timer can be freed while it remains queued on the expiry list. The change from a tristate 'firing' flag to a simple boolean caused the kernel to misidentify whether a timer was still in use, potentially freeing it during an active expiry handler. The resulting use‑after‑free can corrupt kernel memory and trigger a crash or, in theory, allow a local attacker to influence the kernel state.

Affected Systems

The vulnerability affects the Linux kernel itself. All releases prior to the inclusion of commit bf635681c906 are vulnerable. Kernels built from that commit onward incorporate the fix, preventing the race by checking the timer’s queued status before freeing it.

Risk and Exploitability

The CVSS score of 7.8 denotes a high‑severity local flaw. The EPSS score of <1% indicates that exploitation is currently rare, and the vulnerability is not listed in the CISA KEV catalog. The race requires a local attacker to control the creation and deletion of timers, which suggests that while the potential impact is significant, the likelihood of exploitation under normal conditions remains low.

Generated by OpenCVE AI on October 11, 2026 at 05:31 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the kernel patch that includes commit bf635681c906 or upgrade to a kernel version that contains the fix
  • Restrict the use of POSIX CPU timers for untrusted or unprivileged processes by setting limits or disabling timer creation where feasible
  • Enable kernel hardening mechanisms such as SELinux, AppArmor or seccomp to limit the impact of any remaining race conditions

Generated by OpenCVE AI on October 11, 2026 at 05:31 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sun, 11 Oct 2026 04:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-416

Sun, 11 Oct 2026 00:30:00 +0000


Wed, 07 Oct 2026 11:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-416

Wed, 07 Oct 2026 09:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Wed, 07 Oct 2026 07:00:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}


Tue, 06 Oct 2026 13:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Tue, 06 Oct 2026 09:00:00 +0000

Type Values Removed Values Added
Description 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.
Title posix-cpu-timers: Prevent freeing a timer which is queued on the expiry list
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-19T09:16:29.418Z

Reserved: 2026-09-25T10:25:14.332Z

Link: CVE-2026-98258

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-06T09:18:14.737

Modified: 2026-10-19T10:18:26.880

Link: CVE-2026-98258

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-10-06T00:00:00Z

Links: CVE-2026-98258 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-10-11T05:45:16Z

Weaknesses
  • CWE-825

    Expired Pointer Dereference