← Back to search

CVE-2026-98281

7.8 HIGH

Published 2026-10-06 · Updated 2026-10-07

AI risk analysis

Summary
The Linux kernel fails to properly allocate private futex hash tables during vfork() operations, which can lead to race conditions where futex waiters are created before the necessary hash table is allocated. This vulnerability allows for potential memory corruption or denial of service when processes fork with shared memory mappings.
Exploitability
Exploitation requires a process that uses vfork() with shared memory mappings and creates futex waiters before the private hash table is allocated, which is moderately difficult to trigger in practice without specific application patterns.
Blast radius
If exploited, this vulnerability could affect any system running Linux kernels that use vfork() with shared memory, potentially leading to system instability or denial of service across multiple processes.
Detection
No reliable host or network indicator is derivable from the published description.
Prioritized remediation
Upgrade to Linux kernel version 6.10 or later which contains the fix for this futex hash allocation issue during vfork() operations.
kernelmemory-corruptionrace-condition

Analysis generated locally by garnet-coder (no data left the box). AI-assisted — verify against primary sources before acting.

NVD description

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.

CVSS vector

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

All references

Source data: NVD (nvd.nist.gov), public domain. Exploit-DB.ai adds local AI analysis for defensive use only.

Related CVEs

Related by shared AI tags and CWE weakness class. Browse the full archive.