[PATCH 0/5] nvme: validate and decode controller supplied values

[PATCH 0/5] nvme: validate and decode controller supplied values

[shao.mingyin]

This series adds missing validation and endian decoding for values that
come from a controller, a backing controller or a user request.

Patch 1 rejects an invalid ZASL from the controller.  nvme_set_max_append()
shifts 1 by zasl + 3; a value of 29 or more shifts a 32-bit value by 32 or
more, and the old code also used a signed int for the shift.

Patch 2 maps the user data buffer whenever the ioctl length is non-zero,
not only when the user address is non-zero.  With addr 0 and a non-zero
length the command was submitted without a data buffer, and the target
rejected it with an invalid SGL status instead of the host rejecting the
user buffer.

Patch 3 rejects an Identify Namespace from a passthrough backing
controller whose nlbaf does not fit the 64-entry LBA format table.  The
old loop cleared fields past the table and returned an inconsistent
Identify structure.

Patch 4 decodes the FDP Get Features result as the little-endian dword
the controller returns, instead of passing a four-byte structure to the
u32 result pointer and reading it in host byte order.

Patch 5 bounds the reservation report retry loop.  A target that keeps
changing the registrant count made the ioctl loop forever, allocating a
full status buffer on every iteration.

The five patches are independent and can be applied in any order.  All
carry Fixes: and Cc: stable.

Testing: all apply to next-20261105, pass checkpatch.pl --strict with
0 errors/0 warnings/0 checks, and zns.c, ioctl.c, passthru.c, core.c
and pr.c build with the corresponding options under W=1.  Each patch's
--- notes describe its QEMU/TCG A/B test with a test-only target hook;
no hardware was used.

Shao Mingyin (5):
  nvme: zns: reject an out-of-range zone append size limit
  nvme: map passthrough data when the length is nonzero
  nvmet: validate the LBA format count of a passthrough namespace
  nvme: decode the FDP Get Features result as a dword
  nvme: bound the reservation report retry loop

 drivers/nvme/host/core.c       |  6 +++---
 drivers/nvme/host/ioctl.c      |  2 +-
 drivers/nvme/host/pr.c         |  4 +++-
 drivers/nvme/host/zns.c        | 11 ++++++++---
 drivers/nvme/target/passthru.c |  5 +++++
 5 files changed, 20 insertions(+), 8 deletions(-)

---
base-commit: ddfe51b0a0f5dc9e415cc2c8ad8db17532dd426b

Re: [PATCH 4/5] nvme: decode the FDP Get Features result as a dword

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [Medium] nvme: uninitialized stack memory use in
  nvme_query_fdp_granularity() [1]
--

commit 37e4c911db178216572cd8ee6fd19cfc2f58c7f0
Author: Shao Mingyin <shao.mingyin@zte.com.cn>

nvme: decode the FDP Get Features result as a dword

This commit changes nvme_query_fdp_info() to read the NVME_FEAT_FDP Get
Features result as a u32 and decode the flags and FDP configuration index
manually so that FDP probing works on big-endian hosts.

> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index a7a4d09644c13..45feafa003257 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -2339,8 +2339,8 @@ static int nvme_query_fdp_info(struct nvme_ns *ns, struct nvme_ns_info *info)
>  	struct nvme_ns_head *head = ns->head;
>  	struct nvme_ctrl *ctrl = ns->ctrl;
>  	struct nvme_fdp_ruh_status *ruhs;
> -	struct nvme_fdp_config fdp;
>  	struct nvme_command c = {};
> +	u32 fdp;
>  	size_t size;
>  	int i, ret;
>  
> @@ -2351,10 +2351,10 @@ static int nvme_query_fdp_info(struct nvme_ns *ns, struct nvme_ns_info *info)
>  		return ret;
>  	}
>  
> -	if (!(fdp.flags & FDPCFG_FDPE))
> +	if (!(fdp & FDPCFG_FDPE))
>  		return 0;
>  
> -	ret = nvme_query_fdp_granularity(ctrl, info, fdp.fdpcidx);
> +	ret = nvme_query_fdp_granularity(ctrl, info, (fdp >> 8) & 0xff);

[Severity: Medium]
This problem wasn't introduced by this patch, but can
nvme_query_fdp_granularity() read uninitialized stack memory from hdr.sze
[1]?

drivers/nvme/host/core.c:nvme_query_fdp_granularity() {
	struct nvme_fdp_config_log hdr, *h;
	...
	ret = nvme_get_log_lsi(ctrl, 0, NVME_LOG_FDP_CONFIGS, 0,
			       NVME_CSI_NVM, &hdr, size, 0, info->endgid);
	if (ret) {
		...
		return ret;
	}

	size = le32_to_cpu(hdr.sze);
	...
	h = kvzalloc(size, GFP_KERNEL);
}

hdr is allocated on the stack without zero-initialization.  If the
controller completes the log page command with a short data transfer,
hdr.sze remains uninitialized and is passed as the allocation size to
kvzalloc().

[1] https://sashiko.dev/#/bug/linux-1cda5d44-a6cc-40a9-bd2b-cbed1b364093

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/202611150127512368BGQ07ZNIRAIwClkam-8u@zte.com.cn?part=4