Linux kernel BPF verifier: callback reference accounting lets a program leak or double-release kernel references

CVSS 7.8CVE-2022-50650Kernel, userspace & hypervisorcurated

Impact

The verifier modelled for_each-style helper callbacks as if they ran exactly once, so a program whose callback acquires or releases a reference was accepted even though the callback actually runs many times. The result is leaked or multiply-released kernel object references from a program the verifier declared safe - memory exhaustion in the leak case, and reference-count corruption with the usual escalation potential in the release case. On a GPU fleet this sits in the path of anything that loads BPF on the host: CNI dataplanes, service mesh, tracing and profiling agents. Exploitation needs the ability to load a BPF program, so the practical exposure is a container that has been granted CAP_BPF/CAP_SYS_ADMIN, or an operator-run agent, not an ordinary tenant pod.

Who can reach it

Local, authenticated, and requires BPF load privilege (CAP_BPF or CAP_SYS_ADMIN, or unprivileged BPF enabled, which is off by default on current kernels). Not reachable from a tenant pod with a default container profile.

What to do

Update to a fixed stable kernel (commits in the record) and reboot the node; verifier changes ship in the kernel image, so each GPU node has to be drained and rebooted. Until then, confirm kernel.unprivileged_bpf_disabled is set and that no tenant workload holds CAP_BPF or CAP_SYS_ADMIN.

References

https://nvd.nist.gov/vuln/detail/CVE-2022-50650 https://git.kernel.org/stable/c/9d9d00ac29d0ef7ce426964de46fa6b380357d0a https://git.kernel.org/stable/c/caa176c0953cdfd5ce500fb517ce1ea924a8bc4c

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.