CVE-2026-90342: bpf: Fix mmap_lock deadlock on arena lock failure
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix mmaplock deadlock on arena lock failure
Reported by the Sashiko AI review.
arenavmfault() returns VMFAULTRETRY when it can't take arena->spinlock, but it never took mmaplock. The fault path assumes a VMFAULTRETRY handler already dropped mmaplock and re-takes it on the retry, so mmaplock gets taken twice and can deadlock:
douseraddrfault() { fault = handlemmfault(...); // calls arenavmfault() if (fault & VMFAULTRETRY) goto retry; // re-locks mmaplock mmapreadunlock(mm); }
Return VMFAULTSIGBUS instead, for two reasons:
1. We could keep VMFAULTRETRY, but then we'd have to drop the fault lock first and cap the retry ourselves, the way foliolockorretry() does.
2. A failed rawresspinlockirqsave() already means a possible deadlock was detected, so retrying just hits the same lock again.
So returning VMFAULTRETRY here is overkill.
Affected Software
Event History
Frequently Asked Questions
What condition causes the deadlock?
The issue occurs when arena_vm_fault() cannot acquire arena->spinlock. It returns VM_FAULT_RETRY despite not having acquired mmap_lock, and the page-fault retry path then takes mmap_lock again, which can deadlock.
Why is retrying the fault not a safe workaround?
A failed raw_res_spin_lock_irqsave() already indicates that a possible deadlock was detected. Retrying would attempt the same lock again, so the fix returns VM_FAULT_SIGBUS rather than VM_FAULT_RETRY.