Linux kernel BPF: clearing a large PROG_ARRAY map stalls RCU and can hang the CPU

CVSS 5.5CVE-2026-53083Kernel, userspace & hypervisorcurated

Impact

bpf_fd_array_map_clear() loops over every entry of a program array calling prog_array_map_poke_run() per entry, with no cond_resched(). For a PROG_ARRAY with many entries this runs long enough in a workqueue (prog_array_map_clear_deferred) to starve the RCU grace-period kthread, producing RCU stall splats and, under load, a wedged CPU. The exposure on a GPU fleet is the observability and networking tooling, not tenants: Cilium, BPF-based tracing agents and security agents create and tear down program arrays, and a stall here is a kernel-side hang on a node you then have to drain and reboot rather than just restart a daemon.

Who can reach it

Local only, and privileged: the caller needs the ability to create and destroy BPF program array maps, i.e. CAP_BPF/CAP_SYS_ADMIN in the host namespace. An ordinary tenant pod without BPF capabilities cannot reach it. Realistically this triggers as a crash in privileged node agents rather than as tenant-driven abuse.

What to do

Pick up the stable kernel fix that adds the missing cond_resched() in the clear loop (commits linked from the NVD record). Deploying it is a kernel upgrade: drain the node and reboot it. The record names no fixed release version. As an interim measure, keep PROG_ARRAY sizes modest in privileged BPF agents on nodes where an RCU stall would be expensive.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-53083 https://git.kernel.org/stable/c/419878a48085e6d5c2fcc4912eeaac2f8abf36ed https://git.kernel.org/stable/c/4406942e65ca128c56c67443832988873c21d2e9

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.