linux-kernel - Re: [PATCH 1/3] mmap: Fix vma_iterator in error path of vma

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230928170609.uyugdslacbvaw5kc@revolver>
Date:   Thu, 28 Sep 2023 13:06:09 -0400
From:   "Liam R. Howlett" <Liam.Howlett@...cle.com>
To:     Andrew Morton <akpm@...ux-foundation.org>,
        maple-tree@...ts.infradead.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, Jann Horn <jannh@...gle.com>,
        Lorenzo Stoakes <lstoakes@...il.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Suren Baghdasaryan <surenb@...gle.com>,
        Matthew Wilcox <willy@...radead.org>, stable@...r.kernel.org
Subject: Re: [PATCH 1/3] mmap: Fix vma_iterator in error path of vma_merge()

* Liam R. Howlett <Liam.Howlett@...cle.com> [230927 13:26]:
> * Andrew Morton <akpm@...ux-foundation.org> [230927 13:14]:
> > On Wed, 27 Sep 2023 12:07:44 -0400 "Liam R. Howlett" <Liam.Howlett@...cle.com> wrote:
> > 
> > > When merging of the previous VMA fails after the vma iterator has been
> > > moved to the previous entry, the vma iterator must be advanced to ensure
> > > the caller takes the correct action on the next vma iterator event.  Fix
> > > this by adding a vma_next() call to the error path.
> > > 
> > > Users may experience higher CPU usage, most likely in very low memory
> > > situations.
> > 
> > Looking through this thread:
> > 
> > > Closes: https://lore.kernel.org/linux-mm/CAG48ez12VN1JAOtTNMY+Y2YnsU45yL5giS-Qn=ejtiHpgJAbdQ@mail.gmail.com/
> > 
> > I'm seeing no indication that the effect is CPU consumption?  Jann is
> > excpecting bogus oom-killing?
> 
> His testing injected a bogus oom, but since the vma iterator may get
> stuck in a "I can merge! oh, I'm out of memory" loop due to the
> vma_merge() called with the same VMA in this loop, I would expect it to
> be increased CPU usage when almost out of memory until a task is killed.
> I don't think he expected a bogus OOM since we are using GFP_KERNEL
> during mm/internal.h:vma_iter_prealloc() calls.

The initial call to vma_merge() is correct, but on the second call vma
is the same as prev so it won't attempt to merge prev again.  I think it
would only cause one extra call to vma_merge().

So I think you are correct, CPU usage will not increase very much.
But, there also will not be a bogus OOM.  There will just be two calls to
vma_merge() for the same VMA when there is an OOM even and we could have
merged prev.

I doubt the user would notice anything and they have bigger memory
issues at that time.