From nobody Tue Jun 16 19:32:19 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 D7E0A4A33F9; Mon, 20 Apr 2026 13:32:46 +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=1776691966; cv=none; b=EjQjFgBYRNsefQouzYIqzqiwPJ402FKOAYODNo/t+6+pzIQW1eiJ94Ly4BfqbHZU660/PH8CIXYr5zE67hS5gS3PikJx7KUeEfVHPVrv7jV1fz3uzM5ehMIlYWOSIJcBdmV/nFwySL9BkS87Nh46Yu1SvUVimBguy3Qy+RVuwFo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776691966; c=relaxed/simple; bh=gyXi7Wuu5MP4FEFcZJMgcVPb0NAvr7dTrU/QX0T4Gsg=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=hbXTXQEnoan1u/L08jXVBVI5N9Ftlf6mvWGu8ZM+NXx2F7gPZFCavTXUu9DrKZmaF99s+uYZpeCRkXmQMnnwV+oEmCh2zSbTuENbKHMK8b89sAgqJVJzIvUPjB+1LEQwAKIRgVIMmuRy6SJZi8VvtSPElmj1d/ICEe20mHjihSM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=r0OQMdEg; 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="r0OQMdEg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 515AFC19425; Mon, 20 Apr 2026 13:32:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776691966; bh=gyXi7Wuu5MP4FEFcZJMgcVPb0NAvr7dTrU/QX0T4Gsg=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=r0OQMdEgh7amMOCw1wRY/70I4tb0MmUD3a1N7c9Lm0qEtp69OD0/7DbxddYGaN00g yjq6QO0Ph0GpfXlXskkAKKOCP9G152v4Gcb4iIa8hkNAMnjJznjNCT+4xN+rDUvHvK ErAJFITXhyuFmfsUWIthDZyQUeJ6KeNVhk3MW2FzLczvs7mk6hR41HBE5M7WgGcN6P 5kXNGvNM4mq3WjvwUV9M+Na0fj+mKqH38GVteN7tCRWnrzRb3pmf3Y7Zq6KjH8fb+r Ezk9Le8cF5HnjmDlhxk7CUccu+TIXz5+R4GHXGIpmq3lLDH/bhDugqktYlcWogk9VB vjXEHFoJNE3iQ== From: Christian Brauner Date: Mon, 20 Apr 2026 15:32:35 +0200 Subject: [PATCH 1/3] pidfs: fix PIDFD_THREAD flag loss when opening pidfds via file handles 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: <20260420-work-pidfs-v1-1-4bd614e1cb33@kernel.org> References: <20260420-work-pidfs-v1-0-4bd614e1cb33@kernel.org> In-Reply-To: <20260420-work-pidfs-v1-0-4bd614e1cb33@kernel.org> To: linux-fsdevel@vger.kernel.org Cc: Alexander Viro , Jan Kara , linux-kernel@vger.kernel.org, "Christian Brauner (Amutable)" X-Mailer: b4 0.16-dev X-Developer-Signature: v=1; a=openpgp-sha256; l=2810; i=brauner@kernel.org; h=from:subject:message-id; bh=gyXi7Wuu5MP4FEFcZJMgcVPb0NAvr7dTrU/QX0T4Gsg=; b=owGbwMvMwCU28Zj0gdSKO4sYT6slMWQ+0/qlIjm/kP3B/29L3u3b7j3vxrsUtqSZXl867vNdN dhTv3/q1I5SFgYxLgZZMUUWh3aTcLnlPBWbjTI1YOawMoEMYeDiFICJ1Egw/LM6fO8pt7mwzMqN jhc2bX7zIn+L1I0i58tM/3/J117dGB3H8L9C+FTtRaNtbSuT3fs+L2f0XK17oXVn6A5fS7PATo2 uxdwA X-Developer-Key: i=brauner@kernel.org; a=openpgp; fpr=4880B8C9BD0E5106FC070F4F7B3C391EFEA93624 pidfs_export_open() calls dentry_open() which internally calls do_dentry_open() that strips O_EXCL from f_flags. Since PIDFD_THREAD is defined as O_EXCL, thread pidfds opened via open_by_handle_at() silently lose their thread-specific scope. pidfs_alloc_file() already handles this by explicitly restoring the PIDFD_THREAD flag after dentry_open() returns. Factor the common dentry_open() + flag restoration into a shared pidfs_open_file() helper and use it from both call sites. Without this fix, a pidfd obtained via open_by_handle_at() with O_EXCL will have PIDTYPE_TGID scope instead of PIDTYPE_PID scope, causing pidfd_send_signal() to deliver signals to the entire thread group instead of the specific thread. Fixes: 30915e955528 ("pidfs: convert to path_from_stashed() helper") Signed-off-by: Christian Brauner Reviewed-by: Jan Kara --- fs/pidfs.c | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/fs/pidfs.c b/fs/pidfs.c index e3825ee246be..11eb53f3e50a 100644 --- a/fs/pidfs.c +++ b/fs/pidfs.c @@ -897,14 +897,28 @@ static int pidfs_export_permission(struct handle_to_p= ath_ctx *ctx, return 0; } =20 +/* + * Open a pidfs dentry. Pidfds are always O_RDWR and PIDFD_THREAD (O_EXCL) + * must be restored after dentry_open() as do_dentry_open() strips it. + */ +static struct file *pidfs_open_file(const struct path *path, unsigned int = flags) +{ + struct file *f; + + flags |=3D O_RDWR; + f =3D dentry_open(path, flags, current_cred()); + if (!IS_ERR(f)) + f->f_flags |=3D (flags & PIDFD_THREAD); + return f; +} + static struct file *pidfs_export_open(const struct path *path, unsigned in= t oflags) { /* - * Clear O_LARGEFILE as open_by_handle_at() forces it and raise - * O_RDWR as pidfds always are. + * Clear O_LARGEFILE as open_by_handle_at() forces it. */ oflags &=3D ~O_LARGEFILE; - return dentry_open(path, oflags | O_RDWR, current_cred()); + return pidfs_open_file(path, oflags); } =20 static const struct export_operations pidfs_export_operations =3D { @@ -1086,7 +1100,6 @@ static struct file_system_type pidfs_type =3D { =20 struct file *pidfs_alloc_file(struct pid *pid, unsigned int flags) { - struct file *pidfd_file; struct path path __free(path_put) =3D {}; int ret; =20 @@ -1104,13 +1117,7 @@ struct file *pidfs_alloc_file(struct pid *pid, unsig= ned int flags) VFS_WARN_ON_ONCE(!pid->attr); =20 flags &=3D ~PIDFD_STALE; - flags |=3D O_RDWR; - pidfd_file =3D dentry_open(&path, flags, current_cred()); - /* Raise PIDFD_THREAD explicitly as do_dentry_open() strips it. */ - if (!IS_ERR(pidfd_file)) - pidfd_file->f_flags |=3D (flags & PIDFD_THREAD); - - return pidfd_file; + return pidfs_open_file(&path, flags); } =20 void __init pidfs_init(void) --=20 2.47.3 From nobody Tue Jun 16 19:32:19 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 8C46A3ACA5A; Mon, 20 Apr 2026 13:32: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=1776691968; cv=none; b=H3lLUESr4V1sy5Q+mWU2tvvHfk5j2pEPjj5lEVbktAXLVJhJZDSrMeiOKcQOn4H+gJljQ/GTb5niVc8YV1PzU2gC33VCMR+TZJ1utVFpxdG8+kcHEe2qoOc8G4+1Ul2a2OsfNLMkhfDKx/ZyWaZG9dc5xbhrPeZ/mvgAAh0ySaU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776691968; c=relaxed/simple; bh=91T3siAjWjNZMFdndRhJZMMRG16pSjzssiPZfd5aOZg=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=bjCB1S7gha3d5kQGeQ08mGfsX/OB5Jf/1ih4Xff0fYJvNtb11wAzAs04K6yE2w+WUCsaCCaqfWA7pupbyBb9JA20rtkeirbd7sPLKD0/D/bYq7SRDiXVAVm/BdifDqi7vjKALtBX2h99B/ZOoksb//MM/xmDqAGj2/E3ZZeJkRo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TNBCp72A; 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="TNBCp72A" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3AD41C2BCB8; Mon, 20 Apr 2026 13:32:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776691968; bh=91T3siAjWjNZMFdndRhJZMMRG16pSjzssiPZfd5aOZg=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=TNBCp72AKsG8JDP2A+EaSBLdpZs/qQ15AIF4alZKMMxMjNLhPujjLZsbWrdxIZXVS FYEWGKjUcWfCnqDnCW3nDLZZiGmUrVyPIvN3OSO5lvyYCW5mixahwSjeY9q0QSTVro MTIOgmTcNb+oYUpqF5HHSphza4UcZ8VSt97uKoYQGv9fKVuHSWvgdymPgQoWpKYYQ6 k4gic/nnlBman7Lb9H/NzBdlElEWct365j416rhQOJOqnvHrRb+OlbzZqj4MQMAmsE FjsUvIgz/cD4tmp4xN99xEiBDk27SQ4LyEPhFSvVKutn0vYOMM7HtrepdoTmCla4Jf J4nwJ7eXJrPYw== From: Christian Brauner Date: Mon, 20 Apr 2026 15:32:36 +0200 Subject: [PATCH 2/3] pidfs: return -ENODATA from pidfs_xattr_get() when no xattrs exist 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: <20260420-work-pidfs-v1-2-4bd614e1cb33@kernel.org> References: <20260420-work-pidfs-v1-0-4bd614e1cb33@kernel.org> In-Reply-To: <20260420-work-pidfs-v1-0-4bd614e1cb33@kernel.org> To: linux-fsdevel@vger.kernel.org Cc: Alexander Viro , Jan Kara , linux-kernel@vger.kernel.org, "Christian Brauner (Amutable)" X-Mailer: b4 0.16-dev X-Developer-Signature: v=1; a=openpgp-sha256; l=959; i=brauner@kernel.org; h=from:subject:message-id; bh=91T3siAjWjNZMFdndRhJZMMRG16pSjzssiPZfd5aOZg=; b=owGbwMvMwCU28Zj0gdSKO4sYT6slMWQ+0/rNekwkfe255pyEa8tE7beHy3nrdncxvlv9QSin4 nJLT51sRykLgxgXg6yYIotDu0m43HKeis1GmRowc1iZQIYwcHEKwER6qhj+u5ofXKV15/xkvkjJ /e9Wv+5qez3/7vQvAUUzp8RMU3q1dhbDfy++cxs62Rj5fFYZtPw2MEo0ypxSv+wFy6f0x2rnLDa 85gYA X-Developer-Key: i=brauner@kernel.org; a=openpgp; fpr=4880B8C9BD0E5106FC070F4F7B3C391EFEA93624 When no xattrs have ever been set on a pidfd (attr->xattrs is NULL), pidfs_xattr_get() returns 0. The VFS interprets a return value of 0 as "xattr exists with a zero-length value", causing getxattr() to report success for non-existent xattrs. Return -ENODATA instead which is consistent with what simple_xattr_get() returns when an xattr is not found. Fixes: 5c1e4b9db95c ("pidfs: support xattrs on pidfds") Signed-off-by: Christian Brauner Reviewed-by: Jan Kara --- fs/pidfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/pidfs.c b/fs/pidfs.c index 11eb53f3e50a..2ab8fd2646f0 100644 --- a/fs/pidfs.c +++ b/fs/pidfs.c @@ -1023,7 +1023,7 @@ static int pidfs_xattr_get(const struct xattr_handler= *handler, =20 xattrs =3D READ_ONCE(attr->xattrs); if (!xattrs) - return 0; + return -ENODATA; =20 name =3D xattr_full_name(handler, suffix); return simple_xattr_get(xattrs, name, value, size); --=20 2.47.3 From nobody Tue Jun 16 19:32:19 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 1C2584A33F9; Mon, 20 Apr 2026 13:32:50 +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=1776691970; cv=none; b=jmYdw67dEhrE/EeLVf1VOtYe7EzvaLGTSHDQfLEctSu41ATf8BmnxMJuvtr3GUGGXknWtjvvRn6t0VaPWnmDAByQfURV0idhurJd5HPYCiveWHIdY5R2mEzu9dCuGSjkD8fz7v///E9MqkNcI0XdRITgB2Pt0msIRcELBWbioDc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776691970; c=relaxed/simple; bh=jx1CWyv2pvN98Qc7dFxzNUrg/J3h2PF8TmCc2/2xxUo=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=f0vyLK5ij4x3jjM+1s/8AYwEeNlHufuZsOHkaUYs7WFQv0O7Fdx/aMv5Rpv8uiI1v4qZdNiDO0vw7Qs5jtfJoQao1N4wCl7U0F1/X6PIeqb46lHEsybUVHaD2VVF/VaBq5mNHH6bKs/Cm74XmE+QudxHGJSYSe5n1Cs41mtgyz4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LqQ1Y5qq; 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="LqQ1Y5qq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CB5FAC19425; Mon, 20 Apr 2026 13:32:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776691970; bh=jx1CWyv2pvN98Qc7dFxzNUrg/J3h2PF8TmCc2/2xxUo=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=LqQ1Y5qqnQLEekKg3u8R1anJCQCwiKzvzCJ/Tj9Us3jAWwsXffRp7APkTM2nnz9a1 CSewq9BbT5pfQsgqZU7VrmATSGi0ssGtzx/zRQ8gDj9v4uhUMb8YgGpfdR+eELOiYc 4NynxB2xkbGFjQPY0qh2cuEYGuLHiIbYp+zVZbW4MWkkdLVkPz98JZMUym0AMRmMO4 AI3N3uSRW1ZSsSI/UYyqD7RMd0DMpV0flo4P7PWVPU8aD4BtaftHoagENpKQay7ON2 ynN5NFuIHKS+nvbe6ZO83tcP4anxSPDMXn08MsFunz9r0Ll8zEAAnVF0qk7RRWZBAv v0Lf4t3QPZ7RA== From: Christian Brauner Date: Mon, 20 Apr 2026 15:32:37 +0200 Subject: [PATCH 3/3] pidfs: don't report pidfd_info fields that won't fit in the user buffer 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: <20260420-work-pidfs-v1-3-4bd614e1cb33@kernel.org> References: <20260420-work-pidfs-v1-0-4bd614e1cb33@kernel.org> In-Reply-To: <20260420-work-pidfs-v1-0-4bd614e1cb33@kernel.org> To: linux-fsdevel@vger.kernel.org Cc: Alexander Viro , Jan Kara , linux-kernel@vger.kernel.org, "Christian Brauner (Amutable)" X-Mailer: b4 0.16-dev X-Developer-Signature: v=1; a=openpgp-sha256; l=2366; i=brauner@kernel.org; h=from:subject:message-id; bh=jx1CWyv2pvN98Qc7dFxzNUrg/J3h2PF8TmCc2/2xxUo=; b=owGbwMvMwCU28Zj0gdSKO4sYT6slMWQ+0/o9w/SxveJRlituiQt1Aif0K0+RaSzSmv0ivytQW a78frdXRykLgxgXg6yYIotDu0m43HKeis1GmRowc1iZQIYwcHEKwETWRzIydL+pn6tS/nfyZ/cs o27PPfNt2U6uOBTpXnTbhWu2obvCeYZ/xr0tpw9aXWW77R0TPGP1oimv5gpomXlFfRbdtlHhqGQ GNwA= X-Developer-Key: i=brauner@kernel.org; a=openpgp; fpr=4880B8C9BD0E5106FC070F4F7B3C391EFEA93624 The UAPI documentation for struct pidfd_info promises that if the structure provided by userspace is too small to contain a field, the kernel will not set the corresponding bit in the returned mask. The kernel violates this contract: it sets PIDFD_INFO_COREDUMP and PIDFD_INFO_COREDUMP_SIGNAL in the returned mask without checking that usize >=3D PIDFD_INFO_SIZE_VER1 (the coredump fields start at offset 64, beyond a VER0 buffer). Similarly, PIDFD_INFO_SUPPORTED_MASK is set without checking usize >=3D PIDFD_INFO_SIZE_VER2. While copy_struct_to_user() correctly only copies min(usize, ksize) bytes (so no kernel memory leaks), userspace that trusts the mask bits as documented may read its own uninitialized buffer and interpret it as valid data. Gate each set of mask bits on the user-provided struct being large enough to actually deliver the corresponding fields. Fixes: 9e77e4882bae ("pidfs: support retrieving supported pidfd_info flags") Signed-off-by: Christian Brauner --- fs/pidfs.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/fs/pidfs.c b/fs/pidfs.c index 2ab8fd2646f0..4c24d2eb7e41 100644 --- a/fs/pidfs.c +++ b/fs/pidfs.c @@ -375,7 +375,7 @@ static long pidfd_info(struct file *file, unsigned int = cmd, unsigned long arg) } } =20 - if (mask & PIDFD_INFO_COREDUMP) { + if ((mask & PIDFD_INFO_COREDUMP) && usize >=3D PIDFD_INFO_SIZE_VER1) { if (test_bit(PIDFS_ATTR_BIT_COREDUMP, &attr->attr_mask)) { smp_rmb(); kinfo.mask |=3D PIDFD_INFO_COREDUMP | PIDFD_INFO_COREDUMP_SIGNAL; @@ -400,7 +400,8 @@ static long pidfd_info(struct file *file, unsigned int = cmd, unsigned long arg) if (!c) return -ESRCH; =20 - if ((mask & PIDFD_INFO_COREDUMP) && !kinfo.coredump_mask) { + if ((mask & PIDFD_INFO_COREDUMP) && usize >=3D PIDFD_INFO_SIZE_VER1 && + !kinfo.coredump_mask) { guard(task_lock)(task); if (task->mm) { unsigned long flags =3D __mm_flags_get_dumpable(task->mm); @@ -455,7 +456,7 @@ static long pidfd_info(struct file *file, unsigned int = cmd, unsigned long arg) return -ESRCH; =20 copy_out: - if (mask & PIDFD_INFO_SUPPORTED_MASK) { + if ((mask & PIDFD_INFO_SUPPORTED_MASK) && usize >=3D PIDFD_INFO_SIZE_VER2= ) { kinfo.mask |=3D PIDFD_INFO_SUPPORTED_MASK; kinfo.supported_mask =3D PIDFD_INFO_SUPPORTED; } --=20 2.47.3