Linux kernel bpf_link: freed too early while attached programs still dereference it

CVSS 5.5CVE-2024-35860Kernel, userspace & hypervisorcurated

Impact

Some BPF program types receive their bpf_link as a runtime context and dereference it to look up data such as BPF cookies. Before this fix the link could be deallocated as soon as its refcount hit zero, while BPF programs attached through multi-kprobe, multi-uprobe or raw tracepoints were still executing and reading it - a use-after-free in kernel context. The fix defers dealloc until after an RCU grace period (RCU tasks trace first for sleepable programs). On a GPU node this matters because tracing-based observability and eBPF networking agents attach and detach these links continuously; a use-after-free in that path crashes or corrupts the host kernel, taking every tenant pod on the node with it. Reaching it requires the ability to load and attach BPF programs, so on a node where only the operator's agents hold CAP_BPF the practical exposure is a stability bug rather than a tenant escape.

Who can reach it

Local, authenticated: a process able to load and attach BPF programs (CAP_BPF/CAP_SYS_ADMIN, or root in a privileged container) that races detach against program execution. Unprivileged tenant pods without BPF capabilities cannot reach it.

What to do

Take the stable kernel update containing the fix for your series (commits linked in the record); no configuration mitigation exists other than not granting BPF load/attach rights. Applying it means a kernel update and a reboot, so drain the node and reboot it during a maintenance window.

References

https://nvd.nist.gov/vuln/detail/CVE-2024-35860 https://git.kernel.org/stable/c/1a80dbcb2dbaf6e4c216e62e30fa7d3daa8001ce https://git.kernel.org/stable/c/ac48dc6ac9240f73bf08d29edf65c2deca93ee5d

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.