Cloudanix VulnDB

CVE-2026-93137

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in the Linux kernel could let a program running on the same computer corrupt critical memory and take control of the whole machine.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free on mm_struct in bpf_find_vma() when a BPF program performs a lockless read of task->mm on a foreign task followed by mmap_read_trylock() after the owning task has called exit_mm() and freed the mm_struct.

Why it matters to the business

Local attackers can achieve kernel memory corruption or arbitrary code execution on systems running unpatched kernels with BPF programs, resulting in full host compromise, loss of confidentiality/integrity/availability, and potential lateral movement in container or multi-tenant environments.

How an attack unfolds

An attacker compiles and loads a BPF program that invokes bpf_find_vma() against a foreign task; concurrently triggers task exit on the target so that exit_mm() frees the mm_struct between the lockless read and the subsequent trylock, causing the UAF.

How to fix it

Upgrade to a Linux kernel containing the referenced fix that pins the mm under task->alloc_lock, uses mmput_async(), rejects IRQ-disabled and !CONFIG_MMU contexts on the foreign-task path, and mirrors the approach from commit d8e27d2d22b6.

How to confirm the fix worked

Verify the running kernel contains the mm-lifecycle fix for bpf_find_vma(); inspect kernel source or git history for the described changes to task->alloc_lock and mmput_async() usage; test that BPF programs targeting foreign tasks no longer trigger UAF under concurrent exit_mm().

Typical attack path

  1. Obtain local unprivileged access on a Linux host
  2. Load or attach a BPF program that calls bpf_find_vma on a chosen foreign task
  3. Race the target task's exit_mm() path to free the mm_struct
  4. Trigger the UAF dereference inside mmap_read_trylock to corrupt kernel memory or escalate privileges

How to detect it

Search kernel logs and crash dumps for use-after-free signatures involving mm_struct, mmap_read_trylock, or bpf_find_vma; correlate with BPF program loads and task exit events around the same timestamp.

What your security team should do

  • Apply the kernel fix immediately on all systems that compile or run BPF programs
  • Restrict unprivileged BPF loading via sysctl kernel.unprivileged_bpf_disabled=1 where operationally feasible
  • Monitor kernel logs for mm_struct related oops or warnings on hosts running custom BPF
  • Review and reduce use of bpf_find_vma or foreign-task iterators in production BPF programs

The record

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free on mm_struct in bpf_find_vma() bpf_find_vma() reads task->mm and calls mmap_read_trylock(mm) without holding a reference on the mm. On a foreign task, a concurrent exit_mm() can free the mm_struct between the lockless read and the trylock, resulting in a use-after-free. mm_struct is not SLAB_TYPESAFE_BY_RCU. For the current task, task->mm is stable. For a foreign task, pin the mm under task->alloc_lock and release it with mmput_async(), mirroring commit d8e27d2d22b6 ("bpf: fix mm lifecycle in open-coded task_vma iterator"). Use spin_trylock() instead of get_task_mm() so BPF context does not block on alloc_lock. Reject irqs-disabled contexts and !CONFIG_MMU on the foreign-task path because dropping the mm reference is not safe there. Race: CPU0 (BPF program) CPU1 (exiting task) ============================ ========================== bpf_find_vma(foreign_task): mm = task->mm exit_mm(): task->mm = NULL mmput(mm) -> frees mm_struct mmap_read_trylock(mm) // UAF on mm

Affected packages

Ecosystem Package Introduced Fixed