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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.