lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADUfDZqvwhL3Hz7_u+TsO5XrpeWX9dHtbehXUtwbJdyi_GXT_A@mail.gmail.com>
Date: Mon, 5 May 2025 16:15:47 -0700
From: Caleb Sander Mateos <csander@...estorage.com>
To: Sasha Levin <sashal@...nel.org>
Cc: linux-kernel@...r.kernel.org, stable@...r.kernel.org, 
	Xinyu Zhang <xizhang@...estorage.com>, Jens Axboe <axboe@...nel.dk>, 
	Ming Lei <ming.lei@...hat.com>, Keith Busch <kbusch@...nel.org>, sagi@...mberg.me, 
	linux-nvme@...ts.infradead.org
Subject: Re: [PATCH AUTOSEL 6.14 295/642] nvme: map uring_cmd data even if
 address is 0

I wouldn't backport this change to any releases. It's a potential
behavior change if a userspace application was submitting NVMe
passthru commands with a NULL data pointer but nonzero data length and
expecting the data buffer to be ignored. And supporting the data field
set to 0 is only necessary for ublk zero-copy, which is introduced in
6.15.

Best,
Caleb

On Mon, May 5, 2025 at 3:26 PM Sasha Levin <sashal@...nel.org> wrote:
>
> From: Xinyu Zhang <xizhang@...estorage.com>
>
> [ Upstream commit 99fde895ff56ac2241e7b7b4566731d72f2fdaa7 ]
>
> When using kernel registered bvec fixed buffers, the "address" is
> actually the offset into the bvec rather than userspace address.
> Therefore it can be 0.
>
> We can skip checking whether the address is NULL before mapping
> uring_cmd data. Bad userspace address will be handled properly later when
> the user buffer is imported.
>
> With this patch, we will be able to use the kernel registered bvec fixed
> buffers in io_uring NVMe passthru with ublk zero-copy support.
>
> Reviewed-by: Caleb Sander Mateos <csander@...estorage.com>
> Reviewed-by: Jens Axboe <axboe@...nel.dk>
> Reviewed-by: Ming Lei <ming.lei@...hat.com>
> Signed-off-by: Xinyu Zhang <xizhang@...estorage.com>
> Signed-off-by: Keith Busch <kbusch@...nel.org>
> Link: https://lore.kernel.org/r/20250227223916.143006-4-kbusch@meta.com
> Signed-off-by: Jens Axboe <axboe@...nel.dk>
> Signed-off-by: Sasha Levin <sashal@...nel.org>
> ---
>  drivers/nvme/host/ioctl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/nvme/host/ioctl.c b/drivers/nvme/host/ioctl.c
> index fed6b29098ad3..11509ffd28fb5 100644
> --- a/drivers/nvme/host/ioctl.c
> +++ b/drivers/nvme/host/ioctl.c
> @@ -514,7 +514,7 @@ static int nvme_uring_cmd_io(struct nvme_ctrl *ctrl, struct nvme_ns *ns,
>                 return PTR_ERR(req);
>         req->timeout = d.timeout_ms ? msecs_to_jiffies(d.timeout_ms) : 0;
>
> -       if (d.addr && d.data_len) {
> +       if (d.data_len) {
>                 ret = nvme_map_user_request(req, d.addr,
>                         d.data_len, nvme_to_user_ptr(d.metadata),
>                         d.metadata_len, ioucmd, vec);
> --
> 2.39.5
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