linux-kernel - Re: maple tree change made it possible for VMA iteration to see same VMA twice due to late 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]

Date:   Fri, 22 Sep 2023 13:52:32 -0400
From:   "Liam R. Howlett" <Liam.Howlett@...cle.com>
To:     Jann Horn <jannh@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        kernel list <linux-kernel@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>,
        Lorenzo Stoakes <lstoakes@...il.com>,
        Vlastimil Babka <vbabka@...e.cz>
Subject: Re: maple tree change made it possible for VMA iteration to see same
 VMA twice due to late vma_merge() failure

...
> 
> Looking at this, I think it's best to make a label and undo the
> vma_prev() with a vma_next() - at least for now.
> 
> I'm also reading this for the error path on dup_anon_vma() failure, and
> it appears to also have an issue which I'd like to point out here before
> I send the fix for the first issue.
> 
> -----------
>                 vma_start_write(next);                                                                                  
>                 remove = next;                          /* case 1 */                                                    
>                 vma_end = next->vm_end;                                                                                 
>                 err = dup_anon_vma(prev, next);                                                                         
>                 if (curr) {                             /* case 6 */                                                    
>                         vma_start_write(curr);                                                                          
>                         remove = curr;                                                                                  
>                         remove2 = next;                                                                                 
>                         if (!next->anon_vma)                                                                            
>                                 err = dup_anon_vma(prev, curr);  
> -----------
> 
> Since dup_anon_vma() can fail, I think here in case 6 we could overwrite
> the failure.
> 
> That is, we will fail to clone the anon vma and mask the failure if we
> are running case 6 with an anon in next.  Once the first dup_anon_vma()
> returns error, the next call to clone curr vma may return 0 if there is
> no anon vma (this, I think _must_ be the case). Then we are in a
> situation where we will be removing next and expanding prev over curr
> and next, but have not dup'ed the anon vma from next.
> 

I think I am incorrect in the error being overwritten because we won't
call dup_anon_vma(prev, curr) if the source of the previous call (next)
has an anon vma.

Thanks,
Liam