GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel nvme-tcp: unserialized page_frag_cache corrupts page refcounts and panics the host

UnscoredCVE-2026-80862Kernel, userspace & hypervisorcurated

Impact

nvme-tcp preallocates a PDU per request out of a page_frag_cache, but block devices are created in parallel threads and the cache was used without serialization. That mis-counts backstore page references and frees pages early; the network stack catches it as a !sendpage_ok WARN in skb_splice_from_iter under nvme_tcp_try_send_cmd_pdu, followed by random panics. On GPU nodes that mount dataset, checkpoint or scratch volumes over NVMe/TCP, the trigger is parallel namespace setup - fleet boot, a storage controller failover, a mass reconnect - so many nodes can hit it in the same window. Pages freed while still queued for transmission are also a data-integrity concern, not only a crash.

Who can reach it

Local and self-inflicted: no attacker is required, the host's own concurrent NVMe/TCP namespace creation drives it. Exposure is to any node running the nvme-tcp initiator; it is not reachable from the storage network by a remote party.

What to do

Apply the stable kernel fix (linked commits, which serialize use of the page_frag_cache) and reboot every NVMe/TCP initiator node after draining it. No fixed release version is named in the record. Until then, serializing namespace/device creation rather than connecting many in parallel reduces the odds of hitting it but is not a fix.

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.