linux-kernel - Re: Observed memory leak in hugetlb_reserve

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: <Y029wEbf5/AwxGPy@monkey>
Date:   Mon, 17 Oct 2022 13:40:32 -0700
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     Lukas Bulwahn <lukas.bulwahn@...il.com>
Cc:     Muchun Song <songmuchun@...edance.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux-MM <linux-mm@...ck.org>,
        kernel-janitors <kernel-janitors@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Observed memory leak in hugetlb_reserve_pages

On 10/17/22 10:38, Mike Kravetz wrote:
> On 10/17/22 13:11, Lukas Bulwahn wrote:
> > Dear Mike,
> > 
> > The reproducer for the 'memory leak in hugetlb_reserve_pages' bug (see
> > https://elisa-builder-00.iol.unh.edu/syzkaller-next/report?id=3469603f4a0da86b581cc979bd6c6663b46ceb1b)
> > is reproducible, it is triggering the memory leak on the current
> > mainline (commit 60bb8154d1d7), and it was not triggering on v6.0. My
> > build config is a x86_64 defconfig with some syzkaller-recommended
> > debug options.
> 
> Thank you Lukas!
> 
> The leak is embarrassingly obvious.  Here is a bit of code at the beginning of
> hugetlb_reserve_pages:
> 
> 	/*
> 	 * vma specific semaphore used for pmd sharing synchronization
> 	 */
> 	hugetlb_vma_lock_alloc(vma);
> 
> 	/*
> 	 * Only apply hugepage reservation if asked. At fault time, an
> 	 * attempt will be made for VM_NORESERVE to allocate a page
> 	 * without using reserves
> 	 */
> 	if (vm_flags & VM_NORESERVE)
> 		return true;
> 
> There needs to be a hugetlb_vma_lock_free(vma) call before that return.
> 
> I will do some testing and send a patch.  However, I will use commit
> 8d9bfb2608145 in the Fixes: tag.  This is because that commit added the
> call to hugetlb_vma_lock_alloc in hugetlb_reserve_pages without the
> hugetlb_vma_lock_free in the VM_NORESERVE return.
> 
> > My git bisection showed that the first bad commit is
> > [bbff39cc6cbcb86ccfacb2dcafc79912a9f9df69] hugetlb: allocate vma lock
> > for all sharable vmas.
> 
> The reason your bisect pointed to bbff39cc6cbc is because the mmap/vma size in
> the test case is not sufficient for pmd sharing.  Therefore, the test did not
> experience a leak until the patch which allocates the vma lock for ALL vmas
> was added.

Please ignore this email.  I sent it before looking (or thinking) closely.

-- 
Mike Kravetz