linux-kernel - Re: [PATCH] ublk: fix ublksrv pid handling for pid namespaces

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: <aWSJRAEbC3SUuRk-@fedora>
Date: Mon, 12 Jan 2026 13:40:20 +0800
From: Ming Lei <ming.lei@...hat.com>
To: Seamus Connor <sconnor@...estorage.com>
Cc: Jens Axboe <axboe@...nel.dk>, linux-block@...r.kernel.org,
	Caleb Sander <csander@...estorage.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ublk: fix ublksrv pid handling for pid namespaces

On Sat, Jan 10, 2026 at 04:00:15PM -0800, Seamus Connor wrote:
> When ublksrv runs inside a pid namespace, START/END_RECOVERY compared
> the stored init-ns tgid against the userspace pid (getpid vnr), so the
> check failed and control ops could not proceed. Compare against the
> caller’s init-ns tgid and store that value, then translate it back to
> the caller’s pid namespace when reporting GET_DEV_INFO so ublk list
> shows a sensible pid.
> 
> Testing: start/recover in a pid namespace; `ublk list` shows
> reasonable pid values in init, child, and sibling namespaces.
> 
> Fixes: d37a224fc119 ("ublk: validate ublk server pid")
> Signed-off-by: Seamus Connor <sconnor@...estorage.com>
> Reviewed-by: Caleb Sander Mateos <csander@...estorage.com>
> ---
>  drivers/block/ublk_drv.c | 36 ++++++++++++++++++++++++++----------
>  1 file changed, 26 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
> index 79847e0b9e88..9ef6432fef7c 100644
> --- a/drivers/block/ublk_drv.c
> +++ b/drivers/block/ublk_drv.c
> @@ -2858,7 +2858,6 @@ static int ublk_ctrl_start_dev(struct ublk_device *ub,
>   const struct ublksrv_ctrl_cmd *header)
>  {
>   const struct ublk_param_basic *p = &ub->params.basic;
> - int ublksrv_pid = (int)header->data[0];
>   struct queue_limits lim = {
>   .logical_block_size = 1 << p->logical_bs_shift,
>   .physical_block_size = 1 << p->physical_bs_shift,
> @@ -2874,8 +2873,6 @@ static int ublk_ctrl_start_dev(struct ublk_device *ub,
>   struct gendisk *disk;
>   int ret = -EINVAL;
> 
> - if (ublksrv_pid <= 0)
> - return -EINVAL;
>   if (!(ub->params.types & UBLK_PARAM_TYPE_BASIC))
>   return -EINVAL;
> 
> @@ -2922,7 +2919,7 @@ static int ublk_ctrl_start_dev(struct ublk_device *ub,
>   if (wait_for_completion_interruptible(&ub->completion) != 0)
>   return -EINTR;
> 
> - if (ub->ublksrv_tgid != ublksrv_pid)
> + if (ub->ublksrv_tgid != current->tgid)

This way requires that START_DEV command can only be submitted from ublk server
daemon context, which may break implementation sending `START_DEV` command
from remote process context.

Can we fix it in the following way?

+       struct pid *pid = find_vpid(ublksrv_pid);
+
+       if (!pid || pid_nr(pid) != ub->ublksrv_tgid)
+               return -EINVAL;

Also your patch has patch style issue, please check it before posting out
by `./scripts/checkpatch.pl`. Or you may have to use `git send-email` to
send patch file.


Thanks,
Ming