HIGH
futex VforkHash UAF
CVE-2026-98281
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
KernelScan AI7.8HIGH
01Description
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.
02KernelScan AI Analysis
Risk summary
An unprivileged local user can trigger a use-after-free in the kernel's futex hash percpu counters by using futex operations after vfork(), which shares the parent's address space without allocating a private futex hash. This can lead to kernel memory corruption exploitable for privilege escalation or denial of service. Any system with local untrusted users — including multi-tenant containers and shared hosts — is at risk.
Vulnerability analysis
When a process calls vfork(), the child shares the parent's memory space, but the kernel previously excluded vfork from allocating a private futex hash — assuming the parent would be suspended and no concurrency was possible. However, the child can independently access the shared memory and perform futex wait operations before any private hash exists, causing use-after-free corruption in the percpu futex hash reference counters. The fix removes the vfork exclusion so that every clone sharing the parent's memory space — including vfork — allocates a private futex hash upfront, ensuring no futex waiters can exist before the hash is in place. Any unprivileged local user can trigger this directly through the vfork() and futex syscalls; no special capabilities, hardware, or configuration are required.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 6.18 | 6.18.33 | 6.18.54 | 5468a4855b63 |
| 7.0 | 7.0.10 | 7.1 | eecbafa8cabb |
| 7.2 | — | 7.2.8 | b61b6f95d672 |
| mainline | — | 7.3-rc4 | — |