Patch "pstore: Avoid kcore oops by vmap()ing with VM_IOREMAP" has been added to the 5.4-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

    pstore: Avoid kcore oops by vmap()ing with VM_IOREMAP

to the 5.4-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:
     pstore-avoid-kcore-oops-by-vmap-ing-with-vm_ioremap.patch
and it can be found in the queue-5.4 subdirectory.

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



commit 49febbb23103955ad9fd0b489536ebd7ea4b3f78
Author: Stephen Boyd <swboyd@xxxxxxxxxxxx>
Date:   Mon Dec 5 15:31:36 2022 -0800

    pstore: Avoid kcore oops by vmap()ing with VM_IOREMAP
    
    [ Upstream commit e6b842741b4f39007215fd7e545cb55aa3d358a2 ]
    
    An oops can be induced by running 'cat /proc/kcore > /dev/null' on
    devices using pstore with the ram backend because kmap_atomic() assumes
    lowmem pages are accessible with __va().
    
     Unable to handle kernel paging request at virtual address ffffff807ff2b000
     Mem abort info:
     ESR = 0x96000006
     EC = 0x25: DABT (current EL), IL = 32 bits
     SET = 0, FnV = 0
     EA = 0, S1PTW = 0
     FSC = 0x06: level 2 translation fault
     Data abort info:
     ISV = 0, ISS = 0x00000006
     CM = 0, WnR = 0
     swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000081d87000
     [ffffff807ff2b000] pgd=180000017fe18003, p4d=180000017fe18003, pud=180000017fe18003, pmd=0000000000000000
     Internal error: Oops: 96000006 [#1] PREEMPT SMP
     Modules linked in: dm_integrity
     CPU: 7 PID: 21179 Comm: perf Not tainted 5.15.67-10882-ge4eb2eb988cd #1 baa443fb8e8477896a370b31a821eb2009f9bfba
     Hardware name: Google Lazor (rev3 - 8) (DT)
     pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
     pc : __memcpy+0x110/0x260
     lr : vread+0x194/0x294
     sp : ffffffc013ee39d0
     x29: ffffffc013ee39f0 x28: 0000000000001000 x27: ffffff807ff2b000
     x26: 0000000000001000 x25: ffffffc0085a2000 x24: ffffff802d4b3000
     x23: ffffff80f8a60000 x22: ffffff802d4b3000 x21: ffffffc0085a2000
     x20: ffffff8080b7bc68 x19: 0000000000001000 x18: 0000000000000000
     x17: 0000000000000000 x16: 0000000000000000 x15: ffffffd3073f2e60
     x14: ffffffffad588000 x13: 0000000000000000 x12: 0000000000000001
     x11: 00000000000001a2 x10: 00680000fff2bf0b x9 : 03fffffff807ff2b
     x8 : 0000000000000001 x7 : 0000000000000000 x6 : 0000000000000000
     x5 : ffffff802d4b4000 x4 : ffffff807ff2c000 x3 : ffffffc013ee3a78
     x2 : 0000000000001000 x1 : ffffff807ff2b000 x0 : ffffff802d4b3000
     Call trace:
     __memcpy+0x110/0x260
     read_kcore+0x584/0x778
     proc_reg_read+0xb4/0xe4
    
    During early boot, memblock reserves the pages for the ramoops reserved
    memory node in DT that would otherwise be part of the direct lowmem
    mapping. Pstore's ram backend reuses those reserved pages to change the
    memory type (writeback or non-cached) by passing the pages to vmap()
    (see pfn_to_page() usage in persistent_ram_vmap() for more details) with
    specific flags. When read_kcore() starts iterating over the vmalloc
    region, it runs over the virtual address that vmap() returned for
    ramoops. In aligned_vread() the virtual address is passed to
    vmalloc_to_page() which returns the page struct for the reserved lowmem
    area. That lowmem page is passed to kmap_atomic(), which effectively
    calls page_to_virt() that assumes a lowmem page struct must be directly
    accessible with __va() and friends. These pages are mapped via vmap()
    though, and the lowmem mapping was never made, so accessing them via the
    lowmem virtual address oopses like above.
    
    Let's side-step this problem by passing VM_IOREMAP to vmap(). This will
    tell vread() to not include the ramoops region in the kcore. Instead the
    area will look like a bunch of zeros. The alternative is to teach kmap()
    about vmalloc areas that intersect with lowmem. Presumably such a change
    isn't a one-liner, and there isn't much interest in inspecting the
    ramoops region in kcore files anyway, so the most expedient route is
    taken for now.
    
    Cc: Brian Geffon <bgeffon@xxxxxxxxxx>
    Cc: Mike Rapoport <rppt@xxxxxxxxxx>
    Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
    Fixes: 404a6043385d ("staging: android: persistent_ram: handle reserving and mapping memory")
    Signed-off-by: Stephen Boyd <swboyd@xxxxxxxxxxxx>
    Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx>
    Link: https://lore.kernel.org/r/20221205233136.3420802-1-swboyd@xxxxxxxxxxxx
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index 1f4d8c06f9be..286340f312dc 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -427,7 +427,11 @@ static void *persistent_ram_vmap(phys_addr_t start, size_t size,
 		phys_addr_t addr = page_start + i * PAGE_SIZE;
 		pages[i] = pfn_to_page(addr >> PAGE_SHIFT);
 	}
-	vaddr = vmap(pages, page_count, VM_MAP, prot);
+	/*
+	 * VM_IOREMAP used here to bypass this region during vread()
+	 * and kmap_atomic() (i.e. kcore) to avoid __va() failures.
+	 */
+	vaddr = vmap(pages, page_count, VM_MAP | VM_IOREMAP, prot);
 	kfree(pages);
 
 	/*



[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