linux-kernel - Re: Linux-next: crash in alloc_huge

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: <8379f7d5-5d89-ac37-be83-aaa185dd6c3c@quicinc.com>
Date:   Wed, 11 Aug 2021 10:25:15 -0400
From:   Qian Cai <quic_qiancai@...cinc.com>
To:     Mike Rapoport <rppt@...ux.ibm.com>,
        Matthew Wilcox <willy@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>
CC:     David Hildenbrand <david@...hat.com>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Linux Memory Management List <linux-mm@...ck.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux-next: crash in alloc_huge_page()



On 8/11/2021 10:11 AM, Mike Rapoport wrote:
> On Wed, Aug 11, 2021 at 04:06:18AM +0100, Matthew Wilcox wrote:
>> On Tue, Aug 10, 2021 at 10:22:37PM -0400, Qian Cai wrote:
>>> and the page->lru has an address fffffffffffffffc for some reasons. Does it sound like some error code
>>> had not been handled properly and had been propagated here instead? I tried reverting a few recent
>>> commits for mm/hugetlb.c and mm/memblock.c without luck so far.
>>
>> Yes, ff..fc is going to be at offset 8 from the actual address, so
>> that's -12 and -12 is ...
>>
>> #define ENOMEM          12      /* Out of memory */
>>
>> so something's returning ERR_PTR(-ENOMEM) instead of NULL.
> 
> page is not initialized in alloc_buddy_huge_page_with_mpol() and after
> commit 2cfa8b23744f ("mm-hugetlb-add-support-for-mempolicy-mpol_preferred_many-fix") we have 

Good catch, Mike! Pretty sure I missed to test that commit thought that was an old commit along
with the rest of the mpol_preferred series.

It is a dream that one day mm tree could like other subsystem trees where "git tag --contains"
would work to indicate which linux-next tags contains a particular commit to tell the timeline
of it. Right now, we have those commits ID always changed and commit date is meaningless for
mm commits in linux-next.

> 
> 	struct page *page;
> 
> 	...
> 
> 	if (mpol_is_preferred_many(mpol)) {
> 		gfp_t gfp = gfp_mask | __GFP_NOWARN;
> 
> 		gfp &=  ~(__GFP_DIRECT_RECLAIM | __GFP_NOFAIL);
> 		page = alloc_surplus_huge_page(h, gfp, nid, nodemask, false);
> 
> 		/* Fallback to all nodes if page==NULL */
> 		nodemask = NULL;
> 	}
> 
> 	if (!page)
> 		page = alloc_surplus_huge_page(h, gfp_mask, nid, nodemask, false
> 
> 	mpol_cond_put(mpol);
> 	return page;
> 
> so for !mpol_is_preferred_many() we return an uninitialized variable.
> 
> This should fix it:
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 008662083fec..6337697f7ee4 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -2152,7 +2152,7 @@ static
>  struct page *alloc_buddy_huge_page_with_mpol(struct hstate *h,
>  		struct vm_area_struct *vma, unsigned long addr)
>  {
> -	struct page *page;
> +	struct page *page = NULL;
>  	struct mempolicy *mpol;
>  	gfp_t gfp_mask = htlb_alloc_mask(h);
>  	int nid;
>  
>