GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel io_uring zero-copy receive: desc->count underflow lets a recv overshoot its limit

CVSS 8.6CVE-2025-40046Kernel, userspace & hypervisorcurated

Impact

io_zcrx_recv_skb() adjusts desc->count for every received buffer including frag lists, then recurses to process the frag list skbs, so the count is accounted twice and underflows. A zero-copy receive request can then deliver more data than was requested, writing past the length the application reserved. Exposure depends on io_uring zero-copy receive actually being in use: it is a recent, opt-in path that a tenant process must set up itself, so a node whose workloads do not use zcrx is not reachable here. Where it is used - high-throughput ingest or storage front ends on GPU nodes - a local process driving its own zcrx socket can corrupt its own receive accounting, and the record gives availability impact as high.

Who can reach it

A local process that can create io_uring zero-copy receive requests, combined with the remote peer's segmentation producing frag lists. No authentication beyond having the ability to run code on the node and use io_uring; unreachable if io_uring zcrx is disabled or unused.

What to do

Take the stable kernel update carrying commits 09cfd3c52ea7 / 8bcc9eaf1b19. That means drain and reboot each affected node - expensive on a GPU host mid-training, so schedule it with your next kernel window unless you actively run io_uring zero-copy receive workloads. Interim mitigation is to keep io_uring restricted (for example via the io_uring_disabled sysctl or seccomp) for untrusted tenants, which also covers the rest of this subsystem's history.

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.