Bug 2536541 (CVE-2026-90342) - CVE-2026-90342 kernel: bpf: Fix mmap_lock deadlock on arena lock failure
Summary: CVE-2026-90342 kernel: bpf: Fix mmap_lock deadlock on arena lock failure
Keywords:
Status: NEW
Alias: CVE-2026-90342
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-09-17 18:21 UTC by OSIDB Bzimport
Modified: 2026-10-13 14:29 UTC (History)
17 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-09-17 18:21:00 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.