Re: [PATCH 6.15] mm/vma: add give_up_on_oom option on modify/merge, use in uffd release

[Andrew Morton <akpm@linux-foundation.org>]

On Fri, 21 Mar 2025 10:09:37 +0000 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:

> Currently, if a VMA merge fails due to an OOM condition arising on commit
> merge or a failure to duplicate anon_vma's, we report this so the caller
> can handle it.
> 
> However there are cases where the caller is only ostensibly trying a
> merge, and doesn't mind if it fails due to this condition.
> 
> Since we do not want to introduce an implicit assumption that we only
> actually modify VMAs after OOM conditions might arise, add a 'give up on
> oom' option and make an explicit contract that, should this flag be set, we
> absolutely will not modify any VMAs should OOM arise and just bail out.
> 
> Since it'd be very unusual for a user to try to vma_modify() with this flag
> set but be specifying a range within a VMA which ends up being split (which
> can fail due to rlimit issues, not only OOM), we add a debug warning for
> this condition.
> 
> The motivating reason for this is uffd release - syzkaller (and Pedro
> Falcato's VERY astute analysis) found a way in which an injected fault on
> allocation, triggering an OOM condition on commit merge, would result in
> uffd code becoming confused and treating an error value as if it were a VMA
> pointer.
> 
> To avoid this, we make use of this new VMG flag to ensure that this never
> occurs, utilising the fact that, should we be clearing entire VMAs, we do
> not wish an OOM event to be reported to us.
> 
> Many thanks to Pedro Falcato for his excellent analysis and Jann Horn for
> his insightful and intelligent analysis of the situation, both of whom were
> instrumental in this fix.
> 
> Reported-by: syzbot+20ed41006cf9d842c2b5@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/67dc67f0.050a0220.25ae54.001e.GAE@google.com/
> Fixes: 47b16d0462a4 ("mm: abort vma_modify() on merge out of memory failure")

I've added a cc:stable to this.