GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel BPF inode storage: map creation without BPF LSM initialized panics the host on RCU callback

CVE-2026-64192Kernel, userspace & hypervisorcurated

Impact

On a kernel built with CONFIG_BPF_LSM=y but booted without bpf in the lsm= list, the BPF inode security blob offset is never initialized, so a BPF inode-storage map writes into the inode's queued rcu_head.func pointer instead of its own slot. Clearing that pointer during map or inode teardown leaves RCU with a NULL callback, and rcu_do_batch() later fetches an instruction at address 0x0: an immediate, unrecoverable kernel panic. On a GPU node that is an unscheduled host crash that takes every training and inference pod on the box with it, and the node comes back only after a full boot. This is not tenant-reachable: creating the map needs privilege, so the realistic trigger is a root-level eBPF agent (observability, runtime security, CNI) landing on a host whose lsm= boot line does not include bpf.

Who can reach it

Local privileged process on the host (CAP_BPF/CAP_SYS_ADMIN) that creates and updates a BPF_MAP_TYPE_INODE_STORAGE map. Not reachable from an unprivileged tenant pod. Only affected when the kernel has CONFIG_BPF_LSM=y and 'bpf' is absent from the lsm= boot parameter.

What to do

Take the fixed stable kernel (see the git.kernel.org commits) and reboot each node; there is no userspace-only fix, so this rides your normal drain-and-reboot rotation rather than needing its own window. Until then the exposure can be removed by adding bpf to the lsm= boot parameter (also a reboot) or by not running node agents that allocate inode-storage maps on hosts with that config.

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.