On Thu, Sep 08, 2022 at 03:33:52PM -0700, Suren Baghdasaryan wrote:
> > However, mmap_locking was only added to the exit_mmap() path in commit
> > f798a1d4f94d ("mm: fix use-after-free bug when mm->mmap is reused after
> > being freed") and since this patch doesn't exist in v5.15 stable tree
Sorry, I meant 64591e8605d6 ("mm: protect free_pgtables with mmap_lock
write lock in exit_mmap") here, that's when protection was added.
> IIUC, the binder patches are backported to 5.15 kernel and they expect
> mmap_lock to be held during remove_vma() operation in exit_mmap().
Correct!
> However in 5.15 kernel that assumption is incorrect. In that case IMHO
> the backport needs to drop that invalid expectation.
Does this mean that users of async calls such as find_vma() can't rely
on mmap_lock to avoid racing with remove_vma()? I see the following
pattern is used quite often:
mmap_read_lock(mm);
vma = find_vma(mm, addr);
[...]
mmap_read_unlock(mm);
Is this not a real concern? I'd drop the asserts from binder and call it
a day. However, we would also need to fix our race with vm_ops->close().
