GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel BPF LSM: two hooks reachable in atomic context were allowed for sleepable programs

CVSS 8.8CVE-2026-63865Kernel, userspace & hypervisorcurated

Impact

bpf_lsm_task_to_inode() runs under rcu_read_lock() and bpf_lsm_inet_conn_established() runs in softirq context, yet both were listed as attachable by sleepable BPF LSM programs. A sleepable program attached to either hook can block where blocking is forbidden, which on a GPU node means a kernel crash or memory corruption that takes the whole host down - every tenant pod and every in-flight training job on that node with it. Exposure is narrow: loading a BPF LSM program needs privilege (CAP_BPF/CAP_SYS_ADMIN plus BPF LSM enabled in the kernel's lsm= list), so a fleet that does not hand tenants BPF loading rights or run a third-party eBPF security agent is not practically reachable here. The high NVD score reflects the privileged-local worst case, not a tenant-reachable path.

Who can reach it

Local, and effectively privileged: a user or agent that can load and attach sleepable BPF LSM programs (CAP_BPF plus a kernel built with BPF LSM active). Not reachable over the network and not reachable from an unprivileged tenant container.

What to do

Take the stable kernel update that drops both hooks from the sleepable allowlist (five stable branches carry the fix; the commits are linked in the record). Applying it means a kernel package update and a node reboot, so drain the node first. Interim mitigation if a reboot window is far off: audit which eBPF/LSM agents are permitted to load sleepable programs and keep BPF loading privileges off tenant workloads.

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.