GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel BPF verifier: get_helper_proto dereferences a NULL helper function pointer when a config option is disabled

CVSS 7.8CVE-2025-39990Kernel, userspace & hypervisorcurated

Impact

Helper function pointers can be NULL when the config option backing them is not enabled, and get_helper_proto() did not check before use, so loading a program that references such a helper takes the verifier through a NULL pointer. The fix adds the check and marks the unused tail_call helper with BPF_PTR_POISON. This was found by the kernel test robot, and the exposure depends on the kernel build: only configurations that compile out a helper's backing feature are affected, which is why many distribution kernels will not reach it. Where it is reachable, the consequence is a kernel oops at program-load time - a node-wide availability event on a GPU host whose BPF load path is also used by the CNI and by observability agents, with no data-disclosure claim in the record.

Who can reach it

Local. Requires the ability to load a BPF program - CAP_BPF or CAP_SYS_ADMIN, so a privileged container or a node agent rather than an ordinary unprivileged tenant - on a kernel built with the relevant helper's config option disabled.

What to do

Pick up the stable kernel carrying the get_helper_proto validity check (three backports linked) at the next kernel maintenance; drain and reboot per node. Check whether your kernel build actually disables the affected helper config before prioritising. Restricting CAP_BPF to trusted node agents is the standing mitigation and already keeps most tenants out of this path.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.