Linux filesystem development
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Luca Boccassi <bluca@debian.org>,
	stable@kernel.org,  linux-fsdevel@vger.kernel.org
Subject: Re: Please consider backporting coredump %F patch to stable kernels
Date: Mon, 2 Jun 2025 13:45:02 +0200	[thread overview]
Message-ID: <20250602-eilte-experiment-4334f67dc5d8@brauner> (raw)
In-Reply-To: <2025060211-egotistic-overnight-9d10@gregkh>

On Mon, Jun 02, 2025 at 11:32:44AM +0200, Greg Kroah-Hartman wrote:
> On Mon, Jun 02, 2025 at 11:09:05AM +0200, Christian Brauner wrote:
> > On Fri, May 30, 2025 at 10:44:16AM +0100, Luca Boccassi wrote:
> > > Dear stable maintainer(s),
> > > 
> > > The following series was merged for 6.16:
> > > 
> > > https://lore.kernel.org/all/20250414-work-coredump-v2-0-685bf231f828@kernel.org/
> > > 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c57f07b235871c9e5bffaccd458dca2d9a62b164
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95c5f43181fe9c1b5e5a4bd3281c857a5259991f
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b5325b2a270fcaf7b2a9a0f23d422ca8a5a8bdea
> > > 
> > > This allows the userspace coredump handler to get a PIDFD referencing
> > > the crashed process.
> > > 
> > > We have discovered that there are real world exploits that can be used
> > > to trick coredump handling userspace software to act on foreign
> > > processes due to PID reuse attacks:
> > > 
> > > https://security-tracker.debian.org/tracker/CVE-2025-4598
> > > 
> > > We have fixed the worst case scenario, but to really and
> > > comprehensively fix the whole problem we need this new %F option. We
> > > have backported the userspace side to the systemd stable branch. Would
> > > it be possible to backport the above 3 patches to at least the 6.12
> > > series, so that the next Debian stable can be fully covered? The first
> > > two are small bug fixes so it would be good to have them, and the
> > > third one is quite small and unless explicitly configured in the
> > > core_pattern, it will be inert, so risk should be low.
> > 
> > I agree that we should try and backport this if Greg agrees we can do
> > this. v6.15 will be easy to do. Further back might need some custom work
> > though. Let's see what Greg thinks.
> 
> Yes, seems like a good thing to backport to at least 6.12.y if possible.
> 
> Is it just the above 3 commits?

Yes, just those three:

b5325b2a270f ("coredump: hand a pidfd to the usermode coredump helper")
95c5f43181fe ("coredump: fix error handling for replace_fd()")
c57f07b23587 ("pidfs: move O_RDWR into pidfs_alloc_file()")

That should apply cleanly to v6.15 but for the others it requires custom
backports. So here are a couple of trees all based on linux-*.*.y from
the stable repo. You might need to adjust to your stable commit message
format though:

v6.12:
https://github.com/brauner/linux-stable/tree/vfs-6.12.coredump.pidfd

v6.6:
https://github.com/brauner/linux-stable/tree/vfs-6.6.coredump.pidfd

v6.1:
https://github.com/brauner/linux-stable/tree/vfs-6.1.coredump.pidfd

v5.14
https://github.com/brauner/linux-stable/tree/vfs-5.14.coredump.pidfd

v5.10
https://github.com/brauner/linux-stable/tree/vfs-5.10.coredump.pidfd

v5.4
https://github.com/brauner/linux-stable/tree/vfs-5.4.coredump.pidfd

  reply	other threads:[~2025-06-02 11:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-30  9:44 Please consider backporting coredump %F patch to stable kernels Luca Boccassi
2025-06-02  9:09 ` Christian Brauner
2025-06-02  9:32   ` Greg Kroah-Hartman
2025-06-02 11:45     ` Christian Brauner [this message]
2025-06-02 12:06       ` Greg Kroah-Hartman
2025-06-02 12:13         ` Christian Brauner
2025-06-02 12:32           ` Christian Brauner
2025-06-02 12:49             ` Greg Kroah-Hartman
2025-06-02 13:06               ` Christian Brauner
2025-06-02 13:39                 ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250602-eilte-experiment-4334f67dc5d8@brauner \
    --to=brauner@kernel.org \
    --cc=bluca@debian.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=stable@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox