CVE-2025-40123

In the Linux kernel, the following vulnerability has been resolved:

bpf: Enforce expectedattachtype for tailcall compatibility

Yinhao et al. recently reported:

Our fuzzer tool discovered an uninitialized pointer issue in the bpfprogtestrunxdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object.

The test initializes two programs of BPFPROGTYPEXDP: progA acts as the entry point for bpfprogtestrunxdp() and its expectedattachtype can neither be of be BPFXDPDEVMAP nor BPFXDPCPUMAP. progA calls into a slot of a tailcall map it owns. progB's expectedattachtype must be BPFXDPDEVMAP to pass xdpisvalidaccess() validation. The program returns struct xdpmd's egressifindex, and the latter is only allowed to be accessed under mentioned expectedattachtype. progB is then inserted into the tailcall which progA calls.

The underlying issue goes beyond XDP though. Another example are programs of type BPFPROGTYPECGROUPSOCKADDR. sockaddrisvalidaccess() as well as sockaddrfuncproto() have different logic depending on the programs' expectedattachtype. Similarly, a program attached to BPFCGROUPINET4GETPEERNAME should not be allowed doing a tailcall into a program which calls bpfbind() out of BPF which is only enabled for BPFCGROUPINET4_CONNECT.

In short, specifying expectedattachtype allows to open up additional functionality or restrictions beyond what the basic bpfprogtype enables. The use of tailcalls must not violate these constraints. Fix it by enforcing expectedattachtype in _bpfprogmapcompatible().

Note that we only enforce this for tailcall maps, but not for BPF devmaps or cpumaps: There, the programs are invoked through devmapbpfprogrun() and cpu_map_bpf_prog_run() which set up a new environment / context and therefore these situations are not prone to this issue.