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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20250406154350.c548ca25ef60b41fc86d5942@linux-foundation.org>
Date: Sun, 6 Apr 2025 15:43:50 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Vlastimil Babka <vbabka@...e.cz>, Jann Horn <jannh@...gle.com>,
 "Liam R . Howlett" <Liam.Howlett@...cle.com>, Pedro Falcato
 <pfalcato@...e.de>, linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6.15] mm/vma: add give_up_on_oom option on modify/merge,
 use in uffd release

On Fri, 21 Mar 2025 10:09:37 +0000 Lorenzo Stoakes <lorenzo.stoakes@...cle.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@...kaller.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.