GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel bpf: fork bailout frees an uninitialized task->bpf_storage, causing UAF or hang

CVE-2026-72110Kernel, userspace & hypervisorcurated

Impact

If copy_process() bails out early - the described case is the RLIMIT_NPROC check failing - free_task() calls bpf_task_storage_free() on a ->bpf_storage pointer that is still a raw copy of the parent's, so the kernel tears down storage it does not own. The commit message reports kernel hangs and use-after-free. Reachability is gated on the forking process being present in a BPF task storage map, which is precisely what fleet observability and runtime-security agents put processes into, so nodes running that class of tooling are the exposed ones. The practical outcome on a GPU node is an unplanned host hang that takes every attached GPU with it; a use-after-free on task storage also cannot be ruled out as an escalation primitive from what the record states.

Who can reach it

Local and unprivileged. An attacker needs code execution on the host kernel (a tenant container is enough) and needs to be inside a BPF task storage map - which a privileged agent does to processes on its own, not something the attacker must arrange. Driving fork() into the process-limit failure needs no privileges.

What to do

Update to a stable kernel with the fix that wipes ->bpf_storage in dup_task_struct() before any bailout path can free it (five stable commits linked) and reboot. Interim mitigation that actually removes reachability: stop or unload BPF agents that use task local storage maps on the node - if no process is in a task storage map, the path is not reachable. Full fix is a drain-and-reboot per node.

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.