GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel BPF: use-after-free freeing map elements that hold BPF timers

CVSS 7.8CVE-2024-41045Kernel, userspace & hypervisorcurated

Impact

Freeing a map element containing a BPF timer could free the bpf_hrtimer state, and with it the struct hrtimer, while that timer was still armed and enqueued - the RCU grace period expires before a far-future expiry fires. That is a kernel use-after-free on a timer the attacker controls the arming of, which is the shape of bug that turns BPF access into host root. On a GPU node this matters where BPF is reachable beyond the host admin: eBPF-based CNI and observability agents, and any workload granted CAP_BPF or privileged pods. The fix defers cancellation to the global workqueue rather than cancelling inline, which would deadlock. The record describes the mechanism but no public exploit.

Who can reach it

Local user or container able to load BPF programs and update BPF maps - in practice CAP_BPF/CAP_SYS_ADMIN in the init namespace, or a privileged pod. Not reachable by an unprivileged tenant pod on a node with default BPF restrictions, and not remote.

What to do

Update to a stable kernel carrying the fix (three stable commits linked; fixed in the 6.10 stable series per the record) and reboot each node. Mitigation in the meantime is to stop handing out CAP_BPF and privileged pods on shared GPU nodes and to confirm kernel.unprivileged_bpf_disabled is set; that is an admission-policy change rather than a reboot. Hosts running eBPF CNI or tracing agents still load BPF as root, so the patch is the real fix there.

References

Related entries

All Kernel, userspace & hypervisor entries

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.