Re: [PATCH 4/4] nvme: clamp FDP placement handle count to the buffer size

Kanchan Joshi <[email protected]> Thu, 30 Jul 2026 15:10:59 +0530
Newsgroups org.infradead.lists.linux-nvme
Message-ID <[email protected]>
On 7/30/2026 10:01 AM, Guixin Liu wrote:
> nvme_query_fdp_info() allocates the RUH status buffer for at most
> S8_MAX - 1 descriptors and caps the io-mgmt-receive transfer to that
> size. head->nr_plids, however, is taken verbatim from the device-supplied
> nruhsd field, which can be up to 65535. If a non-conformant or malicious
> device reports more descriptors than the buffer holds, the copy loop
> reads past the end of the ruhs buffer (heap out-of-bounds read).
> 
> Clamp nr_plids to the number of descriptors the buffer can actually hold.
> 
> Fixes: 30b5f20bb2dd ("nvme: register fdp parameters with the block layer")
> Signed-off-by: Guixin Liu<[email protected]>
> ---
>   drivers/nvme/host/core.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index 453c1f0b2dd0..b1f444cd3daf 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -2358,6 +2358,7 @@ static int nvme_query_fdp_info(struct nvme_ns *ns, struct nvme_ns_info *info)
>   	}
>   
>   	head->nr_plids = le16_to_cpu(ruhs->nruhsd);
> +	head->nr_plids = min_t(u16, head->nr_plids, S8_MAX - 1);

Given what we have at this point, the fix is fine.

Reviewed-by: Kanchan Joshi <[email protected]>

But I feel the need to improve (what we have) with a follow-up patch:
1. Revise the cap, from S8_MAX - 1 to U8_MAX; since bio->bi_write_hint 
is u8.
2. And a dev_warn() to know if head->nr_plids go above the 
kernel-defined cap. It's possible/fine for device to have more placement 
ids, and if that happens, this can tell.

Keith, Christoph - thoughts?