From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8149FC28CBC for ; Wed, 6 May 2020 16:57:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 304E2208CA for ; Wed, 6 May 2020 16:57:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 304E2208CA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B97C08E0005; Wed, 6 May 2020 12:57:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B48888E0003; Wed, 6 May 2020 12:57:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A84CC8E0005; Wed, 6 May 2020 12:57:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0056.hostedemail.com [216.40.44.56]) by kanga.kvack.org (Postfix) with ESMTP id 91A788E0003 for ; Wed, 6 May 2020 12:57:48 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 4CD3DAC00 for ; Wed, 6 May 2020 16:57:48 +0000 (UTC) X-FDA: 76786901016.10.cake66_270235e0e724c X-HE-Tag: cake66_270235e0e724c X-Filterd-Recvd-Size: 3780 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Wed, 6 May 2020 16:57:47 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 47EF8ABCE; Wed, 6 May 2020 16:57:49 +0000 (UTC) Subject: Re: Potential null pointer dereference in remap_vmalloc_range_partial() To: Dongyang Zhan , linux-mm@kvack.org References: From: Vlastimil Babka Message-ID: Date: Wed, 6 May 2020 18:57:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 5/3/20 8:03 AM, Dongyang Zhan wrote: > Hi, > > I am a security researcher. I found a potential bug in /mm/sparse.c. I hope you can help me to confirm it. > > In Linux 4.10.17, In general, the upstream community prioritises recent kernels, 4.10 is rather old. Bugs from older kernels should be verified if they still apply to most recent version. If they don't, it's a matter of identifying the fixing commit and sending it to stable. > remap_vmalloc_range_partial() in /mm/vmalloc.c does not check the validation of allocated memory 'page', which may cause a null pointer dereference bug. > > int remap_vmalloc_range_partial(struct vm_area_struct *vma, unsigned long uaddr, > void *kaddr, unsigned long size) > { > ... > struct page *page = vmalloc_to_page(kaddr); //page is possible to be null > int ret; > > ret = vm_insert_page(vma, uaddr, page); //null pointer dereference of page > if (ret) > return ret; > ... > } > Let us see vmalloc_to_page(kaddr) in /mm/vmalloc.c > struct page *vmalloc_to_page(const void *vmalloc_addr) > { > unsigned long addr = (unsigned long) vmalloc_addr; > struct page *page = NULL; > pgd_t *pgd = pgd_offset_k(addr); > > /* > * XXX we might need to change this if we add VIRTUAL_BUG_ON for > * architectures that do not vmalloc module space > */ > VIRTUAL_BUG_ON(!is_vmalloc_or_module_addr(vmalloc_addr)); > > if (!pgd_none(*pgd)) { > ... > } > return page; > } > We can find that page is possible to be NULL. Current version of vmalloc_to_page() is even more explicit: if (pgd_none(*pgd)) return NULL; > Then, we can see this function vm_insert_page(vma, uaddr, page) in /mm/memory.c. > int vm_insert_page(struct vm_area_struct *vma, unsigned long addr, > struct page *page) > { > if (addr < vma->vm_start || addr >= vma->vm_end) > return -EFAULT; > if (!page_count(page)) //this function can trigger the bug. > return -EINVAL; > ... > } > page_count() can be found in /include/linux/page_ref.h. > static inline int page_count(struct page *page) > { > return atomic_read(&compound_head(page)->_refcount); > } > Directly using the 'page' pointer is not secure. This all assumes remap_vmalloc_range_partial() was called with kaddr that doesn't have the page table hierarchy populated. You say 'validation of allocated memory 'page'' but page is not being allocated, it's looked up from page tables. If it was valid vmalloc region, the page tables should be populated and there's no NULL. To show a bug, you would need to show how remap_vmalloc_range_partial() can be called with kaddr that's not a proper vmalloc allocation. HTH, Vlastimil