Re: [PATCH] nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU

Keith Busch <[email protected]>
Newsgroups org.kernel.vger.stable,org.infradead.lists.linux-nvme
Message-ID <aozo4lBg1fhoojdP@kbusch-mbp>
On Fri, Aug 14, 2026 at 03:48:11PM -0400, Shivam Kumar wrote:
> 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.

Thanks, applied to nvme-7.3.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.