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

[Jens Axboe <axboe@kernel.dk>]

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