linux-kernel - [PATCH v2 0/3] coredump: hand a pidfd to the usermode coredump helper

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-next>] [day] [month] [year] [list]

Message-Id: <20250414-work-coredump-v2-0-685bf231f828@kernel.org>
Date: Mon, 14 Apr 2025 15:55:04 +0200
From: Christian Brauner <brauner@...nel.org>
To: linux-fsdevel@...r.kernel.org
Cc: Oleg Nesterov <oleg@...hat.com>, 
 Luca Boccassi <luca.boccassi@...il.com>, 
 Lennart Poettering <lennart@...ttering.net>, 
 Daan De Meyer <daan.j.demeyer@...il.com>, Mike Yuan <me@...dnzj.com>, 
 Zbigniew Jędrzejewski-Szmek <zbyszek@...waw.pl>, 
 linux-kernel@...r.kernel.org, Christian Brauner <brauner@...nel.org>
Subject: [PATCH v2 0/3] coredump: hand a pidfd to the usermode coredump
 helper

Give userspace a way to instruct the kernel to install a pidfd for the
crashing process into the process started as a usermode helper. There's
still tricky race-windows that cannot be easily or sometimes not closed
at all by userspace. There's various ways like looking at the start time
of a process to make sure that the usermode helper process is started
after the crashing process but it's all very very brittle and fraught
with peril.

The crashed-but-not-reaped process can be killed by userspace before
coredump processing programs like systemd-coredump have had time to
manually open a PIDFD from the PID the kernel provides them, which means
they can be tricked into reading from an arbitrary process, and they run
with full privileges as they are usermode helper processes.

Even if that specific race-window wouldn't exist it's still the safest
and cleanest way to let the kernel provide the pidfd directly instead of
requiring userspace to do it manually. In parallel with this commit we
already have systemd adding support for this in [1].

When the usermode helper process is forked we install a pidfd file
descriptor three into the usermode helper's file descriptor table so
it's available to the exec'd program.

Since usermode helpers are either children of the system_unbound_wq
workqueue or kthreadd we know that the file descriptor table is empty
and can thus always use three as the file descriptor number.

Note, that we'll install a pidfd for the thread-group leader even if a
subthread is calling do_coredump(). We know that task linkage hasn't
been removed yet and even if this @current isn't the actual thread-group
leader we know that the thread-group leader cannot be reaped until
@current has exited.

[1]: https://github.com/systemd/systemd/pull/37125

Signed-off-by: Christian Brauner <brauner@...nel.org>
---
Changes in v2:
- Store a pid in struct coredump_params instead of a file.
- Link to v1: https://lore.kernel.org/20250414-work-coredump-v1-0-6caebc807ff4@kernel.org

---
Christian Brauner (3):
      pidfs: move O_RDWR into pidfs_alloc_file()
      coredump: fix error handling for replace_fd()
      coredump: hand a pidfd to the usermode coredump helper

 fs/coredump.c            | 68 +++++++++++++++++++++++++++++++++++++++++++-----
 fs/pidfs.c               |  1 +
 include/linux/coredump.h |  1 +
 kernel/fork.c            |  2 +-
 4 files changed, 65 insertions(+), 7 deletions(-)
---
base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8
change-id: 20250413-work-coredump-0f7fa7e6414c