linux-kernel - Re: [PATCH v9 67/69] mm: remove the vma linked list

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, 13 May 2022 14:17:21 +0000
From:   Liam Howlett <liam.howlett@...cle.com>
To:     Qian Cai <quic_qiancai@...cinc.com>
CC:     "maple-tree@...ts.infradead.org" <maple-tree@...ts.infradead.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v9 67/69] mm: remove the vma linked list

* Qian Cai <quic_qiancai@...cinc.com> [220513 09:30]:
> On Wed, May 04, 2022 at 01:14:07AM +0000, Liam Howlett wrote:
> ...
> > @@ -2488,13 +2380,20 @@ do_mas_align_munmap(struct ma_state *mas, struct vm_area_struct *vma,
> >  		    struct mm_struct *mm, unsigned long start,
> >  		    unsigned long end, struct list_head *uf, bool downgrade)
> >  {
> > -	struct vm_area_struct *prev, *last;
> > +	struct vm_area_struct *prev, *next = NULL;
> > +	struct maple_tree mt_detach;
> > +	int count = 0;
> >  	int error = -ENOMEM;
> > -	/* we have start < vma->vm_end  */
> > +	MA_STATE(mas_detach, &mt_detach, start, end - 1);
> > +	mt_init_flags(&mt_detach, MM_MT_FLAGS);
> > +	mt_set_external_lock(&mt_detach, &mm->mmap_lock);
> >  
> >  	if (mas_preallocate(mas, vma, GFP_KERNEL))
> >  		return -ENOMEM;
> >  
> > +	if (mas_preallocate(&mas_detach, vma, GFP_KERNEL))
> 
> This guy was reported as leaks as well.
> 
> unreferenced object 0xffff0802d49b5500 (size 256):
>   comm "trinity-c22", pid 107245, jiffies 4295674711 (age 816.980s)
>   hex dump (first 32 bytes):
>     01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>   backtrace:
>      kmem_cache_alloc
>      mas_alloc_nodes
>      mas_preallocate
>      do_mas_align_munmap.constprop.0
>      do_mas_align_munmap at mm/mmap.c:2384
>      do_mas_munmap
>      __vm_munmap
>      __arm64_sys_munmap
>      invoke_syscall
>      el0_svc_common.constprop.0
>      do_el0_svc
>      el0_svc
>      el0t_64_sync_handler
>      el0t_64_sync


Thanks.  I have not seen this myself but there certainly is a potential
for a leak here when the task runs out of memory in the middle of a
munmap operation.  I've sent you and Andrew a fix.

Cheers,
Liam