From: "Eric W. Biederman" <ebiederm@xmission.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: keescook@chromium.org, willy@infradead.org, stable@vger.kernel.org
Subject: Re: FAILED: patch "[PATCH] coredump: Use the vma snapshot in fill_files_note" failed to apply to 5.17-stable tree
Date: Tue, 05 Apr 2022 09:24:04 -0500 [thread overview]
Message-ID: <87y20jip6j.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <YkvikRzy2ahCbGV6@kroah.com> (Greg KH's message of "Tue, 5 Apr 2022 08:32:49 +0200")
Greg KH <gregkh@linuxfoundation.org> writes:
> On Mon, Apr 04, 2022 at 11:00:19AM -0500, Eric W. Biederman wrote:
>> <gregkh@linuxfoundation.org> writes:
>>
>> > The patch below does not apply to the 5.17-stable tree.
>> > If someone wants it applied there, or to any other stable or longterm
>> > tree, then please email the backport, including the original git commit
>> > id to <stable@vger.kernel.org>.
>>
>> I believe it requires backporting these first.
>>
>> commit 84158b7f6a06 ("coredump: Also dump first pages of non-executable ELF libraries")
>> commit 95c5436a4883 ("coredump: Snapshot the vmas in do_coredump")
>> commit 49c1866348f3 ("coredump: Remove the WARN_ON in dump_vma_snapshot")
>>
>> The first is a more interesting bug fix from Jann Horn.
>> The other two are prerequisite cleanup-patches.
>
> Thanks, that worked!
>
>> I will let other folks judge how concerned they are about missing
>> locking that was detected by code review.
>
> locking where? And if it's not resolved in Linus's tree yet, not much I
> can do.
Sorry for being unclear. This patch "coredump: Use the vma snapshot in
fill_file_note" solves a problem of missing locking by refactoring code
so the locking is unnecessary.
> Also, what about for kernels older than 5.10? Is this an issue there?
The first fix for missing/problematic locking was added in
commit a07279c9a8cd ("binfmt_elf, binfmt_elf_fdpic: use a VMA list
snapshot"). Which is 5.10. I don't know if that fix has ever been backported.
The actual issue of problematic locking that this change was addressing
looks like it dates back to commit 2aa362c49c31 ("coredump: extend core
dump note section to contain file names of mapped files").
These are the kinds of bugs that creative people can use to get the
kernel to do things it is not supposed to do. On an ordinary day no one
trips over so they are not a problem. I am not good at assessing their
impact so I just fix them and let other people figure out how much they
want the fixes.
Eric
prev parent reply other threads:[~2022-04-05 21:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-02 11:36 FAILED: patch "[PATCH] coredump: Use the vma snapshot in fill_files_note" failed to apply to 5.17-stable tree gregkh
2022-04-04 16:00 ` Eric W. Biederman
2022-04-05 6:32 ` Greg KH
2022-04-05 6:36 ` Greg KH
2022-04-05 14:24 ` Eric W. Biederman [this message]
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=87y20jip6j.fsf@email.froward.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=gregkh@linuxfoundation.org \
--cc=keescook@chromium.org \
--cc=stable@vger.kernel.org \
--cc=willy@infradead.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;
as well as URLs for NNTP newsgroup(s).