Patch "ARM: 9242/1: kasan: Only map modules if CONFIG_KASAN_VMALLOC=n" has been added to the 5.15-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    ARM: 9242/1: kasan: Only map modules if CONFIG_KASAN_VMALLOC=n

to the 5.15-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     arm-9242-1-kasan-only-map-modules-if-config_kasan_vm.patch
and it can be found in the queue-5.15 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 303d9665f160d2f61a139c8d360d86a28c9f1afb
Author: Alex Sverdlin <alexander.sverdlin@xxxxxxxxx>
Date:   Mon Sep 5 16:26:59 2022 +0100

    ARM: 9242/1: kasan: Only map modules if CONFIG_KASAN_VMALLOC=n
    
    [ Upstream commit 823f606ab6b4759a1faf0388abcf4fb0776710d2 ]
    
    In case CONFIG_KASAN_VMALLOC=y kasan_populate_vmalloc() allocates the
    shadow pages dynamically. But even worse is that kasan_release_vmalloc()
    releases them, which is not compatible with create_mapping() of
    MODULES_VADDR..MODULES_END range:
    
    BUG: Bad page state in process kworker/9:1  pfn:2068b
    page:e5e06160 refcount:0 mapcount:0 mapping:00000000 index:0x0
    flags: 0x1000(reserved)
    raw: 00001000 e5e06164 e5e06164 00000000 00000000 00000000 ffffffff 00000000
    page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
    bad because of flags: 0x1000(reserved)
    Modules linked in: ip_tables
    CPU: 9 PID: 154 Comm: kworker/9:1 Not tainted 5.4.188-... #1
    Hardware name: LSI Axxia AXM55XX
    Workqueue: events do_free_init
    unwind_backtrace
    show_stack
    dump_stack
    bad_page
    free_pcp_prepare
    free_unref_page
    kasan_depopulate_vmalloc_pte
    __apply_to_page_range
    apply_to_existing_page_range
    kasan_release_vmalloc
    __purge_vmap_area_lazy
    _vm_unmap_aliases.part.0
    __vunmap
    do_free_init
    process_one_work
    worker_thread
    kthread
    
    Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx>
    Signed-off-by: Alexander Sverdlin <alexander.sverdlin@xxxxxxxxx>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@xxxxxxxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
index 4b1619584b23..948ada4a2938 100644
--- a/arch/arm/mm/kasan_init.c
+++ b/arch/arm/mm/kasan_init.c
@@ -264,12 +264,17 @@ void __init kasan_init(void)
 
 	/*
 	 * 1. The module global variables are in MODULES_VADDR ~ MODULES_END,
-	 *    so we need to map this area.
+	 *    so we need to map this area if CONFIG_KASAN_VMALLOC=n. With
+	 *    VMALLOC support KASAN will manage this region dynamically,
+	 *    refer to kasan_populate_vmalloc() and ARM's implementation of
+	 *    module_alloc().
 	 * 2. PKMAP_BASE ~ PKMAP_BASE+PMD_SIZE's shadow and MODULES_VADDR
 	 *    ~ MODULES_END's shadow is in the same PMD_SIZE, so we can't
 	 *    use kasan_populate_zero_shadow.
 	 */
-	create_mapping((void *)MODULES_VADDR, (void *)(PKMAP_BASE + PMD_SIZE));
+	if (!IS_ENABLED(CONFIG_KASAN_VMALLOC) && IS_ENABLED(CONFIG_MODULES))
+		create_mapping((void *)MODULES_VADDR, (void *)(MODULES_END));
+	create_mapping((void *)PKMAP_BASE, (void *)(PKMAP_BASE + PMD_SIZE));
 
 	/*
 	 * KAsan may reuse the contents of kasan_early_shadow_pte directly, so



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux