GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux BPF LSM: attaching to xfrm_decode_session turns packet classification into a kernel panic

CVE-2026-80669Kernel, userspace & hypervisorcurated

Impact

BPF LSM programs could attach to the xfrm_decode_session hook. That hook is allowed to return an error, but security_skb_classify_flow() calls it from a void path and hits BUG_ON when it does - so a BPF LSM program returning non-zero panics the host on the next packet classified through that path. This matters on fleets that run eBPF security or networking agents on every node: a policy change rolled out cluster-wide is a cluster-wide panic, and GPU nodes with in-flight training jobs lose the whole job, not just a pod. The fix disables attachment to the hook outright rather than making the return value safe.

Who can reach it

Local and privileged - loading a BPF LSM program requires CAP_BPF/CAP_SYS_ADMIN and a kernel built with CONFIG_BPF_LSM. The realistic path is an operator-installed eBPF agent or a compromised privileged DaemonSet, not an ordinary tenant pod.

What to do

Fixed in the mainline Linux kernel BPF code by refusing attachment to the hook; take the distro kernel update and reboot the node. Until then, audit which BPF LSM programs your node agents attach and confirm none targets xfrm_decode_session. The record names no fixed release version, only the stable commits.

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.