CVE-2026-72357

The CVSS score of 7.8 for this uprobe unregistration bug warrants scrutiny before you treat it as a typical medium-severity vulnerability. The core issue is a context confusion in `__in_uprobe_trampoline` during the unregister path: the code uses `current->mm` to look up a VMA when it should be using the target process's mm_struct, because you're in tracer context, not the traced process's context. This is a use-after-free-class bug operating on the wrong memory map — a VMA lookup against the wrong process can corrupt that process's memory layout, causing page faults, kernel OOPS, or denial of service. The severity rating conflates damage potential with exploitability. The narrow timing window during unregistration is real, but it's not the primary constraint. The real constraint is access: this bug only triggers in tracer context, which means you need to either control the tracer or compromise the tracer infrastructure itself. Standard debug tools like perf and bpftrace are tracers — but exploiting this through them requires either a bug in their implementation or already having the capability that implies game-over access. The CVSS treats this as a standalone use-after-free without weighting the privilege requirements. Here's what the score obscures: this bug has a lineage. The same pattern — using the wrong process context at tracer/traced boundaries — appeared in ftrace and perf event teardown. Each gets patched with the same structural fix (passing the correct mm_struct pointer), and each patch creates false confidence while the underlying design condition persists. The unregister path specifically is where kernel code goes to rot: registration gets exercised, fuzzed, and maintained; teardown paths are rarely touched and rarely reviewed. This is the third or fourth conversation of this exact bug class in the same subsystem. What should you do? First, verify whether your tracer implementation initiates unregistration programmatically — if you're the tracer, the timing window constraint disappears because you control when unregister happens. Second, consider the multi-tenant blast radius: containerized workloads using perf or bpftrace share the host kernel. If a containerized tracer hits this bug, corrupted VMA state lands in host-level structures, affecting co-resident containers. The CVSS models individual impact but can't express this interconnected blast radius. The patch is architecturally simple — passing the correct mm_struct pointer — but that simplicity is the trap. It addresses this instance without generating durable knowledge that prevents the next occurrence. The fix will be applied, the 7.8 will be accepted, and the pattern will likely recur in some other teardown path. Treat this as a symptom of structural debt, not a one-off incident.

Reviewed through automated stages and approved by a human before publication.