GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel nvmet-auth: uninitialized slab sent to a remote initiator during NVMe-oF authentication

UnscoredCVE-2026-80791Kernel, userspace & hypervisorcurated

Impact

nvmet_execute_auth_receive() sizes the response buffer with kmalloc() from the host-supplied AUTH_RECEIVE allocation length, but the DH-HMAC-CHAP builders write only a fixed-size message into it. The whole allocation is then copied to the wire, so the initiator receives whatever was in the slab past the built message - up to nearly a page of uninitialized kernel memory per exchange. This happens during the pre-authentication handshake, so the peer does not need to hold valid credentials to collect it. Repeated connects give an attacker a sampling channel into target kernel slab contents, which is the kind of leak that turns a separate memory-corruption bug into a working exploit against the storage node your GPU fleet reads from.

Who can reach it

Any peer that can reach the NVMe-oF target portal and start a Fabrics connect with DH-HMAC-CHAP. The leak occurs before authentication completes, so no valid credentials are needed.

What to do

Apply the stable kernel fix on target nodes; it switches the allocation to kzalloc() so the unwritten tail is zeroed. Kernel change, so patched target nodes need a reboot unless livepatched. Conforming responses are unaffected, so there is no functional risk in taking it. In the meantime, limiting who can reach the target portal is the only mitigation - disabling in-band auth does not help, since the leak is in the auth path an initiator can invoke.

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.