Linux Kernel CVE-2026-98258

Requires local access with the ability to call standard POSIX CPU timer syscalls (timer_create with CLOCK_PROCESS_CPUTIME_ID/CLOCK_THREAD_CPUTIME_ID, then timer_settime/timer_delete) - no elevated privileges needed, as these interfaces are available to ordinary users. Exploitation is further gated by having to win a narrow concurrency window: the timer must be in the firing state (queued on the expiry handler's private firing list) at the moment timer_settime() and timer_delete() race it, so that the firing-bit ambiguity introduced by commit bf635681c906 causes the timer to be freed while still queued. Limiting factors: local-only vector (no remote reachability), the need to repeatedly lose/retry to hit the race, and applicability only to kernels containing commit bf635681c906 up to the referenced stable fix commits (roughly 6.13 onward until patched).

Signals point to a genuine but non-urgent local vulnerability. The CVSS base of 7.8 (HIGH) is driven entirely by impact (C:H/I:H/A:H), not accessibility: the vector is AV:L/AC:L/PR:L/UI:N, meaning an attacker must already have local, authenticated (unprivileged) code execution on the host. EPSS reinforces low real-world urgency at 0.17% (6th percentile), there is no CISA KEV listing, and no public exploit was identified - so this is 'no public exploit identified at time of analysis.' These signals are consistent rather than conflicting: a high-impact-but-local flaw with very low exploitation probability. One caveat on complexity: the input rates AC:L, but the described defect is a three-way race (expiry handler vs. timer_settime() vs. timer_delete()) that an attacker must win to trigger the use-after-free, which realistically argues for higher attack complexity than AC:L implies. Net: this is a legitimate local privilege-escalation / memory-corruption primitive in an ubiquitously deployed product, but it is NOT a drop-everything priority - patch it through the normal kernel update cycle. Note also a mild metadata tension: the 'Information Disclosure' tag understates the issue, since a UAF with C:H/I:H/A:H is a full memory-corruption primitive, not merely an info leak.

A local unprivileged user creates a POSIX CPU timer, then concurrently calls timer_settime() and timer_delete() while the timer is firing, deliberately racing the kernel expiry handler. Winning the race frees the cpu_timer while it is still queued on the private firing list, so the handler then dereferences freed memory (elist.next), giving a use-after-free the attacker can groom toward kernel memory corruption and privilege escalation. No public proof-of-concept is currently identified, and exploitation requires local access plus winning a tight timing window.