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.