Linux kernel BPF verifier: map-in-map lookup nullness elided using the wrong max_entries

CVE-2026-64353Kernel, userspace & hypervisorcurated

Impact

An ARRAY_OF_MAPS built on a BPF_F_INNER_MAP template can have the template replaced at runtime by a concrete inner array with a different max_entries. The verifier still reasoned about the inner map using the template, so its const-key nullness elision concluded a lookup could not return NULL, while the runtime helper bounds-checks against the smaller concrete map and returns NULL. The program then dereferences a pointer the verifier promised was non-NULL - a kernel oops, scored AV:L/PR:L with availability impact only. On a GPU node this is a node-availability bug rather than a tenancy bug: BPF map-in-map is loaded by the CNI dataplane and observability agents that sit on every node, so a crash takes down the host and every GPU pod on it. The fix stops eliding nullness for maps flagged BPF_F_INNER_MAP.

Who can reach it

Local: a user or workload able to load BPF programs and create map-in-map objects - CAP_BPF/CAP_SYS_ADMIN, or any context where unprivileged BPF is enabled. An ordinary unprivileged GPU pod cannot reach this unless it has been granted BPF capabilities.

What to do

Take the stable kernel update with the verifier fix (d57db0d97505 and backports), then drain and reboot each node. As an interim control, confirm kernel.unprivileged_bpf_disabled is set and that no tenant workload holds CAP_BPF or CAP_SYS_ADMIN.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-64353 https://git.kernel.org/stable/c/d57db0d975053e01410c54e708a85b6d32ef2ebd https://git.kernel.org/stable/c/0b92ad64d6e4bde85e6b9888404f9a7a2b65d269 https://git.kernel.org/stable/c/53040a81ae57cdca8af8ac36fe4e661730cf7c6b

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.