Skip to main content

Linux Kernel EUVDEUVD-2026-93186

| CVE-2026-98258 HIGH
2026-10-06 Linux GHSA-h9hq-jmqv-hjx4
7.8
CVSS 3.1 · Vendor: Linux
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Gain local unprivileged shell
  2. Delivery
    Create POSIX CPU timer
  3. Exploit
    Race timer_settime/timer_delete against expiry
  4. Execution
    Trigger use-after-free on freed timer
  5. Impact
    Escalate to kernel privileges

Vulnerability Assessment

Exploitation Conditions

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).

Impact

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.

Exploit ScenarioDerived

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.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 07, 2026

Use-after-free in the Linux kernel's POSIX CPU timer subsystem lets a local low-privileged user free a timer that is still queued on the expiry handler's private firing list, corrupting kernel memory and opening the door to privilege escalation or denial of service on kernels built from commit bf635681c906 onward (roughly 6.13 until the referenced stable fixes). Exploitation needs only the standard timer_create/timer_settime/timer_delete calls available to ordinary users, but it is gated by a narrow concurrency window that must be won (assessed CVSS:3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H), which keeps real-world risk modest. No public exploit code or confirmed active exploitation is known and EPSS is 0.17% (6th percentile), while vendor patches are available.

RemediationAI

Upgrade to a kernel containing the upstream fix: the stable back-ports land in Linux 6.18.54, 7.2.8 and 7.3-rc4 (or later), and distributions should track their vendor's rebuilt kernel carrying commits 9971dac1a77845ff467146915fcbb9170f6a8209 (https://git.kernel.org/stable/c/9971dac1a77845ff467146915fcbb9170f6a8209), 4336e3f47d9d516441066e9a65eaf076790d8d45 (https://git.kernel.org/stable/c/4336e3f47d9d516441066e9a65eaf076790d8d45) or c21eaa72f02fc6e85621cbe09d303d8fb8bd39cd (https://git.kernel.org/stable/c/c21eaa72f02fc6e85621cbe09d303d8fb8bd39cd); the NVD entry is at https://nvd.nist.gov/vuln/detail/CVE-2026-98258. Patch status is 'vendor patch available' (no exact upstream LTS versioning is given beyond the EUVD-listed 6.18.54/7.2.8/7.3-rc4), and no public exploit has been identified, so emergency out-of-band patching is not mandatory - schedule the update in the normal kernel maintenance window. Where patching must be deferred, the practical compensating control is to deny unprivileged access to the POSIX CPU-timer syscalls with a seccomp-BPF filter that returns EPERM/ENOSYS for timer_create, timer_settime, timer_delete and timer_gettime (and, more bluntly, clock_nanosleep where feasible) for untrusted or network-facing workloads; the trade-off is that this breaks legitimate applications, profiling tools and language runtimes that rely on POSIX CPU timers, so it should be scoped per-service rather than applied host-wide. Additional isolation measures - running untrusted code in a sandbox with its own timer namespace, in a VM, or under a container runtime that filters these syscalls - reduce reachability but add operational overhead and do not remove the underlying race, so they are complements to, not substitutes for, the kernel fix. Note that this is a local-only, race-gated bug, so the highest-value hardening step is simply keeping untrusted local users off kernels older than the fixed stable releases; do not treat it as a remote-emergency patch.

Affected VersionsENISA

Linux bf635681c906ad056d1fda325de8d1c12c9f8201 <4336e3f47d9d516441066e9a65eaf076790d8d45
Linux patch: 7.2.8
Linux bf635681c906ad056d1fda325de8d1c12c9f8201 <c21eaa72f02fc6e85621cbe09d303d8fb8bd39cd
Linux 6.13
Linux patch: 7.3-rc4
Linux bf635681c906ad056d1fda325de8d1c12c9f8201 <9971dac1a77845ff467146915fcbb9170f6a8209
Linux patch: 0
Linux patch: 6.18.54

Affected Packages

euvd linux no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The flaw lives in the POSIX CPU timer implementation (kernel/time/posix-cpu-timers.c) and the per-timer struct cpu_timer, whose 'firing' field is manipulated by the expiry (signal delivery) path and by the timer_settime()/timer_delete() syscall paths. Commit bf635681c906 changed that field from a tristate into a boolean, erasing the historical distinction between 'this timer is not owned by the firing list' and 'this timer is still owned by the firing list but delivery was canceled'. The resulting race has three interleavings: the expiry handler collects a timer onto its private firing list and sets firing=true; timer_settime() observes firing=true, clears it to false and returns TIMER_RETRY, waiting for the handler; timer_delete() then observes firing=false, completes deletion, unhashes and frees the timer; when the handler resumes its list traversal it dereferences the freed elist.next pointer, producing a use-after-free whose root-cause class is CWE-416/UAF arising from a concurrency race (CWE-362). The upstream fix abandons the firing bit as the ownership indicator and instead tests whether the timer is currently queued on the expiry list; if it is, the code clears the firing bit to suppress signal delivery and returns TIMER_RETRY so the caller drops the timer lock, allowing the expiry path to make progress and unlink the timer safely. The vulnerable code is reachable purely through the POSIX CPU-timer syscall family, so no special hardware, network position, or kernel module is required.

Know when the next one hits your stack

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (Linux) PRIMARY 7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI 7.0 HIGH

Local unprivileged syscalls suffice (AV:L/PR:L), but winning the three-way timer race is hard (AC:H); the resulting kernel UAF yields full memory-corruption impact (C/I/A:H).

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
4.0 AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

4
CVSS changed
Oct 07, 2026 - 07:22 NVD
7.8 (HIGH)
Patch available
Oct 06, 2026 - 10:02 EUVD
CVE Published
Oct 06, 2026 - 08:45 cve.org
UNKNOWN (no severity yet)
CVE Published
Oct 06, 2026 - 08:45 cve.org
HIGH 7.8

DescriptionCVE.org

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.

Executive ViewAI

Why It Matters

A high-severity memory corruption flaw in the Linux kernel (CVE-2026-98258) could allow a local low-privileged user to gain root-level control or cause a denial of service on systems running kernel versions built from commit bf635681c906 onward (approximately 6.13 until vendor stable fixes). Organizations running unpatched Linux servers, cloud instances, or multi-tenant hosts are most exposed because a compromised local account could escalate to full system privileges. No public exploit identified at time of analysis, and vendor patches are available, so prompt remediation is the priority.

Business Impact: High
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.2%
Top 94% exploitable
Prevalence
Ubiquitous
Linux kernel runs on a huge fraction of production systems
Data Quality
4 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Small
Automatable· derived
No
Human Impact
High

Priority Score

39
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +39
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy