GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel nvmet: NULL dereference when a host issues Identify CNS 07h against an NVMe-oF target

UnscoredCVE-2026-80813Kernel, userspace & hypervisorcurated

Impact

nvmet_execute_identify_nslist() with match_css set dereferences req->ns to filter by command set, but the handler never calls nvmet_req_find_ns(), so req->ns is always NULL. As soon as the target has an enabled namespace with an NSID above the requested value, a single Identify command with CNS 07h oopses the target. The comparison was also logically wrong - it needed the command set of the namespace being iterated, not one fixed value. For an operator this is a remote crash of the NVMe-oF target node from a connected host, taking storage away from every node attached to it; a GPU cluster with jobs mid-checkpoint against that target loses them.

Who can reach it

A connected NVMe-oF host that can submit admin commands to the target - one Identify command with CNS 07h. Requires a completed Fabrics connect, which needs no authentication in the default configuration.

What to do

Take the stable kernel fix on target nodes; it uses the loop variable ns->csi instead of the never-populated req->ns. Kernel change, so each target node reboots onto the patched kernel unless livepatched. There is no runtime toggle for this - a host is free to send CNS 07h - so restricting which initiators can reach the portal is the only interim control.

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.