linux-kernel - Re: [PATCH v3 2/3] mmap: Fix error paths with dup_anon

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: <20231003144526.upn62oqknscpwci2@revolver>
Date:   Tue, 3 Oct 2023 10:45:26 -0400
From:   "Liam R. Howlett" <Liam.Howlett@...cle.com>
To:     Lorenzo Stoakes <lstoakes@...il.com>
Cc:     Vlastimil Babka <vbabka@...e.cz>,
        Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, Jann Horn <jannh@...gle.com>,
        Suren Baghdasaryan <surenb@...gle.com>,
        Matthew Wilcox <willy@...radead.org>, stable@...r.kernel.org
Subject: Re: [PATCH v3 2/3] mmap: Fix error paths with dup_anon_vma()

* Lorenzo Stoakes <lstoakes@...il.com> [231002 03:43]:
> On Mon, Oct 02, 2023 at 09:26:03AM +0200, Vlastimil Babka wrote:
> > On 9/30/23 00:28, Lorenzo Stoakes wrote:
> > > On Fri, Sep 29, 2023 at 02:30:40PM -0400, Liam R. Howlett wrote:
> > >> When the calling function fails after the dup_anon_vma(), the
> > >> duplication of the anon_vma is not being undone.  Add the necessary
> > >> unlink_anon_vma() call to the error paths that are missing them.
> > >>
> > >> This issue showed up during inspection of the error path in vma_merge()
> > >> for an unrelated vma iterator issue.
> > >>
> > >> Users may experience increased memory usage, which may be problematic as
> > >> the failure would likely be caused by a low memory situation.
> > >>
> > >> Fixes: d4af56c5c7c6 ("mm: start tracking VMAs with maple tree")
> > >> Cc: stable@...r.kernel.org
> > >> Cc: Jann Horn <jannh@...gle.com>
> > >> Signed-off-by: Liam R. Howlett <Liam.Howlett@...cle.com>
> > >> ---
> > >>  mm/mmap.c | 30 ++++++++++++++++++++++--------
> > >>  1 file changed, 22 insertions(+), 8 deletions(-)
> > >>
> > >> diff --git a/mm/mmap.c b/mm/mmap.c
> > >> index acb7dea49e23..f9f0a5fe4db4 100644
> > >> --- a/mm/mmap.c
> > >> +++ b/mm/mmap.c
> > >> @@ -583,11 +583,12 @@ static inline void vma_complete(struct vma_prepare *vp,
> > >>   * dup_anon_vma() - Helper function to duplicate anon_vma
> > >>   * @dst: The destination VMA
> > >>   * @src: The source VMA
> > >> + * @dup: Pointer to the destination VMA when successful.
> > >>   *
> > >>   * Returns: 0 on success.
> > >
> > > Being a bit nitpicky/refactory here, but anon_vma_clone() appears to have
> > > two possible return values - 0 for success, and -ENOMEM.
> > >
> > > As a result, it's not really gaining us much passing through this value.

Passing through the pointer simplifies the success code path, in most
cases.. for these callers though, it doesn't appear to matter.

> > >
> > > It'd be nice if dup_anon_vma() and anon_vma_clone() were therefore updated
> > > to instead return NULL on ENOMEM and the dst otherwise.
> >
> > But we also need to represent that dup_anon_vma() had nothing to do, because
> > "(src->anon_vma && !dst->anon_vma)" was false, and in that case we should
> > not be returning dst from there?
> >
> > So maybe we could return NULL for that case and ERR_PTR(ret) for the -ENOMEM
> > from anon_vma_clone() ?
> 
> Yeah, you're right, actually I think that would probably be the best
> approach as you'd both eliminate the awkward out parameter but retain the
> fact that there's 3 possible return states (dup'd, no need to dup, error).

I don't like 3 possible returns as it makes things less readable, IMO.
But, since the two callers to the function don't use the assigned
variable again it won't make things too bad here.  We can document it by
using the variable name.  eg: anon_duped = dup_anon_vma() instead of
err = dup_anon_vma().

> 
> >
> > > Then we could de-clunk this whole code path, and the quite natural fact of
> > > 'thing didn't return a pointer therefore had no memory to allocate it' fals
> > > out.
> > >
> > > But this isn't exactly an earth-shattering concern :)
> > >
> >