Database/Kernel, userspace & hypervisor
Linux kernel list_lru: missing RCU read lock allows use-after-free of a freed memory cgroup
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
- QEMU (qemu-img): `qemu-img info` on an untrusted qcow2 image reaches arbitrary host file read/writeCVE-2024-4467 · QEMU (qemu-img)High
- Linux kernel (drivers/gpu/drm/xe): Freeing a scheduler job dereferences the VM it belongs to, but the final exec-queueCVE-2024-44978 · Linux kernel (drivers/gpu/drm/xe)High
- Linux kernel mlx5_core TX timeout devlink health reporter: The TX timeout recovery path runs without the state lock, soCVE-2024-45019 · Linux kernel mlx5_core TX timeout devlink health reporterHigh
- Arm Mali GPU kernel driver: Use-after-free in the Bifrost/Valhall GPU kernel driverCVE-2024-4610 · Arm Mali GPU kernel driverHigh
- Linux kernel (drivers/gpu/drm/xe): The preempt-fence lock lives inside the exec queue, but the queue reference isCVE-2024-46683 · Linux kernel (drivers/gpu/drm/xe)High
- Linux kernel (drivers/pci): Pci_bus_lock() locked every device on the bus except the bridge itself, so a secondary busCVE-2024-46750 · Linux kernel (drivers/pci)High
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.