From patchwork Fri Sep 4 23:35:30 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 310116 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=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 34EB1C2D0A8 for ; Fri, 4 Sep 2020 23:35:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 02BA82100A for ; Fri, 4 Sep 2020 23:35:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599262534; bh=ImmSXwO0sJ2R2+sPRnb0B1ILO2z0q4evWpw/pElgZ0I=; h=Date:From:To:Subject:In-Reply-To:List-ID:From; b=kp3KPU4yZ+IV0bfut3tm2C42O4WcUGhteKBH0l5FLz3ncjk0ZFOmEZorE39y5ognM hi6vEyG/VfW2UmVgM5VNxKnxKs8D5wU8HMQGBLyKZIff6NU1pMLQnqP2isBtrMtVPG /VmKD9e0KKyyJ3QrXXcstMM7AyWCX07ybfxQFrBg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726770AbgIDXfd (ORCPT ); Fri, 4 Sep 2020 19:35:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:38462 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726456AbgIDXfb (ORCPT ); Fri, 4 Sep 2020 19:35:31 -0400 Received: from localhost.localdomain (c-71-198-47-131.hsd1.ca.comcast.net [71.198.47.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C9F8620FC3; Fri, 4 Sep 2020 23:35:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599262531; bh=ImmSXwO0sJ2R2+sPRnb0B1ILO2z0q4evWpw/pElgZ0I=; h=Date:From:To:Subject:In-Reply-To:From; b=I8QicgUy0fedNWi7qQHYjuYF7rvQn+a6MQCdCobc2OCUa5FIqDNxxOFQSO9M7WBEo 91UOJQXtzmCLYUPF86DXq/dEWvYbYyZ5nt0aqc0kBLtYHl6+BPzesAGfrm+PxpCsit cBZax/HrUEFHB5RAWdJlds7mZv/8lvRIZo0szeJ8= Date: Fri, 04 Sep 2020 16:35:30 -0700 From: Andrew Morton To: akpm@linux-foundation.org, cl@linux.com, dongli.zhang@oracle.com, erosca@de.adit-jv.com, iamjoonsoo.kim@lge.com, joe.jin@oracle.com, linux-mm@kvack.org, mm-commits@vger.kernel.org, penberg@kernel.org, rientjes@google.com, stable@vger.kernel.org, torvalds@linux-foundation.org Subject: [patch 03/19] mm: slub: fix conversion of freelist_corrupted() Message-ID: <20200904233530.zhlwFqhIl%akpm@linux-foundation.org> In-Reply-To: <20200904163454.4db0e6ce0c4584d2653678a3@linux-foundation.org> User-Agent: s-nail v14.8.16 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Eugeniu Rosca Subject: mm: slub: fix conversion of freelist_corrupted() Commit 52f23478081ae0 ("mm/slub.c: fix corrupted freechain in deactivate_slab()") suffered an update when picked up from LKML [1]. Specifically, relocating 'freelist = NULL' into 'freelist_corrupted()' created a no-op statement. Fix it by sticking to the behavior intended in the original patch [1]. In addition, make freelist_corrupted() immune to passing NULL instead of &freelist. The issue has been spotted via static analysis and code review. [1] https://lore.kernel.org/linux-mm/20200331031450.12182-1-dongli.zhang@oracle.com/ Link: https://lkml.kernel.org/r/20200824130643.10291-1-erosca@de.adit-jv.com Fixes: 52f23478081ae0 ("mm/slub.c: fix corrupted freechain in deactivate_slab()") Signed-off-by: Eugeniu Rosca Cc: Dongli Zhang Cc: Joe Jin Cc: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Cc: Signed-off-by: Andrew Morton --- mm/slub.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) --- a/mm/slub.c~mm-slub-fix-conversion-of-freelist_corrupted +++ a/mm/slub.c @@ -672,12 +672,12 @@ static void slab_fix(struct kmem_cache * } static bool freelist_corrupted(struct kmem_cache *s, struct page *page, - void *freelist, void *nextfree) + void **freelist, void *nextfree) { if ((s->flags & SLAB_CONSISTENCY_CHECKS) && - !check_valid_pointer(s, page, nextfree)) { - object_err(s, page, freelist, "Freechain corrupt"); - freelist = NULL; + !check_valid_pointer(s, page, nextfree) && freelist) { + object_err(s, page, *freelist, "Freechain corrupt"); + *freelist = NULL; slab_fix(s, "Isolate corrupted freechain"); return true; } @@ -1494,7 +1494,7 @@ static inline void dec_slabs_node(struct int objects) {} static bool freelist_corrupted(struct kmem_cache *s, struct page *page, - void *freelist, void *nextfree) + void **freelist, void *nextfree) { return false; } @@ -2184,7 +2184,7 @@ static void deactivate_slab(struct kmem_ * 'freelist' is already corrupted. So isolate all objects * starting at 'freelist'. */ - if (freelist_corrupted(s, page, freelist, nextfree)) + if (freelist_corrupted(s, page, &freelist, nextfree)) break; do { From patchwork Fri Sep 4 23:35:43 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 264372 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=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 8C1A5C2BB84 for ; Fri, 4 Sep 2020 23:35:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 54F9520C56 for ; Fri, 4 Sep 2020 23:35:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599262546; bh=9k5iDITcfjD2lAeZWwAaaYZqPQFNqH44P9wcYIv0sd8=; h=Date:From:To:Subject:In-Reply-To:List-ID:From; b=KqG2BWrp+JWvmPtTUkgmnszuiCWfoQBfYDmurVLM1V4R4+4iyOlf1FdKgV4fD8pFx wwfhLD8p9ePnlrbp+Qv1+rVgE8g/Y7U24sEcDlvUiDVQOeavOly2xuzadYY25FLyiR Eqb8yimL5V6Hi4tgoLwPXxNN6jkmHHorssnIlNCU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727860AbgIDXfp (ORCPT ); Fri, 4 Sep 2020 19:35:45 -0400 Received: from mail.kernel.org ([198.145.29.99]:38700 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726456AbgIDXfo (ORCPT ); Fri, 4 Sep 2020 19:35:44 -0400 Received: from localhost.localdomain (c-71-198-47-131.hsd1.ca.comcast.net [71.198.47.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 91812208C7; Fri, 4 Sep 2020 23:35:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599262543; bh=9k5iDITcfjD2lAeZWwAaaYZqPQFNqH44P9wcYIv0sd8=; h=Date:From:To:Subject:In-Reply-To:From; b=KIXlLk3TBaQemxGqqkL48Ymp79aTIjcNZ7wm8GB/24AQZLA2oK/Umro4OtE3rjyuh T2rb7MNzjET7/TxzsHmGA5+ZIue4xX8ulJ3dmFdfUY95mMEQd6lOg9EwLkfHQIL5aO eGxcRi3E2CoeKIFcJGfIoMFVBkC6qmNcpH2WVrl4= Date: Fri, 04 Sep 2020 16:35:43 -0700 From: Andrew Morton To: akpm@linux-foundation.org, chris@chris-wilson.co.uk, jroedel@suse.de, linux-mm@kvack.org, mm-commits@vger.kernel.org, pavel@ucw.cz, sfr@canb.auug.org.au, stable@vger.kernel.org, torvalds@linux-foundation.org Subject: [patch 07/19] mm: track page table modifications in __apply_to_page_range() Message-ID: <20200904233543._QZjc1czy%akpm@linux-foundation.org> In-Reply-To: <20200904163454.4db0e6ce0c4584d2653678a3@linux-foundation.org> User-Agent: s-nail v14.8.16 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Joerg Roedel Subject: mm: track page table modifications in __apply_to_page_range() __apply_to_page_range() is also used to change and/or allocate page-table pages in the vmalloc area of the address space. Make sure these changes get synchronized to other page-tables in the system by calling arch_sync_kernel_mappings() when necessary. The impact appears limited to x86-32, where apply_to_page_range may miss updating the PMD. That leads to explosions in drivers like [ 24.227844] BUG: unable to handle page fault for address: fe036000 [ 24.228076] #PF: supervisor write access in kernel mode [ 24.228294] #PF: error_code(0x0002) - not-present page [ 24.228494] *pde = 00000000 [ 24.228640] Oops: 0002 [#1] SMP [ 24.228788] CPU: 3 PID: 1300 Comm: gem_concurrent_ Not tainted 5.9.0-rc1+ #16 [ 24.228957] Hardware name: /NUC6i3SYB, BIOS SYSKLi35.86A.0024.2015.1027.2142 10/27/2015 [ 24.229297] EIP: __execlists_context_alloc+0x132/0x2d0 [i915] [ 24.229462] Code: 31 d2 89 f0 e8 2f 55 02 00 89 45 e8 3d 00 f0 ff ff 0f 87 11 01 00 00 8b 4d e8 03 4b 30 b8 5a 5a 5a 5a ba 01 00 00 00 8d 79 04 01 5a 5a 5a 5a c7 81 fc 0f 00 00 5a 5a 5a 5a 83 e7 fc 29 f9 81 [ 24.229759] EAX: 5a5a5a5a EBX: f60ca000 ECX: fe036000 EDX: 00000001 [ 24.229915] ESI: f43b7340 EDI: fe036004 EBP: f6389cb8 ESP: f6389c9c [ 24.230072] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010286 [ 24.230229] CR0: 80050033 CR2: fe036000 CR3: 2d361000 CR4: 001506d0 [ 24.230385] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [ 24.230539] DR6: fffe0ff0 DR7: 00000400 [ 24.230675] Call Trace: [ 24.230957] execlists_context_alloc+0x10/0x20 [i915] [ 24.231266] intel_context_alloc_state+0x3f/0x70 [i915] [ 24.231547] __intel_context_do_pin+0x117/0x170 [i915] [ 24.231850] i915_gem_do_execbuffer+0xcc7/0x2500 [i915] [ 24.232024] ? __kmalloc_track_caller+0x54/0x230 [ 24.232181] ? ktime_get+0x3e/0x120 [ 24.232333] ? dma_fence_signal+0x34/0x50 [ 24.232617] i915_gem_execbuffer2_ioctl+0xcd/0x1f0 [i915] [ 24.232912] ? i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915] [ 24.233084] drm_ioctl_kernel+0x8f/0xd0 [ 24.233236] drm_ioctl+0x223/0x3d0 [ 24.233505] ? i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915] [ 24.233684] ? pick_next_task_fair+0x1b5/0x3d0 [ 24.233873] ? __switch_to_asm+0x36/0x50 [ 24.234021] ? drm_ioctl_kernel+0xd0/0xd0 [ 24.234167] __ia32_sys_ioctl+0x1ab/0x760 [ 24.234313] ? exit_to_user_mode_prepare+0xe5/0x110 [ 24.234453] ? syscall_exit_to_user_mode+0x23/0x130 [ 24.234601] __do_fast_syscall_32+0x3f/0x70 [ 24.234744] do_fast_syscall_32+0x29/0x60 [ 24.234885] do_SYSENTER_32+0x15/0x20 [ 24.235021] entry_SYSENTER_32+0x9f/0xf2 [ 24.235157] EIP: 0xb7f28559 [ 24.235288] Code: 03 74 c0 01 10 05 03 74 b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76 [ 24.235576] EAX: ffffffda EBX: 00000005 ECX: c0406469 EDX: bf95556c [ 24.235722] ESI: b7e68000 EDI: c0406469 EBP: 00000005 ESP: bf9554d8 [ 24.235869] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000296 [ 24.236018] Modules linked in: i915 x86_pkg_temp_thermal intel_powerclamp crc32_pclmul crc32c_intel intel_cstate intel_uncore intel_gtt drm_kms_helper intel_pch_thermal video button autofs4 i2c_i801 i2c_smbus fan [ 24.236336] CR2: 00000000fe036000 It looks like kasan, xen and i915 are vulnerable. Actual impact is "on thinkpad X60 in 5.9-rc1, screen starts blinking after 30-or-so minutes, and machine is unusable" [sfr@canb.auug.org.au: ARCH_PAGE_TABLE_SYNC_MASK needs vmalloc.h] Link: https://lkml.kernel.org/r/20200825172508.16800a4f@canb.auug.org.au [chris@chris-wilson.co.uk: changelog addition] [pavel@ucw.cz: changelog addition] Link: https://lkml.kernel.org/r/20200821123746.16904-1-joro@8bytes.org Fixes: 2ba3e6947aed ("mm/vmalloc: track which page-table levels were modified") Fixes: 86cf69f1d893 ("x86/mm/32: implement arch_sync_kernel_mappings()") Signed-off-by: Joerg Roedel Signed-off-by: Stephen Rothwell Tested-by: Chris Wilson [x86-32] Acked-by: Linus Torvalds Tested-by: Pavel Machek Cc: [5.8+] Signed-off-by: Andrew Morton --- mm/memory.c | 37 ++++++++++++++++++++++++------------- 1 file changed, 24 insertions(+), 13 deletions(-) --- a/mm/memory.c~mm-track-page-table-modifications-in-__apply_to_page_range +++ a/mm/memory.c @@ -73,6 +73,7 @@ #include #include #include +#include #include @@ -83,6 +84,7 @@ #include #include +#include "pgalloc-track.h" #include "internal.h" #if defined(LAST_CPUPID_NOT_IN_PAGE_FLAGS) && !defined(CONFIG_COMPILE_TEST) @@ -2206,7 +2208,8 @@ EXPORT_SYMBOL(vm_iomap_memory); static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd, unsigned long addr, unsigned long end, - pte_fn_t fn, void *data, bool create) + pte_fn_t fn, void *data, bool create, + pgtbl_mod_mask *mask) { pte_t *pte; int err = 0; @@ -2214,7 +2217,7 @@ static int apply_to_pte_range(struct mm_ if (create) { pte = (mm == &init_mm) ? - pte_alloc_kernel(pmd, addr) : + pte_alloc_kernel_track(pmd, addr, mask) : pte_alloc_map_lock(mm, pmd, addr, &ptl); if (!pte) return -ENOMEM; @@ -2235,6 +2238,7 @@ static int apply_to_pte_range(struct mm_ break; } } while (addr += PAGE_SIZE, addr != end); + *mask |= PGTBL_PTE_MODIFIED; arch_leave_lazy_mmu_mode(); @@ -2245,7 +2249,8 @@ static int apply_to_pte_range(struct mm_ static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud, unsigned long addr, unsigned long end, - pte_fn_t fn, void *data, bool create) + pte_fn_t fn, void *data, bool create, + pgtbl_mod_mask *mask) { pmd_t *pmd; unsigned long next; @@ -2254,7 +2259,7 @@ static int apply_to_pmd_range(struct mm_ BUG_ON(pud_huge(*pud)); if (create) { - pmd = pmd_alloc(mm, pud, addr); + pmd = pmd_alloc_track(mm, pud, addr, mask); if (!pmd) return -ENOMEM; } else { @@ -2264,7 +2269,7 @@ static int apply_to_pmd_range(struct mm_ next = pmd_addr_end(addr, end); if (create || !pmd_none_or_clear_bad(pmd)) { err = apply_to_pte_range(mm, pmd, addr, next, fn, data, - create); + create, mask); if (err) break; } @@ -2274,14 +2279,15 @@ static int apply_to_pmd_range(struct mm_ static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d, unsigned long addr, unsigned long end, - pte_fn_t fn, void *data, bool create) + pte_fn_t fn, void *data, bool create, + pgtbl_mod_mask *mask) { pud_t *pud; unsigned long next; int err = 0; if (create) { - pud = pud_alloc(mm, p4d, addr); + pud = pud_alloc_track(mm, p4d, addr, mask); if (!pud) return -ENOMEM; } else { @@ -2291,7 +2297,7 @@ static int apply_to_pud_range(struct mm_ next = pud_addr_end(addr, end); if (create || !pud_none_or_clear_bad(pud)) { err = apply_to_pmd_range(mm, pud, addr, next, fn, data, - create); + create, mask); if (err) break; } @@ -2301,14 +2307,15 @@ static int apply_to_pud_range(struct mm_ static int apply_to_p4d_range(struct mm_struct *mm, pgd_t *pgd, unsigned long addr, unsigned long end, - pte_fn_t fn, void *data, bool create) + pte_fn_t fn, void *data, bool create, + pgtbl_mod_mask *mask) { p4d_t *p4d; unsigned long next; int err = 0; if (create) { - p4d = p4d_alloc(mm, pgd, addr); + p4d = p4d_alloc_track(mm, pgd, addr, mask); if (!p4d) return -ENOMEM; } else { @@ -2318,7 +2325,7 @@ static int apply_to_p4d_range(struct mm_ next = p4d_addr_end(addr, end); if (create || !p4d_none_or_clear_bad(p4d)) { err = apply_to_pud_range(mm, p4d, addr, next, fn, data, - create); + create, mask); if (err) break; } @@ -2331,8 +2338,9 @@ static int __apply_to_page_range(struct void *data, bool create) { pgd_t *pgd; - unsigned long next; + unsigned long start = addr, next; unsigned long end = addr + size; + pgtbl_mod_mask mask = 0; int err = 0; if (WARN_ON(addr >= end)) @@ -2343,11 +2351,14 @@ static int __apply_to_page_range(struct next = pgd_addr_end(addr, end); if (!create && pgd_none_or_clear_bad(pgd)) continue; - err = apply_to_p4d_range(mm, pgd, addr, next, fn, data, create); + err = apply_to_p4d_range(mm, pgd, addr, next, fn, data, create, &mask); if (err) break; } while (pgd++, addr = next, addr != end); + if (mask & ARCH_PAGE_TABLE_SYNC_MASK) + arch_sync_kernel_mappings(start, start + size); + return err; } From patchwork Fri Sep 4 23:35:55 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 310115 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=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 1BA48C433E2 for ; Fri, 4 Sep 2020 23:35:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DD658208FE for ; Fri, 4 Sep 2020 23:35:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599262557; bh=01S+J4BG+Uf2gR8LLsPpEO4B5nFRQXzksXiZYB5ydhY=; h=Date:From:To:Subject:In-Reply-To:List-ID:From; b=hqNlA155Wt4FgSO9vonWlAcHCHDDSbM/1hTmFp3utp655vf8cCWs+w+bltGTnUuob MTi+9cSVw86J/iM9c5AdkpQbB9rjp5p2lErO7op6H0ncBDmvXLE6V4xFzV0CXOe6Wi 5RybRDn3XXlmCi/9+xAYclePsP0cTkXFXfXBgQHQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728224AbgIDXf5 (ORCPT ); Fri, 4 Sep 2020 19:35:57 -0400 Received: from mail.kernel.org ([198.145.29.99]:38920 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726456AbgIDXf4 (ORCPT ); Fri, 4 Sep 2020 19:35:56 -0400 Received: from localhost.localdomain (c-71-198-47-131.hsd1.ca.comcast.net [71.198.47.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A5B452084D; Fri, 4 Sep 2020 23:35:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599262555; bh=01S+J4BG+Uf2gR8LLsPpEO4B5nFRQXzksXiZYB5ydhY=; h=Date:From:To:Subject:In-Reply-To:From; b=FJ4qmXIWpL8MhhHxO++lxAQTDhBykVP/EquZz1F/7hXd3y6/4owjeZTCcrJPPadLZ SzpEUXirhFzTCcj3LH+zl/uqDL4TwlI7CHGBCZeGJ4upAjdvMoG4nDP9/l/nK72pUw 8LIIujnVLTb0vLnXnDKi0hN4j8zS3ekJX+nrnSqQ= Date: Fri, 04 Sep 2020 16:35:55 -0700 From: Andrew Morton To: akpm@linux-foundation.org, jack@suse.cz, linux-mm@kvack.org, mm-commits@vger.kernel.org, shy828301@gmail.com, stable@vger.kernel.org, torvalds@linux-foundation.org Subject: [patch 11/19] mm: madvise: fix vma user-after-free Message-ID: <20200904233555.nMt3agulD%akpm@linux-foundation.org> In-Reply-To: <20200904163454.4db0e6ce0c4584d2653678a3@linux-foundation.org> User-Agent: s-nail v14.8.16 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Yang Shi Subject: mm: madvise: fix vma user-after-free The syzbot reported the below use-after-free: BUG: KASAN: use-after-free in madvise_willneed mm/madvise.c:293 [inline] BUG: KASAN: use-after-free in madvise_vma mm/madvise.c:942 [inline] BUG: KASAN: use-after-free in do_madvise.part.0+0x1c8b/0x1cf0 mm/madvise.c:1145 Read of size 8 at addr ffff8880a6163eb0 by task syz-executor.0/9996 CPU: 0 PID: 9996 Comm: syz-executor.0 Not tainted 5.9.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x18f/0x20d lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xae/0x497 mm/kasan/report.c:383 __kasan_report mm/kasan/report.c:513 [inline] kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530 madvise_willneed mm/madvise.c:293 [inline] madvise_vma mm/madvise.c:942 [inline] do_madvise.part.0+0x1c8b/0x1cf0 mm/madvise.c:1145 do_madvise mm/madvise.c:1169 [inline] __do_sys_madvise mm/madvise.c:1171 [inline] __se_sys_madvise mm/madvise.c:1169 [inline] __x64_sys_madvise+0xd9/0x110 mm/madvise.c:1169 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45d4d9 Code: 5d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 2b b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f04f7464c78 EFLAGS: 00000246 ORIG_RAX: 000000000000001c RAX: ffffffffffffffda RBX: 0000000000020800 RCX: 000000000045d4d9 RDX: 0000000000000003 RSI: 0000000000600003 RDI: 0000000020000000 RBP: 000000000118d020 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000118cfec R13: 00007ffc579cce7f R14: 00007f04f74659c0 R15: 000000000118cfec Allocated by task 9992: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48 kasan_set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:461 slab_post_alloc_hook mm/slab.h:518 [inline] slab_alloc mm/slab.c:3312 [inline] kmem_cache_alloc+0x138/0x3a0 mm/slab.c:3482 vm_area_alloc+0x1c/0x110 kernel/fork.c:347 mmap_region+0x8e5/0x1780 mm/mmap.c:1743 do_mmap+0xcf9/0x11d0 mm/mmap.c:1545 vm_mmap_pgoff+0x195/0x200 mm/util.c:506 ksys_mmap_pgoff+0x43a/0x560 mm/mmap.c:1596 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 9992: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48 kasan_set_track+0x1c/0x30 mm/kasan/common.c:56 kasan_set_free_info+0x1b/0x30 mm/kasan/generic.c:355 __kasan_slab_free+0xd8/0x120 mm/kasan/common.c:422 __cache_free mm/slab.c:3418 [inline] kmem_cache_free.part.0+0x67/0x1f0 mm/slab.c:3693 remove_vma+0x132/0x170 mm/mmap.c:184 remove_vma_list mm/mmap.c:2613 [inline] __do_munmap+0x743/0x1170 mm/mmap.c:2869 do_munmap mm/mmap.c:2877 [inline] mmap_region+0x257/0x1780 mm/mmap.c:1716 do_mmap+0xcf9/0x11d0 mm/mmap.c:1545 vm_mmap_pgoff+0x195/0x200 mm/util.c:506 ksys_mmap_pgoff+0x43a/0x560 mm/mmap.c:1596 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 It is because vma is accessed after releasing mmap_lock, but someone else acquired the mmap_lock and the vma is gone. Releasing mmap_lock after accessing vma should fix the problem. Link: https://lkml.kernel.org/r/20200816141204.162624-1-shy828301@gmail.com Fixes: 692fe62433d4c ("mm: Handle MADV_WILLNEED through vfs_fadvise()") Reported-by: syzbot+b90df26038d1d5d85c97@syzkaller.appspotmail.com Signed-off-by: Yang Shi Reviewed-by: Andrew Morton Reviewed-by: Jan Kara Cc: [5.4+] Signed-off-by: Andrew Morton --- mm/madvise.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/madvise.c~mm-madvise-fix-vma-user-after-free +++ a/mm/madvise.c @@ -289,9 +289,9 @@ static long madvise_willneed(struct vm_a */ *prev = NULL; /* tell sys_madvise we drop mmap_lock */ get_file(file); - mmap_read_unlock(current->mm); offset = (loff_t)(start - vma->vm_start) + ((loff_t)vma->vm_pgoff << PAGE_SHIFT); + mmap_read_unlock(current->mm); vfs_fadvise(file, offset, end - start, POSIX_FADV_WILLNEED); fput(file); mmap_read_lock(current->mm); From patchwork Fri Sep 4 23:36:01 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 264371 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=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 7477EC2D0A7 for ; Fri, 4 Sep 2020 23:36:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 424FF20DD4 for ; Fri, 4 Sep 2020 23:36:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599262563; bh=rdGcINH+goYdf1OMSWX2vKt8VK8odTAdHQg1iuoOgoM=; h=Date:From:To:Subject:In-Reply-To:List-ID:From; b=Tq6FVRxF5Se+cKMk824xfcGrsluBBDUlRp68/uAvbGLYC5uJlelImuNotNcZd4LyQ LoLUyBuvrp6M8nvGPjUkfd6C8dKiGxo7ua0z27rjkyuzzW9xSOAlq68vtx6kIhHQMX 2PeAfaGfV5nB+ym0xUoASpBClT+D5Pd7dVnCESeg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728253AbgIDXgC (ORCPT ); Fri, 4 Sep 2020 19:36:02 -0400 Received: from mail.kernel.org ([198.145.29.99]:39038 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726456AbgIDXgC (ORCPT ); Fri, 4 Sep 2020 19:36:02 -0400 Received: from localhost.localdomain (c-71-198-47-131.hsd1.ca.comcast.net [71.198.47.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A37D12087C; Fri, 4 Sep 2020 23:36:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599262562; bh=rdGcINH+goYdf1OMSWX2vKt8VK8odTAdHQg1iuoOgoM=; h=Date:From:To:Subject:In-Reply-To:From; b=i18FzwF3sz2Lc2GdUOsu4B+3HCKPJr+BcPThOSQcPkpN7wH5a1Bp9NH4g3RyJv8Km NngelevJKpznHg370U+UKYe6B4ZcZLEC2oJo8HEfsTc+LMQac8W+7lEn93o6L+U258 kuSNx+b5DkqSmJuQj3CokYfjvig3sW8POiYuRQtI= Date: Fri, 04 Sep 2020 16:36:01 -0700 From: Andrew Morton To: akpm@linux-foundation.org, alistair@popple.id.au, jglisse@redhat.com, jhubbard@nvidia.com, linux-mm@kvack.org, mm-commits@vger.kernel.org, peterx@redhat.com, rcampbell@nvidia.com, stable@vger.kernel.org, torvalds@linux-foundation.org Subject: [patch 13/19] mm/rmap: fixup copying of soft dirty and uffd ptes Message-ID: <20200904233601.UPjBGFlal%akpm@linux-foundation.org> In-Reply-To: <20200904163454.4db0e6ce0c4584d2653678a3@linux-foundation.org> User-Agent: s-nail v14.8.16 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Alistair Popple Subject: mm/rmap: fixup copying of soft dirty and uffd ptes During memory migration a pte is temporarily replaced with a migration swap pte. Some pte bits from the existing mapping such as the soft-dirty and uffd write-protect bits are preserved by copying these to the temporary migration swap pte. However these bits are not stored at the same location for swap and non-swap ptes. Therefore testing these bits requires using the appropriate helper function for the given pte type. Unfortunately several code locations were found where the wrong helper function is being used to test soft_dirty and uffd_wp bits which leads to them getting incorrectly set or cleared during page-migration. Fix these by using the correct tests based on pte type. Link: https://lkml.kernel.org/r/20200825064232.10023-2-alistair@popple.id.au Fixes: a5430dda8a3a ("mm/migrate: support un-addressable ZONE_DEVICE page in migration") Fixes: 8c3328f1f36a ("mm/migrate: migrate_vma() unmap page from vma while collecting pages") Fixes: f45ec5ff16a7 ("userfaultfd: wp: support swap and page migration") Signed-off-by: Alistair Popple Reviewed-by: Peter Xu Cc: Jérôme Glisse Cc: John Hubbard Cc: Ralph Campbell Cc: Alistair Popple Cc: Signed-off-by: Andrew Morton --- mm/migrate.c | 15 +++++++++++---- mm/rmap.c | 9 +++++++-- 2 files changed, 18 insertions(+), 6 deletions(-) --- a/mm/migrate.c~mm-rmap-fixup-copying-of-soft-dirty-and-uffd-ptes +++ a/mm/migrate.c @@ -2427,10 +2427,17 @@ again: entry = make_migration_entry(page, mpfn & MIGRATE_PFN_WRITE); swp_pte = swp_entry_to_pte(entry); - if (pte_soft_dirty(pte)) - swp_pte = pte_swp_mksoft_dirty(swp_pte); - if (pte_uffd_wp(pte)) - swp_pte = pte_swp_mkuffd_wp(swp_pte); + if (pte_present(pte)) { + if (pte_soft_dirty(pte)) + swp_pte = pte_swp_mksoft_dirty(swp_pte); + if (pte_uffd_wp(pte)) + swp_pte = pte_swp_mkuffd_wp(swp_pte); + } else { + if (pte_swp_soft_dirty(pte)) + swp_pte = pte_swp_mksoft_dirty(swp_pte); + if (pte_swp_uffd_wp(pte)) + swp_pte = pte_swp_mkuffd_wp(swp_pte); + } set_pte_at(mm, addr, ptep, swp_pte); /* --- a/mm/rmap.c~mm-rmap-fixup-copying-of-soft-dirty-and-uffd-ptes +++ a/mm/rmap.c @@ -1511,9 +1511,14 @@ static bool try_to_unmap_one(struct page */ entry = make_migration_entry(page, 0); swp_pte = swp_entry_to_pte(entry); - if (pte_soft_dirty(pteval)) + + /* + * pteval maps a zone device page and is therefore + * a swap pte. + */ + if (pte_swp_soft_dirty(pteval)) swp_pte = pte_swp_mksoft_dirty(swp_pte); - if (pte_uffd_wp(pteval)) + if (pte_swp_uffd_wp(pteval)) swp_pte = pte_swp_mkuffd_wp(swp_pte); set_pte_at(mm, pvmw.address, pvmw.pte, swp_pte); /*