Skip to main content

Linux Kernel CVE-2026-98281

| EUVDEUVD-2026-93209 HIGH
2026-10-06 Linux GHSA-fwjp-32v8-7pp8
7.8
CVSS 3.1 · Vendor: Linux
View

Attack ChainAIDerived

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

  1. Access
    Obtain local low-privileged shell
  2. Delivery
    Spawn futex waiters before hash alloc
  3. Exploit
    Trigger vfork()/CLONE_VM to reach mm
  4. Execution
    Corrupt kernel memory via private-hash gap
  5. Impact
    Escalate to root privileges

Vulnerability Assessment

Exploitation Conditions

Requires local code execution as an existing (even unprivileged) user who can run a program that establishes private futex waiters and then triggers vfork() or another CLONE_VM-based clone before the private futex hash has been allocated - the precise unsafe window the fix closes. This is not remotely reachable: AV:L and PR:L mean the attacker must already have an authenticated local account and the ability to execute arbitrary binaries. Exploitation is further limited by the need to reliably hit the race/ordering condition (futex waiters existing prior to private-hash allocation across the vfork boundary), which reduces reliability and favors a skilled attacker; systems without untrusted local users are at substantially lower practical risk. Only kernels in the affected ranges (e.g. 6.18.33-6.18.54, 7.0.10-7.1 and related) are vulnerable.

Impact

Signals are consistent and point to a genuine but non-urgent local-privilege-class kernel flaw rather than an internet-facing emergency. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 7.8) confirms this is locally exploitable by an already-authenticated low-privileged user with no user interaction, yielding high confidentiality, integrity and availability impact - the classic profile of a kernel memory-safety bug leading to local privilege escalation. The EPSS score is very low (0.17%, 6th percentile), the CVE is NOT on the CISA KEV list, and no public exploit is referenced, so there is no evidence of active or imminent mass exploitation. The one countervailing signal is that the bug was found and demonstrated-as-reachable by a well-known researcher (Jann Horn), meaning exploitability is credible and weaponization by a skilled attacker is plausible even though no POC is published. Note a labeling tension: the input Tags list 'Information Disclosure', but the CVSS vector asserts C:H/I:H/A:H and the description concerns futex private-hash allocation on vfork()/CLONE_VM (a memory-management/use-after-free pattern typical of privilege escalation, not pure info disclosure) - treat the 'Information Disclosure' characterization with caution and verify impact against the upstream commits. Overall: real priority for multi-tenant and untrusted-local-user environments to patch on normal cadence, low priority as an emergency.

Exploit ScenarioDerived

A local, low-privileged user on a shared Linux host runs a crafted program that creates futex waiters and then invokes vfork() (or another CLONE_VM path) before the private futex hash is allocated, reaching the mm in an inconsistent state. By winning the resulting race/triggering the unsafe access the attacker corrupts kernel memory to escalate to root. No public exploit code is identified at time of analysis, but reachability was demonstrated by the reporting researcher.

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

Local privilege escalation in the Linux kernel futex subsystem (CVE-2026-98281) lets an existing local user with the ability to execute binaries corrupt or manipulate the per-mm private futex hash, potentially leading to full compromise of confidentiality, integrity and availability on the affected host. The flaw stems from the kernel failing to allocate the private futex hash when the mm is shared across a vfork() (or other CLONE_VM) boundary, so private futex waiters can exist before that hash is initialized; the fix closes this ordering window. Exploitation requires an authenticated local account (CVSS PR:L) and reliable triggering of the ordering condition, which our assessment rates as high attack complexity despite the vendor's base vector (AV:L/AC:H versus the published AC:L). There is no public exploit identified at time of analysis, the issue is not in CISA KEV, and EPSS is low at roughly 0.17% (6th percentile), indicating a genuine but non-urgent local-privilege-class kernel flaw rather than an internet-facing emergency.

RemediationAI

