Wind River Support Network

Description

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

========Wind River Notice========

To backport the fix might break current common BPF code due to context changes.

 

*Mitigation:*

The default WindRiver Linux kernel prevents unprivileged users from being able to use eBPF by the kernel.unprivileged_bpf_disabled sysctl. This would require a privileged user with CAP_SYS_ADMIN or root to be able to abuse this flaw reducing its attack space.

For the WindRiver Linux to confirm the current state, inspect the sysctl with the command:

cat /proc/sys/kernel/unprivileged_bpf_disabled

The setting of 1 would mean that unprivileged users can not use eBPF, mitigating the flaw.

 

 

CVEs

• CVE-2025-40123