CVE-2024-35860

What it actually does

Use-after-free in bpf_link deallocation for multi-kprobe, multi-uprobe, and raw_tp links where active BPF programs can still dereference link data (such as cookies) after refcount reaches zero but before RCU grace period completes.

Why it matters to the business

Linux kernel systems running affected BPF workloads face elevated risk of crashes, memory corruption, or local privilege escalation; the issue has been public for over two years with negligible exploitation signals and no ransomware usage.

How an attack unfolds

An attacker loads a sleepable or non-sleepable BPF program that holds a reference to a multi-kprobe or raw_tp link, triggers refcount drop to zero while the program is still executing, then reuses the freed link object during the window before RCU grace period to read or write attacker-controlled data.

How to fix it

Upgrade the Linux kernel to a version containing commit 876941f533e7b47fc69977fc4551c02f2d18af97 or later; rebuild and redeploy any out-of-tree modules that register custom bpf_link types; enable BPF LSM or other runtime restrictions if immediate patching is not feasible.

How to confirm the fix worked

Confirm the running kernel contains commit 876941f533e7b47fc69977fc4551c02f2d18af97; inspect /proc/kallsyms or kernel build logs for the deferred dealloc callbacks; run existing BPF selftests for multi-kprobe and raw_tp links to verify no UAF reports under syzkaller or KASAN.

Typical attack path

1. Obtain local code execution or unprivileged user access on a Linux host with CAP_BPF or ability to load tracing programs
2. Attach a multi-kprobe, multi-uprobe, or raw_tp BPF program that uses link data at runtime
3. Drop the last user-space reference to the bpf_link while BPF programs are still running
4. Trigger reuse of the freed link memory via another allocation or direct dereference inside the BPF program
5. Achieve memory corruption, information leak, or control-flow hijack inside the kernel

How to detect it

Search kernel logs and audit trails for KASAN or KMSAN reports mentioning bpf_link or bpf_link_free around the time of BPF program load or attach operations; review ftrace or perf events for unexpected multi-kprobe or raw_tp activity followed by kernel oops.

What your security team should do

• Prioritize patching production kernels that host BPF tracing or security programs within standard change windows
• Audit any custom BPF link implementations for proper use of deferred deallocation callbacks
• Monitor EPSS and KEV feeds; current score remains below 0.003 with zero trend and no known in-the-wild exploitation
• Restrict unprivileged BPF program loading via sysctl or LSM until systems are updated