GPU VulnDB

Database/Firmware, BMC & network fabric

Linux kernel NVMe-oF TCP target (nvmet-tcp, H2C_DATA PDU before CONNECT): Nvmet_tcp_build_pdu_iovec() dereferences cmd

CVSS 7.5CVE-2026-22998Firmware, BMC & network fabriccurated

Impact

Nvmet_tcp_build_pdu_iovec() dereferences cmd->req.sg and cmd->iov without checking they were ever initialised. Sending an H2C_DATA PDU straight after the ICREQ/ICRESP handshake - before any CONNECT command, before any NVMe-level identification of the initiator - reaches that dereference and crashes the target. This is genuinely pre-authentication: the only thing the attacker completes is the transport handshake, and the payoff is taking down the storage target for every tenant it serves.

Who can reach it

Remote, fully unauthenticated, immediately after TCP connect and the NVMe/TCP ICREQ exchange. No host NQN, no DH-HMAC-CHAP, nothing.

What to do

Kernel update adding the NULL checks before processing H2C_DATA. Because it is pre-auth, in-band authentication does not help you here - the compensating control is network reachability: the nvmet listener must not be reachable from tenant-routable networks, only from the storage fabric.

References

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=32b63acd78f577b332d976aa06b56e70d054cbbahttps://git.kernel.org/pub/scm/linux/security/vulns.git/tree/cve/published/2026/CVE-2026-22998.json

Related entries

All Firmware, BMC & network fabric 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.