Cloudanix VulnDB

CVE-2026-80758

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug inside the Linux kernel's handling of certain low-level synchronization features could let attackers who already have access crash the whole system or potentially gain more control.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
High
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in futex_private_hash_put where fph->mm is read after the final reference drop and RCU grace period allows the kmalloc-512 allocation to be freed by another task.

Why it matters to the business

Linux systems may experience kernel crashes or memory corruption; local attackers could leverage the flaw for denial of service or privilege escalation on servers and endpoints running affected kernels.

How an attack unfolds

An attacker crafts concurrent futex operations that allocate a private hash, drops the last reference while preemption is enabled, waits for an RCU grace period to free the structure, then resumes the original task to read the now-freed mm pointer.

How to fix it

Apply the upstream kernel commit that loads the mm pointer while the fph reference is still held and passes the saved value to wake_up_var; rebuild and deploy the patched kernel across all affected distributions.

How to confirm the fix worked

Boot the patched kernel and confirm absence of KASAN slab-use-after-free reports in futex_private_hash_put; review kernel source for the mm-load-before-put change and run regression tests exercising futex private hashing.

Typical attack path

  1. Trigger futex hash allocation via userspace futex calls
  2. Force preemption exactly after the reference count reaches zero but before mm is loaded
  3. Allow RCU grace period to complete so another task frees the kmalloc-512 object
  4. Resume original task to dereference the freed pointer inside wake_up_var

How to detect it

Search kernel logs and dmesg for KASAN reports citing slab-use-after-free at offset 24 inside a kmalloc-512 allocation with stack traces pointing to futex_private_hash_put and futex_hash_allocate.

What your security team should do

  • Prioritize kernel updates on all production Linux systems within the next patching cycle
  • Enable KASAN or similar debug kernels in staging environments to validate the fix
  • Monitor vendor advisories for backported fixes in LTS kernels
  • Restrict untrusted local code execution where possible until patches are deployed

The record

In the Linux kernel, the following vulnerability has been resolved: futex: Avoid private hash use-after-free on final put futex_private_hash_put() drops the reference to fph before evaluating fph->mm for wake_up_var(). futex_ref_put() enables preemption again before returning. If that put drops the final reference and the task is preempted, another task can pivot to the replacement hash and free the old hash after an RCU grace period. The first task then reads fph->mm from the freed allocation when it resumes. KASAN reports a slab-use-after-free in futex_private_hash_put(), with the read at offset 24 in a freed kmalloc-512 allocation. The allocation and free stacks point to futex_hash_allocate() and the RCU free path, respectively. Load the mm pointer while the fph reference is still held and pass the saved value to wake_up_var(). wake_up_var() uses the pointer as a waitqueue key and does not dereference the mm through it.

Affected packages

Ecosystem Package Introduced Fixed