From nobody Sun Feb 8 08:42:51 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5B9AC254AE5; Fri, 2 May 2025 12:42:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746189769; cv=none; b=FIYm7JpSyae8ovwOe1SLisPPWXNAzR39turWroQ+APDxR76ry6m9H+IaGpWGehTkd5BUvwXR38doZ853IsAyPjQfs8SOv5v1ra1q/LopJYuvkq4MrYlZEQH/8kLlAafg4vvFABr/GtWyprbQI60r1gr8TjvKD2nlBM6c4S9QL88= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746189769; c=relaxed/simple; bh=d48rlIeb55kv9LHwHtfILNbBpVSvS+cV2//Rf2p6cRQ=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=o5BTeM278GQRndNioT73uyyWsgde6jg0nWIm4KDjIospQrZVpBU1GjjfO1/MceQQHL2/QupL4lffyRLhXEl26J02gIx2DFY95+BmKYp8Rv++LimEUtE5oBHyd0rvsLLVfdPTngyvSFIjzPSMx5hPm94IwGPcVAg0/T0Y+E0ptA8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ym9rhXJ6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ym9rhXJ6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DBDF5C4CEE4; Fri, 2 May 2025 12:42:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746189768; bh=d48rlIeb55kv9LHwHtfILNbBpVSvS+cV2//Rf2p6cRQ=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=Ym9rhXJ6YqnYaVLgRVBOZoLLxp2uyI5BOAtHdk4rT9y79qu+bZjhdvbYEHXYf15xA OXpMttX1a4yz4vUulrf1mAP0l6TYhaJ9501KZ8OWEAAP7WaKPXK2fTA5gZfQXA3ydq tFkGEprVNIKJf7ZXxSXCCqMZL7vZTcZoiTJJk7T40ofBXTn2K54hC5u3h5o+4ORjIz 1gTnVuvKZtUF0TO2q6tLXJ0Q2mDQVJcOwau4toSVtIxVN2SBiUqx5Apywi5ILGYHu3 3EieaFb1j/lK31oUUV11syvNuct3rYAzTQ7j0WDVztIvNWpynbvy7Zs+4c9l2grpBU 2s5xiP7rzJPbQ== From: Christian Brauner Date: Fri, 02 May 2025 14:42:32 +0200 Subject: [PATCH RFC v2 1/6] coredump: massage format_corname() Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250502-work-coredump-socket-v2-1-43259042ffc7@kernel.org> References: <20250502-work-coredump-socket-v2-0-43259042ffc7@kernel.org> In-Reply-To: <20250502-work-coredump-socket-v2-0-43259042ffc7@kernel.org> To: Eric Dumazet , Kuniyuki Iwashima , Oleg Nesterov , linux-fsdevel@vger.kernel.org, Jann Horn Cc: "David S. Miller" , Alexander Viro , Daan De Meyer , David Rheinsberg , Jakub Kicinski , Jan Kara , Lennart Poettering , Luca Boccassi , Mike Yuan , Paolo Abeni , Simon Horman , =?utf-8?q?Zbigniew_J=C4=99drzejewski-Szmek?= , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Christian Brauner X-Mailer: b4 0.15-dev-c25d1 X-Developer-Signature: v=1; a=openpgp-sha256; l=4656; i=brauner@kernel.org; h=from:subject:message-id; bh=d48rlIeb55kv9LHwHtfILNbBpVSvS+cV2//Rf2p6cRQ=; b=owGbwMvMwCU28Zj0gdSKO4sYT6slMWSI7N3/8Tzn7oU+ouf935kc6pu1UlEyfM2OWJGliQ/Xf L7+mcvJvKOUhUGMi0FWTJHFod0kXG45T8Vmo0wNmDmsTCBDGLg4BWAim24w/DO4XP1nwzeRiTqd Z767ruKK+5WSzubr8NtCjnXjL8GL8w8x/A/9fC0+a5Ki5CQu+2dTWko0yw+tbuHrCHVassN9deN 2VgYA X-Developer-Key: i=brauner@kernel.org; a=openpgp; fpr=4880B8C9BD0E5106FC070F4F7B3C391EFEA93624 We're going to extend the coredump code in follow-up patches. Clean it up so we can do this more easily. Signed-off-by: Christian Brauner --- fs/coredump.c | 41 ++++++++++++++++++++++++----------------- 1 file changed, 24 insertions(+), 17 deletions(-) diff --git a/fs/coredump.c b/fs/coredump.c index d740a0411266..281320ea351f 100644 --- a/fs/coredump.c +++ b/fs/coredump.c @@ -76,9 +76,15 @@ static char core_pattern[CORENAME_MAX_SIZE] =3D "core"; static int core_name_size =3D CORENAME_MAX_SIZE; unsigned int core_file_note_size_limit =3D CORE_FILE_NOTE_SIZE_DEFAULT; =20 +enum coredump_type_t { + COREDUMP_FILE =3D 1, + COREDUMP_PIPE =3D 2, +}; + struct core_name { char *corename; int used, size; + enum coredump_type_t core_type; }; =20 static int expand_corename(struct core_name *cn, int size) @@ -218,18 +224,21 @@ static int format_corename(struct core_name *cn, stru= ct coredump_params *cprm, { const struct cred *cred =3D current_cred(); const char *pat_ptr =3D core_pattern; - int ispipe =3D (*pat_ptr =3D=3D '|'); bool was_space =3D false; int pid_in_pattern =3D 0; int err =3D 0; =20 cn->used =3D 0; cn->corename =3D NULL; + if (*pat_ptr =3D=3D '|') + cn->core_type =3D COREDUMP_PIPE; + else + cn->core_type =3D COREDUMP_FILE; if (expand_corename(cn, core_name_size)) return -ENOMEM; cn->corename[0] =3D '\0'; =20 - if (ispipe) { + if (cn->core_type =3D=3D COREDUMP_PIPE) { int argvs =3D sizeof(core_pattern) / 2; (*argv) =3D kmalloc_array(argvs, sizeof(**argv), GFP_KERNEL); if (!(*argv)) @@ -247,7 +256,7 @@ static int format_corename(struct core_name *cn, struct= coredump_params *cprm, * Split on spaces before doing template expansion so that * %e and %E don't get split if they have spaces in them */ - if (ispipe) { + if (cn->core_type =3D=3D COREDUMP_PIPE) { if (isspace(*pat_ptr)) { if (cn->used !=3D 0) was_space =3D true; @@ -353,7 +362,7 @@ static int format_corename(struct core_name *cn, struct= coredump_params *cprm, * Installing a pidfd only makes sense if * we actually spawn a usermode helper. */ - if (!ispipe) + if (!(cn->core_type !=3D COREDUMP_PIPE)) break; =20 /* @@ -384,12 +393,12 @@ static int format_corename(struct core_name *cn, stru= ct coredump_params *cprm, * If core_pattern does not include a %p (as is the default) * and core_uses_pid is set, then .%pid will be appended to * the filename. Do not do this for piped commands. */ - if (!ispipe && !pid_in_pattern && core_uses_pid) { + if (!(cn->core_type =3D=3D COREDUMP_PIPE) && !pid_in_pattern && core_uses= _pid) { err =3D cn_printf(cn, ".%d", task_tgid_vnr(current)); if (err) return err; } - return ispipe; + return 0; } =20 static int zap_process(struct signal_struct *signal, int exit_code) @@ -583,7 +592,6 @@ void do_coredump(const kernel_siginfo_t *siginfo) const struct cred *old_cred; struct cred *cred; int retval =3D 0; - int ispipe; size_t *argv =3D NULL; int argc =3D 0; /* require nonrelative corefile path and be extra careful */ @@ -632,19 +640,18 @@ void do_coredump(const kernel_siginfo_t *siginfo) =20 old_cred =3D override_creds(cred); =20 - ispipe =3D format_corename(&cn, &cprm, &argv, &argc); + retval =3D format_corename(&cn, &cprm, &argv, &argc); + if (retval < 0) { + coredump_report_failure("format_corename failed, aborting core"); + goto fail_unlock; + } =20 - if (ispipe) { + if (cn.core_type =3D=3D COREDUMP_PIPE) { int argi; int dump_count; char **helper_argv; struct subprocess_info *sub_info; =20 - if (ispipe < 0) { - coredump_report_failure("format_corename failed, aborting core"); - goto fail_unlock; - } - if (cprm.limit =3D=3D 1) { /* See umh_coredump_setup() which sets RLIMIT_CORE =3D 1. * @@ -695,7 +702,7 @@ void do_coredump(const kernel_siginfo_t *siginfo) coredump_report_failure("|%s pipe failed", cn.corename); goto close_fail; } - } else { + } else if (cn.core_type =3D=3D COREDUMP_FILE) { struct mnt_idmap *idmap; struct inode *inode; int open_flags =3D O_CREAT | O_WRONLY | O_NOFOLLOW | @@ -823,13 +830,13 @@ void do_coredump(const kernel_siginfo_t *siginfo) file_end_write(cprm.file); free_vma_snapshot(&cprm); } - if (ispipe && core_pipe_limit) + if ((cn.core_type =3D=3D COREDUMP_PIPE) && core_pipe_limit) wait_for_dump_helpers(cprm.file); close_fail: if (cprm.file) filp_close(cprm.file, NULL); fail_dropcount: - if (ispipe) + if (cn.core_type =3D=3D COREDUMP_PIPE) atomic_dec(&core_dump_count); fail_unlock: kfree(argv); --=20 2.47.2 From nobody Sun Feb 8 08:42:51 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E2D8D248F46; Fri, 2 May 2025 12:42:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746189774; cv=none; b=hbQTGr7w5L/rUQrXrZ2YXuLotwcbBjtq+Jkf8zDTG4NV0YYHdjuzoTQBFQ2PDNXtRf5dM8+eoJInvMU9Rr2RgjkjhBrsbB1e9FhKEYP8ioO08YABEubrCkgpANAaAbEsHTy9KKddJlypA2Q1cDtR7Ll6qy92Ub0UA8pK/AXhD74= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746189774; c=relaxed/simple; bh=sY3uIB6g6xsWBkS/M2/GrdpdnZH6W10Su5t41D1OTEg=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=rvAUSQ9Rj9rvD26moYg7rupggyz9p0FjcbPhGHEc8ulMUpKDa+L88SmzA5PIRfxeFs5ePYndfwsUOKBWtdD+XuG46qiuxvhQ0jIDhA62xmCGrpLeL09WNPKfiRJNRS5iTbmO7mXThmtyYCCj+9TKYy/DKHONzY42MHK0zTWoe0A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ilvkt6di; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ilvkt6di" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4D51EC4CEEB; Fri, 2 May 2025 12:42:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746189773; bh=sY3uIB6g6xsWBkS/M2/GrdpdnZH6W10Su5t41D1OTEg=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=Ilvkt6dinbQJBlCYAZYj+1+2FbQR9rqhlQ0M+gncmtxbrumdwgkCSZofmO34ZOUj7 mGGEHvnNnuexIbIWyjrHUbaCLkGjRiKfnsQU+SHk5NoayIgLLnJfnFLWpkvEGqQ4Wa Nl4Y9zJKCq5br64R2jKvu+6S2AdD4XnAlSBQqnbX4LVH2G2/sNaP2y1cMr+1G5qqi8 BYHsgLDfELQXDWbOzwHLfci/XWxFbLYp2GONpFZLwGCvMUNmJbPvwAbQZESK8ryJgc kt2Vp5Nvao2KGmivvcbxddDn7zefa/dhaXuQ4hA5D2Si9Wk0GktezuqZIM21OJbp2A dd3tZX5QzlayA== From: Christian Brauner Date: Fri, 02 May 2025 14:42:33 +0200 Subject: [PATCH RFC v2 2/6] coredump: massage do_coredump() Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250502-work-coredump-socket-v2-2-43259042ffc7@kernel.org> References: <20250502-work-coredump-socket-v2-0-43259042ffc7@kernel.org> In-Reply-To: <20250502-work-coredump-socket-v2-0-43259042ffc7@kernel.org> To: Eric Dumazet , Kuniyuki Iwashima , Oleg Nesterov , linux-fsdevel@vger.kernel.org, Jann Horn Cc: "David S. Miller" , Alexander Viro , Daan De Meyer , David Rheinsberg , Jakub Kicinski , Jan Kara , Lennart Poettering , Luca Boccassi , Mike Yuan , Paolo Abeni , Simon Horman , =?utf-8?q?Zbigniew_J=C4=99drzejewski-Szmek?= , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Christian Brauner X-Mailer: b4 0.15-dev-c25d1 X-Developer-Signature: v=1; a=openpgp-sha256; l=4933; i=brauner@kernel.org; h=from:subject:message-id; bh=sY3uIB6g6xsWBkS/M2/GrdpdnZH6W10Su5t41D1OTEg=; b=owGbwMvMwCU28Zj0gdSKO4sYT6slMWSI7N2v8eF8qXy1LEvlm1uuAVNWz7kpvXbGlJpdqx/sW ZTp5m3xv6OUhUGMi0FWTJHFod0kXG45T8Vmo0wNmDmsTCBDGLg4BWAij2YyMrw0+/JjidOuq+dP FqcHLXVVY7Q/n/LYTfaEyfpc5/7ZD+cyMjwyfm9kuPjBr6eTTBb1cMqufftE5FxTRcvBgtUSJpv T/VgB X-Developer-Key: i=brauner@kernel.org; a=openpgp; fpr=4880B8C9BD0E5106FC070F4F7B3C391EFEA93624 We're going to extend the coredump code in follow-up patches. Clean it up so we can do this more easily. Signed-off-by: Christian Brauner --- fs/coredump.c | 123 +++++++++++++++++++++++++++++++-----------------------= ---- 1 file changed, 66 insertions(+), 57 deletions(-) diff --git a/fs/coredump.c b/fs/coredump.c index 281320ea351f..1779299b8c61 100644 --- a/fs/coredump.c +++ b/fs/coredump.c @@ -646,63 +646,8 @@ void do_coredump(const kernel_siginfo_t *siginfo) goto fail_unlock; } =20 - if (cn.core_type =3D=3D COREDUMP_PIPE) { - int argi; - int dump_count; - char **helper_argv; - struct subprocess_info *sub_info; - - if (cprm.limit =3D=3D 1) { - /* See umh_coredump_setup() which sets RLIMIT_CORE =3D 1. - * - * Normally core limits are irrelevant to pipes, since - * we're not writing to the file system, but we use - * cprm.limit of 1 here as a special value, this is a - * consistent way to catch recursive crashes. - * We can still crash if the core_pattern binary sets - * RLIM_CORE =3D !1, but it runs as root, and can do - * lots of stupid things. - * - * Note that we use task_tgid_vnr here to grab the pid - * of the process group leader. That way we get the - * right pid if a thread in a multi-threaded - * core_pattern process dies. - */ - coredump_report_failure("RLIMIT_CORE is set to 1, aborting core"); - goto fail_unlock; - } - cprm.limit =3D RLIM_INFINITY; - - dump_count =3D atomic_inc_return(&core_dump_count); - if (core_pipe_limit && (core_pipe_limit < dump_count)) { - coredump_report_failure("over core_pipe_limit, skipping core dump"); - goto fail_dropcount; - } - - helper_argv =3D kmalloc_array(argc + 1, sizeof(*helper_argv), - GFP_KERNEL); - if (!helper_argv) { - coredump_report_failure("%s failed to allocate memory", __func__); - goto fail_dropcount; - } - for (argi =3D 0; argi < argc; argi++) - helper_argv[argi] =3D cn.corename + argv[argi]; - helper_argv[argi] =3D NULL; - - retval =3D -ENOMEM; - sub_info =3D call_usermodehelper_setup(helper_argv[0], - helper_argv, NULL, GFP_KERNEL, - umh_coredump_setup, NULL, &cprm); - if (sub_info) - retval =3D call_usermodehelper_exec(sub_info, - UMH_WAIT_EXEC); - - kfree(helper_argv); - if (retval) { - coredump_report_failure("|%s pipe failed", cn.corename); - goto close_fail; - } - } else if (cn.core_type =3D=3D COREDUMP_FILE) { + switch (cn.core_type) { + case COREDUMP_FILE: { struct mnt_idmap *idmap; struct inode *inode; int open_flags =3D O_CREAT | O_WRONLY | O_NOFOLLOW | @@ -796,6 +741,70 @@ void do_coredump(const kernel_siginfo_t *siginfo) if (do_truncate(idmap, cprm.file->f_path.dentry, 0, 0, cprm.file)) goto close_fail; + break; + } + case COREDUMP_PIPE: { + int argi; + int dump_count; + char **helper_argv; + struct subprocess_info *sub_info; + + if (cprm.limit =3D=3D 1) { + /* See umh_coredump_setup() which sets RLIMIT_CORE =3D 1. + * + * Normally core limits are irrelevant to pipes, since + * we're not writing to the file system, but we use + * cprm.limit of 1 here as a special value, this is a + * consistent way to catch recursive crashes. + * We can still crash if the core_pattern binary sets + * RLIM_CORE =3D !1, but it runs as root, and can do + * lots of stupid things. + * + * Note that we use task_tgid_vnr here to grab the pid + * of the process group leader. That way we get the + * right pid if a thread in a multi-threaded + * core_pattern process dies. + */ + coredump_report_failure("RLIMIT_CORE is set to 1, aborting core"); + goto fail_unlock; + } + cprm.limit =3D RLIM_INFINITY; + + dump_count =3D atomic_inc_return(&core_dump_count); + if (core_pipe_limit && (core_pipe_limit < dump_count)) { + coredump_report_failure("over core_pipe_limit, skipping core dump"); + goto fail_dropcount; + } + + helper_argv =3D kmalloc_array(argc + 1, sizeof(*helper_argv), + GFP_KERNEL); + if (!helper_argv) { + coredump_report_failure("%s failed to allocate memory", __func__); + goto fail_dropcount; + } + for (argi =3D 0; argi < argc; argi++) + helper_argv[argi] =3D cn.corename + argv[argi]; + helper_argv[argi] =3D NULL; + + retval =3D -ENOMEM; + sub_info =3D call_usermodehelper_setup(helper_argv[0], + helper_argv, NULL, GFP_KERNEL, + umh_coredump_setup, NULL, &cprm); + if (sub_info) + retval =3D call_usermodehelper_exec(sub_info, + UMH_WAIT_EXEC); + + kfree(helper_argv); + if (retval) { + coredump_report_failure("|%s pipe failed", cn.corename); + goto close_fail; + } + break; + } + default: + WARN_ON_ONCE(true); + retval =3D -EINVAL; + goto close_fail; } =20 /* get us an unshared descriptor table; almost always a no-op */ --=20 2.47.2 From nobody Sun Feb 8 08:42:51 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3B140253F0C; Fri, 2 May 2025 12:42:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746189778; cv=none; b=e9gKThroqJplM0Toi2svd5iJhwADiMaCtngYf5Z7mAAvd4TnMbeKcBvsCF34YCYstQwEzNWY9I4/NbQSrHzcJZzkDw0S/lZ+xhf1ZqAiT2Tt5wluNAjYD9EzEMAuFduXa6tZzOj0pWinHq/q7teAA3C3qNrIqNzsroFe3tPUcx4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746189778; c=relaxed/simple; bh=/vJ8Xys/h8H5d+TJXIiBTPL4YzXjsAeeRGWurXNqgJQ=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=BKZVWmQVAKHCZT5RrbHL0RCm0bXiu7Un3WBEcO9HRLdor191C1IJk5fg0nNAJXZEBOdE1TMmR5EOYhEB3TlU4D2+gEsOMkCZrUq4yAj5O3wvJUYwOjYkF5e5RL93grLrjsRIe0yScT7jSYeDDQRJIAs1FZ1FBrelqyM+tP85RMM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HhwusinW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HhwusinW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D7FE7C4CEE4; Fri, 2 May 2025 12:42:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746189778; bh=/vJ8Xys/h8H5d+TJXIiBTPL4YzXjsAeeRGWurXNqgJQ=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=HhwusinWMsE2RgWhvZSdQ7d+uMwvzxcYQZAtzOQGYe0yLNWRp9CEHyDZZyhoIZyB5 lmi2KI0JRGoqITAh9ogpyLUfBdrdJxNInOvBC8jXdYqE2ECChGhZA1hM1I0kMWc3oX srgFKAKBzkFKzrUscLQwGBdtE18KDnal+rAG+rTh/UAEGj4IhMA6Ool4zdi1lCkhJJ C+luWSFJqQ2/1XlbxMXp+J8J7UBiZVSb69+DHx1lmvg7EmbA3M1BDrBmfFM++6gJj7 bXvXYUuWEwPwsWEB5vCjhDQmwcOFgTJqFKKaqXCRhwWl4Gy1xJ/i9azpK1RxyJZ2uW ZhidTQPdOElXA== From: Christian Brauner Date: Fri, 02 May 2025 14:42:34 +0200 Subject: [PATCH RFC v2 3/6] coredump: support AF_UNIX sockets Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250502-work-coredump-socket-v2-3-43259042ffc7@kernel.org> References: <20250502-work-coredump-socket-v2-0-43259042ffc7@kernel.org> In-Reply-To: <20250502-work-coredump-socket-v2-0-43259042ffc7@kernel.org> To: Eric Dumazet , Kuniyuki Iwashima , Oleg Nesterov , linux-fsdevel@vger.kernel.org, Jann Horn Cc: "David S. Miller" , Alexander Viro , Daan De Meyer , David Rheinsberg , Jakub Kicinski , Jan Kara , Lennart Poettering , Luca Boccassi , Mike Yuan , Paolo Abeni , Simon Horman , =?utf-8?q?Zbigniew_J=C4=99drzejewski-Szmek?= , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Christian Brauner X-Mailer: b4 0.15-dev-c25d1 X-Developer-Signature: v=1; a=openpgp-sha256; l=9998; i=brauner@kernel.org; h=from:subject:message-id; bh=/vJ8Xys/h8H5d+TJXIiBTPL4YzXjsAeeRGWurXNqgJQ=; b=owGbwMvMwCU28Zj0gdSKO4sYT6slMWSI7N3vu57X7WPGuhsih9idTCTNgyScvYS1fWzqN0zKj t4ryaLRUcrCIMbFICumyOLQbhIut5ynYrNRpgbMHFYmkCEMXJwCMJHk1Qz/i1ojbuXOLn4b5XSD wWB/XdyKXQwfw8QKp77eJfFCuCothpFh99UDsU7Xc+6XX3R+sjDKaWuL2Ma5tx5uj3Nd2H3r924 ZdgA= X-Developer-Key: i=brauner@kernel.org; a=openpgp; fpr=4880B8C9BD0E5106FC070F4F7B3C391EFEA93624 Coredumping currently supports two modes: (1) Dumping directly into a file somewhere on the filesystem. (2) Dumping into a pipe connected to a usermode helper process spawned as a child of the system_unbound_wq or kthreadd. For simplicity I'm mostly ignoring (1). There's probably still some users of (1) out there but processing coredumps in this way can be considered adventurous especially in the face of set*id binaries. The most common option should be (2) by now. It works by allowing userspace to put a string into /proc/sys/kernel/core_pattern like: |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h The "|" at the beginning indicates to the kernel that a pipe must be used. The path following the pipe indicator is a path to a binary that will be spawned as a usermode helper process. Any additional parameters pass information about the task that is generating the coredump to the binary that processes the coredump. In this case systemd-coredump is spawned as a usermode helper. There's various conceptual consequences of this (non-exhaustive list): - systemd-coredump is spawned with file descriptor number 0 (stdin) to the read-end of the pipe. All other file descriptors are closed. That specifically includes 1 (stdout) and 2 (stderr). This has already caused bugs because userspace assumed that this cannot happen (Whether or not this is a sane assumption is irrelevant.). - systemd-coredump will be spawned as a child of system_unbound_wq. So it is not a child of any userspace process and specifically not a child of PID 1 so it cannot be waited upon and is in general a weird hybrid upcall. - systemd-coredump is spawned highly privileged as it is spawned with full kernel credentials requiring all kinds of weird privilege dropping excercises in userspaces. This adds another mode: (3) Dumping into a AF_UNIX socket. Userspace can set /proc/sys/kernel/core_pattern to: :/run/coredump.socket The ":" at the beginning indicates to the kernel that an AF_UNIX socket is used to process coredumps. The task generating the coredump simply connects to the socket and writes the coredump into the socket. Userspace can get a stable handle on the task generating the coredump by using the SO_PEERPIDFD socket option. SO_PEERPIDFD uses the thread-group leader pid stashed during connect(). Even if the task generating the coredump is a subthread in the thread-group the pidfd of the thread-group leader is a reliable stable handle. Userspace that's interested in the credentials of the specific thread that crashed can use SCM_PIDFD to retrieve them. The pidfd can be used to safely open and parse /proc/ of the task and it can also be used to retrieve additional meta information via the PIDFD_GET_INFO ioctl(). This will allow userspace to not have to rely on usermode helpers for processing coredumps and thus to stop having to handle super privileged coredumping helpers. This is easy to test: (a) coredump processing (we're using socat): > cat coredump_socket.sh #!/bin/bash set -x sudo bash -c "echo ':/tmp/stream.sock' > /proc/sys/kernel/core_pattern" socat --statistics unix-listen:/tmp/stream.sock,fork FILE:core_file,cre= ate,append,truncate (b) trigger a coredump: user1@localhost:~/data/scripts$ cat crash.c #include #include int main(int argc, char *argv[]) { fprintf(stderr, "%u\n", (1 / 0)); _exit(0); } Signed-off-by: Christian Brauner --- fs/coredump.c | 137 ++++++++++++++++++++++++++++++++++++++++++++++++++++++= +--- 1 file changed, 132 insertions(+), 5 deletions(-) diff --git a/fs/coredump.c b/fs/coredump.c index 1779299b8c61..9a6cba233db9 100644 --- a/fs/coredump.c +++ b/fs/coredump.c @@ -45,6 +45,9 @@ #include #include #include +#include +#include +#include =20 #include #include @@ -79,6 +82,7 @@ unsigned int core_file_note_size_limit =3D CORE_FILE_NOTE= _SIZE_DEFAULT; enum coredump_type_t { COREDUMP_FILE =3D 1, COREDUMP_PIPE =3D 2, + COREDUMP_SOCK =3D 3, }; =20 struct core_name { @@ -232,13 +236,16 @@ static int format_corename(struct core_name *cn, stru= ct coredump_params *cprm, cn->corename =3D NULL; if (*pat_ptr =3D=3D '|') cn->core_type =3D COREDUMP_PIPE; + else if (*pat_ptr =3D=3D ':') + cn->core_type =3D COREDUMP_SOCK; else cn->core_type =3D COREDUMP_FILE; if (expand_corename(cn, core_name_size)) return -ENOMEM; cn->corename[0] =3D '\0'; =20 - if (cn->core_type =3D=3D COREDUMP_PIPE) { + switch (cn->core_type) { + case COREDUMP_PIPE: { int argvs =3D sizeof(core_pattern) / 2; (*argv) =3D kmalloc_array(argvs, sizeof(**argv), GFP_KERNEL); if (!(*argv)) @@ -247,6 +254,39 @@ static int format_corename(struct core_name *cn, struc= t coredump_params *cprm, ++pat_ptr; if (!(*pat_ptr)) return -ENOMEM; + break; + } + case COREDUMP_SOCK: { + /* skip ':' */ + ++pat_ptr; + /* no spaces */ + if (!(*pat_ptr)) + return -EINVAL; + /* must be an absolute path */ + if (!(*pat_ptr =3D=3D '/')) + return -EINVAL; + err =3D cn_printf(cn, "%s", pat_ptr); + if (err) + return err; + /* + * For simplicitly we simply refuse spaces in the socket + * path. It's in line with what we do for pipes. + */ + if (strchr(cn->corename, ' ')) + return -EINVAL; + + /* + * Currently no need to parse any other options. + * Relevant information can be retrieved from the peer + * pidfd retrievable via SO_PEERPIDFD by the receiver or + * via /proc/, using the SO_PEERPIDFD to guard + * against pid recycling when opening /proc/. + */ + return 0; + } + default: + WARN_ON_ONCE(cn->core_type !=3D COREDUMP_FILE); + break; } =20 /* Repeat as long as we have more pattern to process and more output @@ -801,6 +841,73 @@ void do_coredump(const kernel_siginfo_t *siginfo) } break; } + case COREDUMP_SOCK: { + struct file *file __free(fput) =3D NULL; +#ifdef CONFIG_UNIX + ssize_t addr_size; + struct sockaddr_un unix_addr =3D { + .sun_family =3D AF_UNIX, + }; + struct sockaddr_storage *addr; + + /* + * TODO: We need to really support core_pipe_limit to + * prevent the task from being reaped before userspace + * had a chance to look at /proc/. + * + * I need help from the networking people (or maybe Oleg + * also knows?) how to do this. + * + * IOW, we need to wait for the other side to shutdown + * the socket/terminate the connection. + * + * We could just read but then userspace could sent us + * SCM_RIGHTS and we just shouldn't need to deal with + * any of that. + */ + if (WARN_ON_ONCE(core_pipe_limit)) { + retval =3D -EINVAL; + goto close_fail; + } + + retval =3D strscpy(unix_addr.sun_path, cn.corename, sizeof(unix_addr.sun= _path)); + if (retval < 0) + goto close_fail; + addr_size =3D offsetof(struct sockaddr_un, sun_path) + retval + 1, + + file =3D __sys_socket_file(AF_UNIX, SOCK_STREAM, 0); + if (IS_ERR(file)) + goto close_fail; + + /* + * It is possible that the userspace process which is + * supposed to handle the coredump and is listening on + * the AF_UNIX socket coredumps. This should be fine + * though. If this was the only process which was + * listen()ing on the AF_UNIX socket for coredumps it + * obviously won't be listen()ing anymore by the time it + * gets here. So the __sys_connect_file() call will + * often fail with ECONNREFUSED and the coredump. + * + * In general though, userspace should just mark itself + * non dumpable and not do any of this nonsense. We + * shouldn't work around this. + */ + addr =3D (struct sockaddr_storage *)(&unix_addr); + retval =3D __sys_connect_file(file, addr, addr_size, O_CLOEXEC); + if (retval) + goto close_fail; + + /* The peer isn't supposed to write and we for sure won't read. */ + retval =3D __sys_shutdown_sock(sock_from_file(file), SHUT_RD); + if (retval) + goto close_fail; + + cprm.limit =3D RLIM_INFINITY; +#endif + cprm.file =3D no_free_ptr(file); + break; + } default: WARN_ON_ONCE(true); retval =3D -EINVAL; @@ -818,7 +925,10 @@ void do_coredump(const kernel_siginfo_t *siginfo) * have this set to NULL. */ if (!cprm.file) { - coredump_report_failure("Core dump to |%s disabled", cn.corename); + if (cn.core_type =3D=3D COREDUMP_PIPE) + coredump_report_failure("Core dump to |%s disabled", cn.corename); + else + coredump_report_failure("Core dump to :%s disabled", cn.corename); goto close_fail; } if (!dump_vma_snapshot(&cprm)) @@ -839,8 +949,25 @@ void do_coredump(const kernel_siginfo_t *siginfo) file_end_write(cprm.file); free_vma_snapshot(&cprm); } - if ((cn.core_type =3D=3D COREDUMP_PIPE) && core_pipe_limit) - wait_for_dump_helpers(cprm.file); + + if (core_pipe_limit) { + switch (cn.core_type) { + case COREDUMP_PIPE: + wait_for_dump_helpers(cprm.file); + break; + case COREDUMP_SOCK: { + /* + * TODO: Wait for the coredump handler to shut + * down the socket so we prevent the task from + * being reaped. + */ + break; + } + default: + break; + } + } + close_fail: if (cprm.file) filp_close(cprm.file, NULL); @@ -1070,7 +1197,7 @@ EXPORT_SYMBOL(dump_align); void validate_coredump_safety(void) { if (suid_dumpable =3D=3D SUID_DUMP_ROOT && - core_pattern[0] !=3D '/' && core_pattern[0] !=3D '|') { + core_pattern[0] !=3D '/' && core_pattern[0] !=3D '|' && core_pattern[= 0] !=3D ':') { =20 coredump_report_failure("Unsafe core_pattern used with fs.suid_dumpable= =3D2: " "pipe handler or fully qualified core dump path required. " --=20 2.47.2 From nobody Sun Feb 8 08:42:51 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CA809255F49; Fri, 2 May 2025 12:43:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746189782; cv=none; b=iLBcmUa5pxlMahySDYM6ec1xH1Q6DYL99JqvomHCRNpR6uZJO5A0Oy8nW5Rdnff418jm1l4Pigb3g3jodOpKn7PizbNE4thkQr0IFbNV0h2aIk1nwS5WUnG+MbBdbwu6ncCuxI9vhMXtqUM/6zu87uF5czp+6kem3x2qRRpCcaM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746189782; c=relaxed/simple; bh=NhE2hFgc61WAQVF5mM6Mii0VL7txusY2shDJ6wbW/tk=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=Ya59JTsMLGMd/grg6DHVwJGRZysSFBLBcpry10fhbpb2PcwcJxKlD2rLJukDCWkgevU5TtoYBZVq8U7mWCTSeSgE6I9iz3EQJ5mIYRIcKodKxQOgvPIc2L1yCLbaCcidzWGqZK2J3HM7OyPw26alJxmfufNhRZBhK0CRLT/Rvp0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MsoFxfiD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MsoFxfiD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 871FDC4CEEB; Fri, 2 May 2025 12:42:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746189782; bh=NhE2hFgc61WAQVF5mM6Mii0VL7txusY2shDJ6wbW/tk=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=MsoFxfiD42mggzSTl5WY9oKWthZvSFgeqnws7iz29iGLCej5NHo4tWo9LL9kQmEG8 CMbc5E/vJftCUtxKv1WC2CPbrS5Jzm9NzR+6inZQA04j4DWyO2w0J0AF4pPMQ1gUaZ 7hdJqB2K7Rin4c9hPHok7+Bjs9DBz8CEMZGrzKUl3XLJ9gYjhLN6DwNdUwwUr7lxVv 7voIIymRURBbqsiA3bxjhH809irT+b8LTarhXwwUb7bWHiRZFoEjsMSVh83w+SfaMn 6cUGJMrMMeDu5B0AZb+6I7MwVv0KHFBdCkJrBZALXoYwwPAWR8QHSnqlUTAHW/6HzF ioKLLlo0CFsTA== From: Christian Brauner Date: Fri, 02 May 2025 14:42:35 +0200 Subject: [PATCH RFC v2 4/6] coredump: show supported coredump modes Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250502-work-coredump-socket-v2-4-43259042ffc7@kernel.org> References: <20250502-work-coredump-socket-v2-0-43259042ffc7@kernel.org> In-Reply-To: <20250502-work-coredump-socket-v2-0-43259042ffc7@kernel.org> To: Eric Dumazet , Kuniyuki Iwashima , Oleg Nesterov , linux-fsdevel@vger.kernel.org, Jann Horn Cc: "David S. Miller" , Alexander Viro , Daan De Meyer , David Rheinsberg , Jakub Kicinski , Jan Kara , Lennart Poettering , Luca Boccassi , Mike Yuan , Paolo Abeni , Simon Horman , =?utf-8?q?Zbigniew_J=C4=99drzejewski-Szmek?= , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Christian Brauner X-Mailer: b4 0.15-dev-c25d1 X-Developer-Signature: v=1; a=openpgp-sha256; l=1137; i=brauner@kernel.org; h=from:subject:message-id; bh=NhE2hFgc61WAQVF5mM6Mii0VL7txusY2shDJ6wbW/tk=; b=owGbwMvMwCU28Zj0gdSKO4sYT6slMWSI7D0gs/VbQOHn/2/vSUyRLmD99DBG01VBRj+aYdn3y 25nnme+7ShlYRDjYpAVU2RxaDcJl1vOU7HZKFMDZg4rE8gQBi5OAZjI3J+MDDeL2udn7b7y2V28 8vDRFak5F3bzph+dp2xTzhdzff+6ahaGf5rtp/U3NWpaax8rktG2uLj/UfAvY6eAw59mnl/p/jJ yOTcA X-Developer-Key: i=brauner@kernel.org; a=openpgp; fpr=4880B8C9BD0E5106FC070F4F7B3C391EFEA93624 Allow userspace to discover what coredump modes are supported. Signed-off-by: Christian Brauner --- fs/coredump.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/fs/coredump.c b/fs/coredump.c index 9a6cba233db9..1c7428c23878 100644 --- a/fs/coredump.c +++ b/fs/coredump.c @@ -1217,6 +1217,13 @@ static int proc_dostring_coredump(const struct ctl_t= able *table, int write, =20 static const unsigned int core_file_note_size_min =3D CORE_FILE_NOTE_SIZE_= DEFAULT; static const unsigned int core_file_note_size_max =3D CORE_FILE_NOTE_SIZE_= MAX; +static char core_modes[] =3D { +#ifdef CONFIG_UNIX + "file\npipe\nunix" +#else + "file\npipe" +#endif +}; =20 static const struct ctl_table coredump_sysctls[] =3D { { @@ -1260,6 +1267,13 @@ static const struct ctl_table coredump_sysctls[] =3D= { .extra1 =3D SYSCTL_ZERO, .extra2 =3D SYSCTL_ONE, }, + { + .procname =3D "core_modes", + .data =3D core_modes, + .maxlen =3D sizeof(core_modes) - 1, + .mode =3D 0444, + .proc_handler =3D proc_dostring, + }, }; =20 static int __init init_fs_coredump_sysctls(void) --=20 2.47.2 From nobody Sun Feb 8 08:42:51 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 99C802561D4; Fri, 2 May 2025 12:43:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746189787; cv=none; b=U/T27peU4f/wT5JTdIApwUDj8isJYdg48Ec4dLb/Nm+bG/Fl47wfalI16+tyhIpEyIlle1rErwckChIfDs5kWmcWLTJwW1HYxf+LdxmuFyDPn0g7KuIsXnclpSaRvT0T9V9dmRT3tn8aGery5F/kpqGqyC9cYW+pXPKHRgatB/U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746189787; c=relaxed/simple; bh=Q+HdCX2y54OlEoGDyCxnEP5wtN8IQL7luYDJY8KMhvs=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=jyyDH+l7f9icqB3ru0d5aVGFiGzZIuLCAi7s/l6N/1GV2hHH/sQB9VOPQ+GnDbV48Z3lQNF9p0SkzK2LlSMApMWXtAexDYLn+WIy2rrJ5m2nhsULhQvzwfaUZn1UtpA9ehHl1nk7Zch2WmfaAqkiKwekr7oH/perua+L3vBXAJs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hJT/EH56; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hJT/EH56" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22284C4CEEB; Fri, 2 May 2025 12:43:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746189787; bh=Q+HdCX2y54OlEoGDyCxnEP5wtN8IQL7luYDJY8KMhvs=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=hJT/EH56YF0tFr1a5Ft92cdpoOK90Gr51NzmVkRhJBJk10YMJjWFViFrQQHcUNyjR VsImmr8Q1eM8bR9CCLUS1mmWv68iOlqljrhzQg1ju3G4XTEjeQgORxxGZTJg1g10Bg IPggo2HLspXm5KugsRDc+MlUb4vJcDdE589+mj+6gn1ejSCyOLrQAsABAnoCjr62+Z d7efoBqEIzkqNJM7Cb2fjT7R4rwJIPBYtrWAem08F7l9ECHuLn+knop2Vev+eF7ZWI KcL9xHbxMThE1SBXk7SUPhVRAKDSn9Jhd4M/qx+BlhV2pKVj7StsUe+s76+mYGXbgM zRL+E9EbfdFtg== From: Christian Brauner Date: Fri, 02 May 2025 14:42:36 +0200 Subject: [PATCH RFC v2 5/6] pidfs, coredump: add PIDFD_INFO_COREDUMP Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250502-work-coredump-socket-v2-5-43259042ffc7@kernel.org> References: <20250502-work-coredump-socket-v2-0-43259042ffc7@kernel.org> In-Reply-To: <20250502-work-coredump-socket-v2-0-43259042ffc7@kernel.org> To: Eric Dumazet , Kuniyuki Iwashima , Oleg Nesterov , linux-fsdevel@vger.kernel.org, Jann Horn Cc: "David S. Miller" , Alexander Viro , Daan De Meyer , David Rheinsberg , Jakub Kicinski , Jan Kara , Lennart Poettering , Luca Boccassi , Mike Yuan , Paolo Abeni , Simon Horman , =?utf-8?q?Zbigniew_J=C4=99drzejewski-Szmek?= , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Christian Brauner X-Mailer: b4 0.15-dev-c25d1 X-Developer-Signature: v=1; a=openpgp-sha256; l=6369; i=brauner@kernel.org; h=from:subject:message-id; bh=Q+HdCX2y54OlEoGDyCxnEP5wtN8IQL7luYDJY8KMhvs=; b=owGbwMvMwCU28Zj0gdSKO4sYT6slMWSI7D0Qf9p20QeNRrGnfaWCbVoJSZrxRvs1v6feMTEsO HtAac6ZjlIWBjEuBlkxRRaHdpNwueU8FZuNMjVg5rAygQxh4OIUgIm8jWD4Z+m2ZvL9ordSITXS D3epbTDaMM3ztI/gvujGhmtuTz7saWb4p8PfvOy69NdMn7O/Wn923T5ReTfYdc1Rd+dLGSYc74+ YcwAA X-Developer-Key: i=brauner@kernel.org; a=openpgp; fpr=4880B8C9BD0E5106FC070F4F7B3C391EFEA93624 Let userspace know that the task coredumped and whether it was dumped as root or as regular user. The latter is needed so that access permissions to the executable are correctly handled. I don't think this requires any additional privileges checks. The missing exposure of the dumpability attribute of a given task is an issue we should fix given that we already expose whether a task is coredumping or not. Signed-off-by: Christian Brauner --- fs/coredump.c | 5 ++++ fs/pidfs.c | 58 ++++++++++++++++++++++++++++++++++++++++++= ++++ include/linux/pidfs.h | 3 +++ include/uapi/linux/pidfd.h | 11 +++++++++ 4 files changed, 77 insertions(+) diff --git a/fs/coredump.c b/fs/coredump.c index 1c7428c23878..735b5b94c518 100644 --- a/fs/coredump.c +++ b/fs/coredump.c @@ -48,6 +48,7 @@ #include #include #include +#include =20 #include #include @@ -594,6 +595,8 @@ static int umh_coredump_setup(struct subprocess_info *i= nfo, struct cred *new) if (IS_ERR(pidfs_file)) return PTR_ERR(pidfs_file); =20 + pidfs_coredump(cp); + /* * Usermode helpers are childen of either * system_unbound_wq or of kthreadd. So we know that @@ -904,6 +907,8 @@ void do_coredump(const kernel_siginfo_t *siginfo) goto close_fail; =20 cprm.limit =3D RLIM_INFINITY; + cprm.pid =3D task_tgid(current); + pidfs_coredump(&cprm); #endif cprm.file =3D no_free_ptr(file); break; diff --git a/fs/pidfs.c b/fs/pidfs.c index 3b39e471840b..c891f4ef9c38 100644 --- a/fs/pidfs.c +++ b/fs/pidfs.c @@ -20,6 +20,7 @@ #include #include #include +#include =20 #include "internal.h" #include "mount.h" @@ -33,6 +34,7 @@ static struct kmem_cache *pidfs_cachep __ro_after_init; struct pidfs_exit_info { __u64 cgroupid; __s32 exit_code; + __s32 coredump_mask; }; =20 struct pidfs_inode { @@ -240,6 +242,22 @@ static inline bool pid_in_current_pidns(const struct p= id *pid) return false; } =20 +static __u32 pidfs_coredump_mask(unsigned long mm_flags) +{ + switch (__get_dumpable(mm_flags)) { + case SUID_DUMP_USER: + return PIDFD_COREDUMP_USER; + case SUID_DUMP_ROOT: + return PIDFD_COREDUMP_ROOT; + case SUID_DUMP_DISABLE: + return PIDFD_COREDUMP_SKIP; + default: + WARN_ON_ONCE(true); + } + + return 0; +} + static long pidfd_info(struct file *file, unsigned int cmd, unsigned long = arg) { struct pidfd_info __user *uinfo =3D (struct pidfd_info __user *)arg; @@ -292,6 +310,21 @@ static long pidfd_info(struct file *file, unsigned int= cmd, unsigned long arg) goto copy_out; } =20 + /* + * Should we require privilege to access that information? Seems + * pointless because we already expose whether a task is + * coredumping in /proc//status. + */ + if (mask & PIDFD_INFO_COREDUMP) { + kinfo.mask |=3D PIDFD_INFO_COREDUMP; + kinfo.coredump_mask =3D READ_ONCE(pidfs_i(inode)->__pei.coredump_mask); + if (!kinfo.coredump_mask) { + task_lock(task); + kinfo.coredump_mask =3D pidfs_coredump_mask(task->mm->flags); + task_unlock(task); + } + } + c =3D get_task_cred(task); if (!c) return -ESRCH; @@ -559,6 +592,31 @@ void pidfs_exit(struct task_struct *tsk) } } =20 +void pidfs_coredump(const struct coredump_params *cprm) +{ + struct pid *pid =3D cprm->pid; + struct pidfs_exit_info *exit_info; + struct dentry *dentry; + struct inode *inode; + __u32 coredump_mask =3D 0; + + dentry =3D stashed_dentry_get(&pid->stashed); + if (WARN_ON_ONCE(!dentry)) + return; + + inode =3D d_inode(dentry); + exit_info =3D &pidfs_i(inode)->__pei; + /* Note how we were coredumped. */ + coredump_mask =3D pidfs_coredump_mask(cprm->mm_flags); + /* Note that we actually did coredump. */ + coredump_mask |=3D PIDFD_COREDUMPED; + /* If coredumping is set to skip we should never end up here. */ + VFS_WARN_ON_ONCE(coredump_mask & PIDFD_COREDUMP_SKIP); + smp_store_release(&exit_info->coredump_mask, coredump_mask); + /* Fwiw, this cannot be the last reference. */ + dput(dentry); +} + static struct vfsmount *pidfs_mnt __ro_after_init; =20 /* diff --git a/include/linux/pidfs.h b/include/linux/pidfs.h index 2676890c4d0d..f7729b9371bc 100644 --- a/include/linux/pidfs.h +++ b/include/linux/pidfs.h @@ -2,11 +2,14 @@ #ifndef _LINUX_PID_FS_H #define _LINUX_PID_FS_H =20 +struct coredump_params; + struct file *pidfs_alloc_file(struct pid *pid, unsigned int flags); void __init pidfs_init(void); void pidfs_add_pid(struct pid *pid); void pidfs_remove_pid(struct pid *pid); void pidfs_exit(struct task_struct *tsk); +void pidfs_coredump(const struct coredump_params *cprm); extern const struct dentry_operations pidfs_dentry_operations; int pidfs_register_pid(struct pid *pid); void pidfs_get_pid(struct pid *pid); diff --git a/include/uapi/linux/pidfd.h b/include/uapi/linux/pidfd.h index 8c1511edd0e9..b7c831f4cf4b 100644 --- a/include/uapi/linux/pidfd.h +++ b/include/uapi/linux/pidfd.h @@ -25,9 +25,19 @@ #define PIDFD_INFO_CREDS (1UL << 1) /* Always returned, even if not reque= sted */ #define PIDFD_INFO_CGROUPID (1UL << 2) /* Always returned if available, e= ven if not requested */ #define PIDFD_INFO_EXIT (1UL << 3) /* Only returned if requested. */ +#define PIDFD_INFO_COREDUMP (1UL << 4) /* Only returned if requested. */ =20 #define PIDFD_INFO_SIZE_VER0 64 /* sizeof first published struct */ =20 +/* + * Values for @coredump_mask in pidfd_info. + * Only valid if PIDFD_INFO_SUID_COREDUMP is set in @mask. + */ +#define PIDFD_COREDUMPED (1U << 0) /* Did crash and... */ +#define PIDFD_COREDUMP_SKIP (1U << 1) /* coredumping generation was skippe= d. */ +#define PIDFD_COREDUMP_USER (1U << 2) /* coredump was done as the user. */ +#define PIDFD_COREDUMP_ROOT (1U << 3) /* coredump was done as root. */ + /* * The concept of process and threads in userland and the kernel is a conf= using * one - within the kernel every thread is a 'task' with its own individua= l PID, @@ -92,6 +102,7 @@ struct pidfd_info { __u32 fsuid; __u32 fsgid; __s32 exit_code; + __u32 coredump_mask; }; =20 #define PIDFS_IOCTL_MAGIC 0xFF --=20 2.47.2 From nobody Sun Feb 8 08:42:51 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1872F254AF8; Fri, 2 May 2025 12:43:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746189792; cv=none; b=Tw34LRd0T4GB16gQo1tZmsNOvgN838u3pnDS1FwietdQ+e/CxDMA5eDQ/etmu9Z2/jimlB1LaSpN1uAndPebYgdK9Bi9wwjYLsZl3M+hfupTlugCx08nlQ7RlFLvurrBg+b2qeNmrv+C6GsPjCLtLRT8cxKN9MZYnqKq4X7eI9A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746189792; c=relaxed/simple; bh=vWvdauE0P4tZXK3aJ6k30xFFFQGEsyt1LCtOQc4zs2U=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=WIXIxBGXs4P9KGTFwBeRGck07qJCSfOZwxJ10hNut0Z+fm75q8RzgrtGSWzRXgMmv5OMOCoNKOAFl3z3jYLCtIc9SNpYglW2ZTfvvSs6T2bKxtfK9EO33GEdoAFPSfdmdPdUrK5r9lUT5OJDLURQ+A16CslnKtZBPFj7QHY+WbM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XYqTei7I; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XYqTei7I" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 88201C4CEE4; Fri, 2 May 2025 12:43:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746189791; bh=vWvdauE0P4tZXK3aJ6k30xFFFQGEsyt1LCtOQc4zs2U=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=XYqTei7Iu717MS6b7ipZKgw+7d6TYnrO/ZshwmXBbtxlMtnnKr4OPPLjqd0vPkAgT n6YHXGQLnlEcyvPAZ0Dwe5y9QCGcHYp/kyb5Kdj1i2iU/sMZIY6rrR5Yr0RlElFezm 8OAQ2ZoMohXDDtwTtfPBLehkR4OV8jMs9Nfm7Ve5kFFWIs2Bvh9xY4EWqecGiUbPkx 09i1q73tAANoD9XJeieDt+YFOEme7kJwGAdD9C/hNbMb/NrN8Y1BJNDwJUOoNWX4Aq b6CEGrdd7oJk8uAoge6agezK+xLh20eYi8QifSVinXAOyyZo9KjIUHoJ5lHFuSo6d8 0TpZCwYd5xADw== From: Christian Brauner Date: Fri, 02 May 2025 14:42:37 +0200 Subject: [PATCH RFC v2 6/6] selftests/coredump: add tests for AF_UNIX coredumps Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250502-work-coredump-socket-v2-6-43259042ffc7@kernel.org> References: <20250502-work-coredump-socket-v2-0-43259042ffc7@kernel.org> In-Reply-To: <20250502-work-coredump-socket-v2-0-43259042ffc7@kernel.org> To: Eric Dumazet , Kuniyuki Iwashima , Oleg Nesterov , linux-fsdevel@vger.kernel.org, Jann Horn Cc: "David S. Miller" , Alexander Viro , Daan De Meyer , David Rheinsberg , Jakub Kicinski , Jan Kara , Lennart Poettering , Luca Boccassi , Mike Yuan , Paolo Abeni , Simon Horman , =?utf-8?q?Zbigniew_J=C4=99drzejewski-Szmek?= , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Christian Brauner X-Mailer: b4 0.15-dev-c25d1 X-Developer-Signature: v=1; a=openpgp-sha256; l=2158; i=brauner@kernel.org; h=from:subject:message-id; bh=vWvdauE0P4tZXK3aJ6k30xFFFQGEsyt1LCtOQc4zs2U=; b=owGbwMvMwCU28Zj0gdSKO4sYT6slMWSI7D1w0ctzz1Ephx8XKvuajIUbKwye+8azC7CvF/5iU aVY9lq7o5SFQYyLQVZMkcWh3SRcbjlPxWajTA2YOaxMIEMYuDgFYCLvDRn+pznNU5+QMM/DJ32b 6xf3vdLLTzE63PG2mmLgHinpyV7szsgw+3XpQ6e0RX/q+DPsL+jJp20/8G3VBNvMKWxsGl/sHd6 wAQA= X-Developer-Key: i=brauner@kernel.org; a=openpgp; fpr=4880B8C9BD0E5106FC070F4F7B3C391EFEA93624 Add a simple test for generating coredumps via AF_UNIX sockets. Signed-off-by: Christian Brauner --- tools/testing/selftests/coredump/stackdump_test.c | 50 +++++++++++++++++++= ++++ 1 file changed, 50 insertions(+) diff --git a/tools/testing/selftests/coredump/stackdump_test.c b/tools/test= ing/selftests/coredump/stackdump_test.c index fe3c728cd6be..ccaee98dbee3 100644 --- a/tools/testing/selftests/coredump/stackdump_test.c +++ b/tools/testing/selftests/coredump/stackdump_test.c @@ -5,7 +5,9 @@ #include #include #include +#include #include +#include #include =20 #include "../kselftest_harness.h" @@ -154,4 +156,52 @@ TEST_F_TIMEOUT(coredump, stackdump, 120) fclose(file); } =20 +TEST_F(coredump, socket) +{ + int fd, ret, status; + FILE *file; + pid_t pid, pid_socat; + struct stat st; + char core_file[PATH_MAX]; + + ASSERT_EQ(unshare(CLONE_NEWNS), 0); + ASSERT_EQ(mount(NULL, "/", NULL, MS_PRIVATE | MS_REC, NULL), 0); + ASSERT_EQ(mount(NULL, "/tmp", "tmpfs", 0, NULL), 0); + + pid_socat =3D fork(); + ASSERT_GE(pid_socat, 0); + if (pid_socat =3D=3D 0) { + execlp("socat", "socat", + "unix-listen:/tmp/coredump.socket,fork", + "FILE:/tmp/coredump_file,create,append,trunc", + (char *)NULL); + _exit(EXIT_FAILURE); + } + + file =3D fopen("/proc/sys/kernel/core_pattern", "w"); + ASSERT_NE(NULL, file); + + ret =3D fprintf(file, ":/tmp/coredump.socket"); + ASSERT_EQ(ret, strlen(":/tmp/coredump.socket")); + ASSERT_EQ(fclose(file), 0); + + pid =3D fork(); + ASSERT_GE(pid, 0); + if (pid =3D=3D 0) + crashing_child(); + + waitpid(pid, &status, 0); + ASSERT_TRUE(WIFSIGNALED(status)); + ASSERT_TRUE(WCOREDUMP(status)); + + ASSERT_EQ(kill(pid_socat, SIGTERM), 0); + waitpid(pid_socat, &status, 0); + ASSERT_TRUE(WIFEXITED(status)); + ASSERT_EQ(WEXITSTATUS(status), 143); + + /* We should somehow validate the produced core file. */ + ASSERT_EQ(stat("/tmp/coredump_file", &st), 0); + ASSERT_GT(st.st_size, 0); +} + TEST_HARNESS_MAIN --=20 2.47.2