Re: [PATCH v2 3/5] binder: check vma->vm_start in binder_vma_close()

[Carlos Llamas]

On Tue, Sep 01, 2026 at 09:31:27AM +0000, Alice Ryhl wrote:
> On Tue, Sep 01, 2026 at 03:04:14AM +0000, Carlos Llamas wrote:
> > Certain operations like a failed mremap() might trigger vm_ops->close()
> > on temporary mappings. To avoid tearing-down the main binder mapping on
> > these, let's verify that the VMA matches the expected starting address.
> > 
> > Cc: stable@xxxxxxxxxxxxxxx
> > Fixes: 457b9a6f09f0 ("Staging: android: add binder driver")
> > Reported-by: Sashiko <sashiko-bot@xxxxxxxxxx>
> > Closes: https://sashiko.dev/#/patchset/20260831224145.169403-1-cmllamas%40google.com?part=1
> > Signed-off-by: Carlos Llamas <cmllamas@xxxxxxxxxx>
> 
> I don't quite understand this. You explicitly made sure mremap() can't
> happen to begin with, so when is this called?

The issue is mremap() first clones the old vma and then calls ->mremap()
but we return -EINVAL. So it now starts to tear-down the cloned vma and
it calls ->close() as part of it.

The idea was to avoid shutting down our IPC when this happens.

However, sashiko pointed out a second issue with a tail split. I need to
expand this check to allow the ->close() on anything within the range of
the original VMA.

I'll have to send a v3.