Cloudanix VulnDB

CVE-2026-90342

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A locking mistake in the Linux kernel could cause the system to freeze when certain advanced networking or security programs run, and the fix prevents that freeze from happening.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Improper VM_FAULT_RETRY return in arena_vm_fault() causes double-acquisition of mmap_lock when raw_res_spin_lock_irqsave() fails, leading to deadlock in the do_user_addr_fault() retry path.

Why it matters to the business

Unpatched systems risk kernel-level deadlocks or hangs when BPF arena mappings experience lock contention, potentially disrupting workloads on Linux hosts that use advanced BPF features.

How an attack unfolds

An attacker with local access crafts BPF arena mappings and triggers concurrent faults that force arena spinlock acquisition failure; the fault handler then retries without having dropped mmap_lock, causing deadlock. No public exploits or threat actors are associated with this issue.

How to fix it

Upgrade to a Linux kernel containing the commit that changes arena_vm_fault() to return VM_FAULT_SIGBUS instead of VM_FAULT_RETRY on lock failure.

How to confirm the fix worked

Confirm kernel source contains the updated arena_vm_fault() logic returning VM_FAULT_SIGBUS; reproduce fault under lock contention to verify no deadlock occurs.

Typical attack path

  1. Obtain local code execution on target Linux system
  2. Load BPF program that creates arena mappings
  3. Induce concurrent page faults while holding or contending arena spinlock
  4. Trigger raw_res_spin_lock_irqsave() failure path in arena_vm_fault()
  5. Observe deadlock in mmap_lock acquisition during fault retry

How to detect it

Search kernel logs and dmesg for repeated mmap_lock contention messages or task hangs involving arena_vm_fault; correlate with BPF program load events.

What your security team should do

  • Identify systems running BPF arena code and schedule kernel updates within normal patch windows
  • Monitor kernel logs for mmap_lock related stalls or deadlocks
  • Review BPF usage to determine exposure breadth across the fleet

The record

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix mmap_lock deadlock on arena lock failure Reported by the Sashiko AI review. arena_vm_fault() returns VM_FAULT_RETRY when it can't take arena->spinlock, but it never took mmap_lock. The fault path assumes a VM_FAULT_RETRY handler already dropped mmap_lock and re-takes it on the retry, so mmap_lock gets taken twice and can deadlock: do_user_addr_fault() { fault = handle_mm_fault(...); // calls arena_vm_fault() if (fault & VM_FAULT_RETRY) goto retry; // re-locks mmap_lock mmap_read_unlock(mm); } Return VM_FAULT_SIGBUS instead, for two reasons: 1. We could keep VM_FAULT_RETRY, but then we'd have to drop the fault lock first and cap the retry ourselves, the way __folio_lock_or_retry() does. 2. A failed raw_res_spin_lock_irqsave() already means a possible deadlock was detected, so retrying just hits the same lock again. So returning VM_FAULT_RETRY here is overkill.

Affected packages

Ecosystem Package Introduced Fixed