CVE-2025-40123

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Enforce expected_attach_type for tailcall compatibility<br /> <br /> Yinhao et al. recently reported:<br /> <br /> Our fuzzer tool discovered an uninitialized pointer issue in the<br /> bpf_prog_test_run_xdp() function within the Linux kernel&amp;#39;s BPF subsystem.<br /> This leads to a NULL pointer dereference when a BPF program attempts to<br /> deference the txq member of struct xdp_buff object.<br /> <br /> The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as the<br /> entry point for bpf_prog_test_run_xdp() and its expected_attach_type can<br /> neither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slot<br /> of a tailcall map it owns. progB&amp;#39;s expected_attach_type must be BPF_XDP_DEVMAP<br /> to pass xdp_is_valid_access() validation. The program returns struct xdp_md&amp;#39;s<br /> egress_ifindex, and the latter is only allowed to be accessed under mentioned<br /> expected_attach_type. progB is then inserted into the tailcall which progA<br /> calls.<br /> <br /> The underlying issue goes beyond XDP though. Another example are programs<br /> of type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as well<br /> as sock_addr_func_proto() have different logic depending on the programs&amp;#39;<br /> expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAME<br /> should not be allowed doing a tailcall into a program which calls bpf_bind()<br /> out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT.<br /> <br /> In short, specifying expected_attach_type allows to open up additional<br /> functionality or restrictions beyond what the basic bpf_prog_type enables.<br /> The use of tailcalls must not violate these constraints. Fix it by enforcing<br /> expected_attach_type in __bpf_prog_map_compatible().<br /> <br /> Note that we only enforce this for tailcall maps, but not for BPF devmaps or<br /> cpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() and<br /> cpu_map_bpf_prog_run*() which set up a new environment / context and therefore<br /> these situations are not prone to this issue.