CVE-2026-89969
nicheOut-of-bounds kernel write in Linux nvmet-tcp target via over-long PDU
The Linux kernel's NVMe/TCP target transport (nvmet-tcp) reads incoming PDU headers into a fixed 128-byte buffer without validating the declared PDU length, allowing a 4-byte out-of-bounds write. A remote, unauthenticated host that connects to an NVMe/TCP target and negotiates header digests can send a duplicate ICReq PDU, causing 124 attacker-controlled bytes to be written at offset 8 of the 128-byte union and spilling 4 bytes over its end into adjacent kernel memory (queue->hdr_digest and queue->data_digest); the duplicate ICReq is only rejected after the overflow has occurred. This corrupts kernel memory adjacent to the receive buffer, matching the critical CVSS 9.8 rating (network vector, no privileges, high C/I/A impact), though no public proof-of-concept is known and the flaw is not listed in CISA KEV. Only systems running a Linux kernel with the nvmet-tcp target enabled and reachable over the network are affected. The upstream fix rejects any PDU whose declared length would read past the end of the receive buffer before performing the second read.
What to do: Update the kernel to a release or distro package containing the upstream nvmet-tcp fix (the commit that rejects PDUs whose declared length exceeds sizeof(queue->pdu)) and rebuild/reboot affected storage nodes. Until patched, firewall TCP port 4420 so only trusted NVMe initiators can reach the target, since the attack requires no authentication and only needs the ability to open a connection and send a crafted duplicate ICReq. Check whether your kernels enable the NVMe target TCP transport (CONFIG_NVME_TARGET_TCP, e.g. via nvmetcli or /sys/kernel/config/nvmet) to determine if you are exposed at all.
| Linux kernel nvmet-tcp (NVMe over Fabrics TCP target transport, CONFIG_NVME_TARGET_TCP) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU nvmet_tcp_try_recv_pdu() reads a PDU header into the fixed 128-byte queue->pdu union, then computes the remaining payload length as queue->left = hdr->hlen - queue->offset + hdgst; and reads that many more bytes into &queue->pdu + queue->offset, without ever bounding the result against sizeof(queue->pdu). A struct nvme_tcp_icreq_pdu is itself 128 bytes, exactly the size of the union. Once a header digest has been negotiated (hdgst = 4), a second ICReq passes the hlen == nvmet_tcp_pdu_size() check but yields queue->left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the 128-byte buffer -- 4 bytes past its end, over queue->hdr_digest and queue->data_digest. Those bytes are attacker-controlled (an ICReq carries no digest), and the duplicate ICReq is only rejected later, after the overflow. A remote unauthenticated host can thus corrupt kernel memory adjacent to the receive buffer. Reject any PDU whose declared length would read past the end of queue->pdu before the second recv.
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.