Question: io_uring SQPOLL fdinfo prints host PID across pid_ns?

Question: io_uring SQPOLL fdinfo prints host PID across pid_ns?

[Xie Maoyi]

Hi Jens, Pavel,

While testing io_uring with the SQPOLL setup flag from inside an
unprivileged user_ns + pid_ns, I noticed that
/proc/<pid>/fdinfo/<ring> prints the SQPOLL kthread's host
(init_pid_ns) PID rather than the kthread's PID as seen from the
caller's pid_ns. I'm not sure whether this is intended behaviour
or a bug worth fixing, and would appreciate your view before
sending a patch.

Reproduction (KASAN, mainline 7.0): a process unshares CLONE_NEWUSER
| CLONE_NEWPID | CLONE_NEWNS, mounts a private /proc, and a
grandchild (PID 1 in the new pid_ns) opens an io_uring ring with
IORING_SETUP_SQPOLL. Inside the new pid_ns:

  /proc/self/task contains {1, 2}     # SQPOLL kthread is PID 2
  /proc/self/fdinfo/<ring>:
    SqThread:  356                    # init_pid_ns view (host PID)

After applying a candidate fix that translates sq->task_pid
through task_pid_nr_ns() against the inode's pid_ns (mirroring
pidfd_show_fdinfo() in kernel/pid.c), the same PoC prints:

  SqThread:  2                        # caller's pid_ns view

Is this expected behaviour, or worth fixing? If a fix would be
welcome, I have a 2+/1- patch in io_uring/fdinfo.c that's
checkpatch-clean and verified pre/post on a KASAN VM. Happy to
send the patch and the full PoC if that's useful.

Thanks,
Maoyi
________________________________

CONFIDENTIALITY: This email is intended solely for the person(s) named and may be confidential and/or privileged. If you are not the intended recipient, please delete it, notify us and do not copy, use, or disclose its contents.
Towards a sustainable earth: Print only when necessary. Thank you.

Re: Question: io_uring SQPOLL fdinfo prints host PID across pid_ns?

[Jens Axboe]

On 5/8/26 2:34 AM, Xie Maoyi wrote:
> Hi Jens, Pavel,
> 
> While testing io_uring with the SQPOLL setup flag from inside an
> unprivileged user_ns + pid_ns, I noticed that
> /proc/<pid>/fdinfo/<ring> prints the SQPOLL kthread's host
> (init_pid_ns) PID rather than the kthread's PID as seen from the
> caller's pid_ns. I'm not sure whether this is intended behaviour
> or a bug worth fixing, and would appreciate your view before
> sending a patch.
> 
> Reproduction (KASAN, mainline 7.0): a process unshares CLONE_NEWUSER
> | CLONE_NEWPID | CLONE_NEWNS, mounts a private /proc, and a
> grandchild (PID 1 in the new pid_ns) opens an io_uring ring with
> IORING_SETUP_SQPOLL. Inside the new pid_ns:
> 
>   /proc/self/task contains {1, 2}     # SQPOLL kthread is PID 2
>   /proc/self/fdinfo/<ring>:
>     SqThread:  356                    # init_pid_ns view (host PID)
> 
> After applying a candidate fix that translates sq->task_pid
> through task_pid_nr_ns() against the inode's pid_ns (mirroring
> pidfd_show_fdinfo() in kernel/pid.c), the same PoC prints:
> 
>   SqThread:  2                        # caller's pid_ns view
> 
> Is this expected behaviour, or worth fixing? If a fix would be
> welcome, I have a 2+/1- patch in io_uring/fdinfo.c that's
> checkpatch-clean and verified pre/post on a KASAN VM. Happy to
> send the patch and the full PoC if that's useful.

Please send the patch, I do think we should change that.

-- 
Jens Axboe