[PATCH 6.6.y] nvme-fabrics: use reserved tag for reg read/write command

Xu Chunguang chunguang.xu at shopee.com
Tue Sep 29 21:16:57 PDT 2026


OK, I will apply it for 6.6 later, Thanks


On Wed, Sep 30, 2026 at 10:42 AM Artem Dinaburg <artem at trailofbits.com> wrote:
>
> From: Chunguang Xu <chunguang.xu at shopee.com>
>
> [ Upstream commit 7dc3bfcb4c9cc58970fff6aaa48172cb224d85aa ]
>
> In some scenarios, if too many commands are issued by nvme command in
> the same time by user tasks, this may exhaust all tags of admin_q. If
> a reset (nvme reset or IO timeout) occurs before these commands finish,
> reconnect routine may fail to update nvme regs due to insufficient tags,
> which will cause kernel hang forever. In order to workaround this issue,
> maybe we can let reg_read32()/reg_read64()/reg_write32() use reserved
> tags. This maybe safe for nvmf:
>
> 1. For the disable ctrl path,  we will not issue connect command
> 2. For the enable ctrl / fw activate path, since connect and reg_xx()
>    are called serially.
>
> So the reserved tags may still be enough while reg_xx() use reserved tags.
>
> [ Backport to 6.6.y: used the older BLK_MQ_REQ_RESERVED request flag. ]
>
> Signed-off-by: Chunguang Xu <chunguang.xu at shopee.com>
> Reviewed-by: Sagi Grimberg <sagi at grimberg.me>
> Reviewed-by: Chaitanya Kulkarni <kch at nvidia.com>
> Reviewed-by: Christoph Hellwig <hch at lst.de>
> Signed-off-by: Keith Busch <kbusch at kernel.org>
> Assisted-by: LLM
> Signed-off-by: Artem Dinaburg <artem at trailofbits.com>
> ---
> Hi Greg, Sasha, and nvme maintainers,
>
> I am working through the small CVE backports still missing from 6.6.y.
> This one addresses CVE-2024-41082. It reserves a request tag for
> controller-register I/O during reconnect and reset.
>
> The fix is already present in 6.12.y, 6.18.y, and 7.2.y, but not in 6.6.y.
> This fix also affects 6.1.y, which will need a separate backport; this
> submission contains only the 6.6.y patch.
> The target-specific adjustment is recorded in the bracketed note above.
>
> Could you please queue it for 6.6.y?
>
> CVE: CVE-2024-41082
> Upstream: 7dc3bfcb4c9cc58970fff6aaa48172cb224d85aa
>
> AI assistance: An LLM helped identify, adapt, and validate this backport; I
> reviewed the resulting code and validation evidence.
>
> Thanks,
> Artem Dinaburg
>
>  drivers/nvme/host/fabrics.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/nvme/host/fabrics.c b/drivers/nvme/host/fabrics.c
> index fd01b86f10a4b0..8adcc8c97c42cf 100644
> --- a/drivers/nvme/host/fabrics.c
> +++ b/drivers/nvme/host/fabrics.c
> @@ -179,7 +179,7 @@ int nvmf_reg_read32(struct nvme_ctrl *ctrl, u32 off, u32 *val)
>         cmd.prop_get.offset = cpu_to_le32(off);
>
>         ret = __nvme_submit_sync_cmd(ctrl->fabrics_q, &cmd, &res, NULL, 0,
> -                       NVME_QID_ANY, 0, 0);
> +                       NVME_QID_ANY, 0, BLK_MQ_REQ_RESERVED);
>
>         if (ret >= 0)
>                 *val = le64_to_cpu(res.u64);
> @@ -225,7 +225,7 @@ int nvmf_reg_read64(struct nvme_ctrl *ctrl, u32 off, u64 *val)
>         cmd.prop_get.offset = cpu_to_le32(off);
>
>         ret = __nvme_submit_sync_cmd(ctrl->fabrics_q, &cmd, &res, NULL, 0,
> -                       NVME_QID_ANY, 0, 0);
> +                       NVME_QID_ANY, 0, BLK_MQ_REQ_RESERVED);
>
>         if (ret >= 0)
>                 *val = le64_to_cpu(res.u64);
> @@ -270,7 +270,7 @@ int nvmf_reg_write32(struct nvme_ctrl *ctrl, u32 off, u32 val)
>         cmd.prop_set.value = cpu_to_le64(val);
>
>         ret = __nvme_submit_sync_cmd(ctrl->fabrics_q, &cmd, NULL, NULL, 0,
> -                       NVME_QID_ANY, 0, 0);
> +                       NVME_QID_ANY, 0, BLK_MQ_REQ_RESERVED);
>         if (unlikely(ret))
>                 dev_err(ctrl->device,
>                         "Property Set error: %d, offset %#x\n",
> --
> 2.39.5
>



More information about the Linux-nvme mailing list