GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel bpf: reused slab objects leave htab special fields stale, causing hard lockup

CVSS 7.8CVE-2023-53790Kernel, userspace & hypervisorcurated

Impact

Elements freed into the BPF memory allocator can be reused immediately; for non-preallocated hash maps the reuse reinitializes special fields such as bpf_spin_lock while a concurrent lookup is still reading them. The reported outcome is a hard lockup inside queued_spin_lock_slowpath reached from the bpf map lookup syscall path. On a node running an eBPF dataplane or eBPF observability agents, a wedged CPU means the host stops scheduling work and every tenant pod on it dies with no graceful drain.

Who can reach it

Local user able to create and operate non-preallocated BPF hash maps with special fields - CAP_BPF or root in the initial namespace, or a privileged agent container. Unprivileged BPF is disabled by default on most distributions, which narrows this considerably.

What to do

Update to a stable kernel carrying the __GFP_ZERO fix in the BPF allocator (commits 5d447e04290e, 678ea18d6240, 997849c4b969) and reboot the node. Until then, keep unprivileged BPF disabled (kernel.unprivileged_bpf_disabled=1) and limit which workloads hold CAP_BPF.

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.