CVE-2026-80669

What it actually does

A BPF LSM program can attach to the xfrm_decode_session hook which security_skb_classify_flow() invokes from a void return path, so any error return triggers BUG_ON() and a kernel panic.

Why it matters to the business

Systems can be crashed on demand by any user permitted to load BPF programs, producing denial of service, unplanned reboots, and loss of availability for workloads running on the host.

How an attack unfolds

An attacker with BPF loading rights compiles and loads an LSM program that attaches to xfrm_decode_session, returns an error on packet classification, and forces the kernel to hit the BUG_ON path during normal network flow processing.

How to fix it

Upgrade to a kernel release that disables BPF LSM attachment to xfrm_decode_session; restrict unprivileged BPF loading via sysctl or LSM policy until the fix is deployed.

How to confirm the fix worked

Inspect kernel source or running configuration to confirm the hook attachment is rejected; attempt to load an LSM program targeting the hook and verify the operation fails with an appropriate error.

Typical attack path

1. Obtain privileges to load BPF programs on the target host
2. Compile and pin a malicious LSM program that attaches to xfrm_decode_session
3. Return a non-zero error code from the hook
4. Trigger network traffic that causes security_skb_classify_flow to invoke the hook
5. Observe kernel panic and system reboot

How to detect it

Search kernel logs and crash dumps for BUG_ON messages originating from security_skb_classify_flow or xfrm_decode_session; review audit logs for recent BPF program loads that reference LSM attachment to network hooks.

What your security team should do

• Apply the kernel update that disables the hook attachment as soon as it is available
• Limit BPF program loading to trusted users or processes via existing access controls
• Monitor kernel logs for BUG_ON entries referencing xfrm_decode_session or security_skb_classify_flow