Linux kernel BPF: tailcalls ignore expected_attach_type, yielding NULL deref and bypassed context checks

Impact

__bpf_prog_map_compatible() checked only bpf_prog_type, not expected_attach_type, so a program could tailcall into another program of the same type whose attach type unlocks different context access or helpers. The reported case is an XDP program tailcalling into a BPF_XDP_DEVMAP program that dereferences xdp_buff->txq, which is uninitialized under bpf_prog_test_run_xdp() and gives a NULL pointer dereference and node panic. The same shape applies to CGROUP_SOCK_ADDR, where a getpeername program could tailcall into code calling bpf_bind(), reaching functionality its own attach type was supposed to deny. On a GPU node the immediate cost is an unplanned crash that kills every running job on the host; the broader cost is that attach-type-based restrictions inside the BPF verifier cannot be relied on.

Who can reach it

Local user or container able to load BPF programs and populate a tailcall map - CAP_BPF plus the relevant network capability, or root. Not reachable over the network, and not reachable from a tenant GPU pod unless BPF loading has been delegated to it.

What to do

Update to a stable kernel carrying the referenced commits, which enforces expected_attach_type for tailcall maps, then drain and reboot each node. Devmap and cpumap program invocation is unaffected and needs no change. Until the reboot window, do not grant BPF loading capabilities to untrusted workloads. The record lists stable commits only, no fixed version string.

References

Related entries

• Linux kernel SMC: dst entry can be freed under smc_clc_prfx_set during connect(), a local UAFCVE-2025-40139 · Linux kernel SMC protocol (smc_clc_prfx_set destination cache use-after-free)High
• Linux kernel (net/tls): The kTLS device-offload setup resolved the socket's netdevice outside RCU, so the net_device itCVE-2025-40149 · Linux kernel (net/tls)High
• Linux kernel (virt/kvm): Unbinding a memslot from a guest_memfd was skipped once the file was already dying, so if theCVE-2025-40274 · Linux kernel (virt/kvm)High
• Linux kernel (drivers/gpu/drm/vmwgfx): The vmwgfx command-buffer parser trusted a size field taken straight from theCVE-2025-40277 · Linux kernel (drivers/gpu/drm/vmwgfx)High
• VMware Aria Operations / VMware Tools: Local privilege escalation to root inside a managed VM via SDMP service discoveryCVE-2025-41244 · VMware Aria Operations / VMware ToolsHigh
• PAM (pam-config): Local user is treated as `allow_active` in PAMCVE-2025-6018 · PAM (pam-config)High