Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> writes:
> On Mon, Apr 04, 2022 at 11:00:19AM -0500, Eric W. Biederman wrote:
>> <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx>.
>>
>> 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
