Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2039562imm; Mon, 16 Jul 2018 00:40:34 -0700 (PDT) X-Google-Smtp-Source: AAOMgpd6Es3Y5uSGhDTw43xNwDBD8EUwAVvWe3X+NpE0YthW9pOXYNV1Cg/b46cdZ1jzWdoGWzAe X-Received: by 2002:a63:9311:: with SMTP id b17-v6mr14568679pge.261.1531726834241; Mon, 16 Jul 2018 00:40:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531726834; cv=none; d=google.com; s=arc-20160816; b=ft5t0iNL9nL9XcfVWWNytALa6kROPCmLtCYVYHFUWsJ4EeBnTnCDSe4pU/PS7dj7sp xvKxKP9JY0K5uX7qaI2dq8ReDsIUG3hpbtgRJg4H/mpiMBsklVSk9s7ptK6zLeG0C6pw X/YN+gRSzvdSywa3oWv+BTpNnArBFfg7q4gsZjTbB1l5QKTD1F6d3zC+r55Kp5xaJGd0 xXv4jEbWmXipF+maZ3WUAYfQOQzoaG0CNp2mGDt4iMqr3OVlhepOzvzx+JdIgij6FAs4 vBYjUPb4Kj8JXWro214PWJzWTAEhrUnfeylIxlOaxRPWNk/C7TKgQF0VbDc0gb0PpDNE c+nA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=sqsMcZtrSzctoOpteGWH7mEX7L3mZTvuKVeufJwCJ9s=; b=GjcTpl/WhqO7Zg5sxnCzJ1/Me/W5Gwyqwto24sfw/rEXEYVljcwfJ0Di9eStYYULMp 8aJfk/9sXYV2h3MMd3sBiZ5DxardDm8C3e3fcgTPQlKlblHATCPPKYgRUN2tRMkEirX6 Ex47DslI5aSBHsU1GXVP0UX8YplakMxrBtNql4QJdbMFsb7kRjsAKLcMGZb5x70lhZT5 MFdXdciZwwKW9ONA4MvwWbGgv+0JQxxBpPicc1lag2bUr3p6RkLOrZsuhDDouH/uoYuU zspxNvAUs70scDofC+Kzhvvxclmq9sFUD0DY06iWFc7d/JVyaDgAkUaF8Kn7rO9Y+1Jr yoAw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j10-v6si29549920plg.396.2018.07.16.00.40.19; Mon, 16 Jul 2018 00:40:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732054AbeGPID6 (ORCPT + 99 others); Mon, 16 Jul 2018 04:03:58 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:46802 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728460AbeGPID6 (ORCPT ); Mon, 16 Jul 2018 04:03:58 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id AB092C03; Mon, 16 Jul 2018 07:37:56 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Michal Hocko , syzbot , Tetsuo Handa , Oscar Salvador , Zi Yan , "Aneesh Kumar K.V" , Dan Williams , "Kirill A. Shutemov" , "Michael S. Tsirkin" , Al Viro , "Huang, Ying" , Andrew Morton , Linus Torvalds Subject: [PATCH 4.17 39/67] mm: do not bug_on on incorrect length in __mm_populate() Date: Mon, 16 Jul 2018 09:35:08 +0200 Message-Id: <20180716073449.337211671@linuxfoundation.org> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20180716073443.294323458@linuxfoundation.org> References: <20180716073443.294323458@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.17-stable review patch. If anyone has any objections, please let me know. ------------------ From: Michal Hocko commit bb177a732c4369bb58a1fe1df8f552b6f0f7db5f upstream. syzbot has noticed that a specially crafted library can easily hit VM_BUG_ON in __mm_populate kernel BUG at mm/gup.c:1242! invalid opcode: 0000 [#1] SMP CPU: 2 PID: 9667 Comm: a.out Not tainted 4.18.0-rc3 #644 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017 RIP: 0010:__mm_populate+0x1e2/0x1f0 Code: 55 d0 65 48 33 14 25 28 00 00 00 89 d8 75 21 48 83 c4 20 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 75 18 f1 ff 0f 0b e8 6e 18 f1 ff <0f> 0b 31 db eb c9 e8 93 06 e0 ff 0f 1f 00 55 48 89 e5 53 48 89 fb Call Trace: vm_brk_flags+0xc3/0x100 vm_brk+0x1f/0x30 load_elf_library+0x281/0x2e0 __ia32_sys_uselib+0x170/0x1e0 do_fast_syscall_32+0xca/0x420 entry_SYSENTER_compat+0x70/0x7f The reason is that the length of the new brk is not page aligned when we try to populate the it. There is no reason to bug on that though. do_brk_flags already aligns the length properly so the mapping is expanded as it should. All we need is to tell mm_populate about it. Besides that there is absolutely no reason to to bug_on in the first place. The worst thing that could happen is that the last page wouldn't get populated and that is far from putting system into an inconsistent state. Fix the issue by moving the length sanitization code from do_brk_flags up to vm_brk_flags. The only other caller of do_brk_flags is brk syscall entry and it makes sure to provide the proper length so t here is no need for sanitation and so we can use do_brk_flags without it. Also remove the bogus BUG_ONs. [osalvador@techadventures.net: fix up vm_brk_flags s@request@len@] Link: http://lkml.kernel.org/r/20180706090217.GI32658@dhcp22.suse.cz Signed-off-by: Michal Hocko Reported-by: syzbot Tested-by: Tetsuo Handa Reviewed-by: Oscar Salvador Cc: Zi Yan Cc: "Aneesh Kumar K.V" Cc: Dan Williams Cc: "Kirill A. Shutemov" Cc: Michael S. Tsirkin Cc: Al Viro Cc: "Huang, Ying" Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- mm/gup.c | 2 -- mm/mmap.c | 29 ++++++++++++----------------- 2 files changed, 12 insertions(+), 19 deletions(-) --- a/mm/gup.c +++ b/mm/gup.c @@ -1222,8 +1222,6 @@ int __mm_populate(unsigned long start, u int locked = 0; long ret = 0; - VM_BUG_ON(start & ~PAGE_MASK); - VM_BUG_ON(len != PAGE_ALIGN(len)); end = start + len; for (nstart = start; nstart < end; nstart = nend) { --- a/mm/mmap.c +++ b/mm/mmap.c @@ -186,8 +186,8 @@ static struct vm_area_struct *remove_vma return next; } -static int do_brk(unsigned long addr, unsigned long len, struct list_head *uf); - +static int do_brk_flags(unsigned long addr, unsigned long request, unsigned long flags, + struct list_head *uf); SYSCALL_DEFINE1(brk, unsigned long, brk) { unsigned long retval; @@ -245,7 +245,7 @@ SYSCALL_DEFINE1(brk, unsigned long, brk) goto out; /* Ok, looks good - let it rip. */ - if (do_brk(oldbrk, newbrk-oldbrk, &uf) < 0) + if (do_brk_flags(oldbrk, newbrk-oldbrk, 0, &uf) < 0) goto out; set_brk: @@ -2929,21 +2929,14 @@ static inline void verify_mm_writelocked * anonymous maps. eventually we may be able to do some * brk-specific accounting here. */ -static int do_brk_flags(unsigned long addr, unsigned long request, unsigned long flags, struct list_head *uf) +static int do_brk_flags(unsigned long addr, unsigned long len, unsigned long flags, struct list_head *uf) { struct mm_struct *mm = current->mm; struct vm_area_struct *vma, *prev; - unsigned long len; struct rb_node **rb_link, *rb_parent; pgoff_t pgoff = addr >> PAGE_SHIFT; int error; - len = PAGE_ALIGN(request); - if (len < request) - return -ENOMEM; - if (!len) - return 0; - /* Until we need other flags, refuse anything except VM_EXEC. */ if ((flags & (~VM_EXEC)) != 0) return -EINVAL; @@ -3015,18 +3008,20 @@ out: return 0; } -static int do_brk(unsigned long addr, unsigned long len, struct list_head *uf) -{ - return do_brk_flags(addr, len, 0, uf); -} - -int vm_brk_flags(unsigned long addr, unsigned long len, unsigned long flags) +int vm_brk_flags(unsigned long addr, unsigned long request, unsigned long flags) { struct mm_struct *mm = current->mm; + unsigned long len; int ret; bool populate; LIST_HEAD(uf); + len = PAGE_ALIGN(request); + if (len < request) + return -ENOMEM; + if (!len) + return 0; + if (down_write_killable(&mm->mmap_sem)) return -EINTR;