GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel list_lru: missing RCU read lock allows use-after-free of a freed memory cgroup

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

Impact

list_lru called mem_cgroup_from_slab_obj() without holding the RCU read lock or cgroup_mutex, so the memcg it returns can be freed concurrently and then dereferenced. On a GPU node this is core-kernel code every container touches: memcg-accounted slab objects are created and reclaimed constantly by the cgroup hierarchy that Kubernetes puts each tenant pod in, and cgroup teardown on pod churn is exactly when a memcg gets freed. A successful exploit is a kernel use-after-free with host-wide consequences - a crash that takes every GPU job on the node down, or in the worst case memory corruption leading to privilege escalation out of a container. The upstream commit notes the bug was found by code inspection, so there is no public report of a triggerable path; treat the exploitability as unproven and the hygiene fix as the point.

Who can reach it

Local. Any workload that can allocate memcg-accounted slab objects and drive cgroup creation/teardown - which includes any tenant with a container on the node - is in the right position; no special capability or device access is named in the record. No remote or network path.

What to do

Pick up the fixed stable kernel (commits 4589f77c18dd and 5161b48712dc) and reboot each node. There is no runtime mitigation and no module to reload - the fix is in core mm, so it ships only with a new kernel. Fold it into the next scheduled kernel rollout rather than an emergency window unless you have local untrusted tenants and a low tolerance for host crashes.

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.