GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel BPF: missing destination length check in bpf_crypto_crypt allows out-of-bounds write

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

Impact

The bpf_crypto_crypt() kfunc passed the source dynptr's length to the crypto backend without checking that the destination dynptr was at least as large, so a crafted BPF program could write past the end of the destination buffer in kernel memory. On a GPU node that means kernel heap corruption, which realistically ends in a host crash or privilege escalation from whatever context loaded the program - and a crashing GPU host takes its running jobs with it and is expensive to drain. The practical exposure is narrow: the upstream fix notes these kfuncs are reachable only with root privileges, so this is a hardening fix rather than a tenant-reachable escape. Fleets that let an agent or operator load BPF programs as root (CNI dataplanes, eBPF observability agents) are the ones that should care.

Who can reach it

Local, root-privileged: an actor able to load a BPF program that calls the crypto kfuncs. Not reachable from an unprivileged tenant pod, and not reachable over the network.

What to do

Take the stable kernel update containing the added src_len > dst_len check (commits linked in the record); there is no runtime mitigation other than not loading untrusted BPF. Applying it means a kernel package upgrade, so each GPU node has to be drained and rebooted - batch it with the next routine kernel window rather than opening one for this alone, given the root-only precondition.

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.