Re: [PATCH] nvmet-rdma: fix out-of-bounds write in nvmet_rdma_map_sgl_inline()

From: Keith Busch

Date: Wed Oct 21 2026 - 18:34:55 EST


On Wed, Oct 21, 2026 at 01:07:48AM -0400, Andrew Stellman wrote:
> nvmet_rdma_map_sgl_inline() bounds the host-supplied in-capsule SGL
> offset with "off + len > inline_data_size", evaluated in 64-bit
> arithmetic. off is taken straight from the host SGL descriptor
> (le64_to_cpu(sgl->addr)) and len is promoted to 64-bit, so the sum
> wraps: an off within len of 2^64 makes it small and the check passes.
> off is then used as page_idx = off / PAGE_SIZE to index the fixed-size
> rsp->cmd->inline_sg[] array (NVMET_RDMA_MAX_INLINE_SGE entries), so a
> crafted offset yields an out-of-bounds scatterlist index that is written
> through in nvmet_rdma_use_inline_sg().
>
> The mapping runs while handling a received capsule, before the command
> executes, so a remote RDMA peer can reach it (the Connect capsule is a
> write and takes this path on a queue that has no controller yet). The
> host controls only the low bits of the resulting displacement, so the
> expected impact is an out-of-bounds write that faults the target
> (remote denial of service).
>
> This wrap was reported, with a KASAN reproduction, on linux-nvme in May,
> and the check below was suggested in that thread. The fix that was
> applied, 48c0162f647b, reworked how the offset is mapped but kept the
> original check, and its page index turns a wrapped offset into an
> out-of-bounds index into inline_sg[].
>
> Reject the offset before it can wrap.
>
> Found independently by static analysis with AI assistance, not
> reproduced at runtime.
>
> Fixes: 0d5ee2b2ab4f ("nvmet-rdma: support max(16KB, PAGE_SIZE) inline data")
> Fixes: 48c0162f647b ("nvmet-rdma: handle inline data with a nonzero offset")
> Reported-by: Bryam Vargas <hexlabsecurity@xxxxxxxxx>
> Closes: https://lore.kernel.org/all/LM21QIR-1-qJb7PViyJKCnGBnUzizeiNJVWQ3wb7ZwGezodjgKg3f-iobqOyequ-sT1jFCKJImfqNO_BKU3KO80xFITnaI5GTV_GxLUNDDc=@proton.me/
> Suggested-by: Keith Busch <kbusch@xxxxxxxxxx>
> Cc: stable@xxxxxxxxxx

Should be @vger.kernel.org.

Thanks, applied to nvme-7.4 with the above email fixed.