lkml.org 
[lkml]   [2022]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] binfmt_elf: Take the mmap lock when walking the VMA list
On Mon, Jan 31, 2022 at 10:03:31AM -0600, Eric W. Biederman wrote:
> "Matthew Wilcox (Oracle)" <willy@infradead.org> writes:
>
> > I'm not sure if the VMA list can change under us, but dump_vma_snapshot()
> > is very careful to take the mmap_lock in write mode. We only need to
> > take it in read mode here as we do not care if the size of the stack
> > VMA changes underneath us.
> >
> > If it can be changed underneath us, this is a potential use-after-free
> > for a multithreaded process which is dumping core.
>
> The problem is not multi-threaded process so much as processes that
> share their mm.

I don't understand the difference. I appreciate that another process can
get read access to an mm through, eg, /proc, but how can another process
(that isn't a thread of this process) modify the VMAs?

> I think rather than take a lock we should be using the snapshot captured
> with dump_vma_snapshot. Otherwise we have the very real chance that the
> two get out of sync. Which would result in a non-sense core file.
>
> Probably that means that dump_vma_snapshot needs to call get_file on
> vma->vm_file store it in core_vma_metadata.
>
> Do you think you can fix it something like that?

Uhh .. that seems like it needs a lot more understanding of binfmt_elf
than I currently possess. I'd rather spend my time working on folios
than learning much more about binfmt_elf. I was just trying to fix an
assertion failure with the maple tree patches (we now assert that you're
holding a lock when walking the list of VMAs).

\
 
 \ /
  Last update: 2022-01-31 17:15    [W:0.048 / U:0.476 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site