Vendor-released patch: upgrade to Linux kernel 6.18.54, 7.1, 7.2.8 or 7.3-rc4 (or a later release containing the fix commits b61b6f95d6722ddbbbd09e689fa41b55fd36f9a5, eecbafa8cabbc4d1482f6a5e2acc25a8f934681b or 5468a4855b63b30156a79e5248e01bf1a2c18dd7), and track your distribution's backported kernel errata for the corresponding update. Because the flaw is only reachable with local code execution (AV:L/PR:L) and requires winning an ordering/race window that our assessment rates as high complexity, the most effective compensating control while patching is to eliminate the attacker's foothold rather than to reconfigure the futex subsystem: restrict interactive/shell access and arbitrary binary execution for untrusted local accounts, and confine multi-tenant or CI-style workloads that run untrusted code on shared kernels to isolated VMs, containers with a patched or gVisor-style kernel, or dedicated hosts. Where untrusted local execution cannot be removed, prioritize the kernel upgrade on hosts with shared shells, build runners, or container hosts; seccomp and similar syscall filters are not a reliable mitigation here because the vulnerable path is exercised by ordinary pthread/vfork usage, and disabling vfork or CLONE_VM system-wide would break standard runtimes and is not advised. Kernel livepatching backports of the referenced commits can bridge the gap until a full reboot-into-patched-kernel cycle is possible. Monitor the vendor advisory at https://nvd.nist.gov/vuln/detail/CVE-2026-98281 and the kernel.org stable commits for updated guidance; note that no vendor workaround is documented, so patching remains the only complete fix.

Affected VersionsENISA

Linux patch: 0
Linux patch: 6.18.54
Linux 974ac49a9a068b0591a59f65c63eb06579a13091
Linux 7.1
Linux 1dcd36420af2da5bd59306dba9caf78e3d248b1d <5468a4855b63b30156a79e5248e01bf1a2c18dd7
Linux ee9dce44362b2d8132c32964656ab6dff7dfbc6a <eecbafa8cabbc4d1482f6a5e2acc25a8f934681b
Linux 6.18.33 <6.18.54
Linux 7.0.10 <7.1
Linux ee9dce44362b2d8132c32964656ab6dff7dfbc6a <b61b6f95d6722ddbbbd09e689fa41b55fd36f9a5
Linux patch: 7.2.8
Linux patch: 7.3-rc4

Affected Packages

euvd linux fix: 6.18.54, 7.1

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 futex (fast userspace mutex) subsystem backs most userspace locking primitives (pthread mutexes, condvars, etc.). Private futexes (FUTEX_PRIVATE_FLAG) are tracked per address space in a hash table hung off the mm_struct, and the kernel allocates that private hash lazily on first use rather than at mm creation. vfork() and other CLONE_VM clones share the mm_struct without being threads, so a child process can legitimately reach the parent's address space and issue private futex operations, as Jann Horn demonstrated. If a private futex waiter is established across such a vfork boundary before the private hash has been allocated, the kernel can operate on the futex state without the required backing structure, producing the memory-safety and ordering defect the patch addresses. The commit therefore forces private-hash allocation on vfork() and any other CLONE_VM user, and explicitly ensures the kernel never allows private futex waiters to exist prior to that allocation. This is best characterized as an initialization-ordering/concurrency defect in mm- and futex-lifetime handling rather than a classical CWE-tagged parsing or bounds bug; no CWE identifier was supplied in the source data. Affected code sits in the core kernel (CPE cpe:2.3:a:linux:linux), and the fix is delivered through the upstream stable/mainline trees.

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 low-priv user (AV:L/PR:L); AC:H because it depends on winning a vfork/CLONE_VM ordering race; kernel memory corruption yields full C/I/A.

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:

futex: Also allocate private hash on vfork()

As Jann demonstrated, it is entirely feasible to access the mm through vfork(). Therefore we need to allocate a private hash on vfork() as well as any other CLONE_VM user.

Specifically, it must be avoided to have (private) futex waiters before allocating the private hash.

Executive ViewAI

Why It Matters

A high-severity flaw in the Linux kernel's futex subsystem could allow an attacker with an existing local account to escalate privileges and fully compromise an affected host, risking data confidentiality, integrity, and service availability. Organizations running vulnerable Linux kernels-especially multi-user servers, container hosts, and shared build or jump systems-should prioritize remediation because local access could be turned into root-level control. The immediate risk is tempered by the need for authenticated local access, high attack complexity, and no public exploit identified at time of analysis, but a vendor patch is available and should be treated as a high-priority kernel update.

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 servers, cloud, and devices
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