[External] Re: kasan-for-arm32

李文杰 liwenjie.liwenjie at bytedance.com
Sun Nov 27 23:06:14 PST 2022


Dear All:

1. Now I met a problem that the kasan-for-arm32 could not check global
variable OOB;
2. For example , I define a global array g_test_array[8] = "1234567",
and g_test_array[16]='A'. But it couldn't kasan report bug.
3. I have disassembled the vmlinux, and I am sure that __asan_store1()
was inserted before memory access to g_test_array[16]. But the shadow
memory is zero.
4. More I found that g_test_array[8] has no redzone, it seems that
__asan_register_globals() was not called.

could anyone help me? Thanks very much,,

李文杰 <liwenjie.liwenjie at bytedance.com> 于2022年11月11日周五 15:53写道:
>
> Dear Florian Fainelli,
>
> 1. Thanks for reply, Yes, it looks like that. And I will talk about it
> with Qualcomm further.
>
> 2. Now Linus Walleij' kasan-for-arm32  patch has worked on my machine
> successfully, and it can report slab UAF and slab OOB now.
>
> 3. But it does not work on out-of-bounds accesses to stack or global
> variables now. I notice that the feature depend on >=gcc 5.0, but my
> compiler is clang 11.0.2.
>
> Florian Fainelli <f.fainelli at gmail.com> 于2022年11月11日周五 06:43写道:
> >
> > On 11/10/22 08:17, 李文杰 wrote:
> > > Dear Linus Walleij,
> > >
> > > Thanks for reply,
> > >
> > > 1. I know why my kernel-5.4's vmalloc region not shadowed already,
> > > because the CONFIG_ENABLE_VMALLOC_SAVING=y was enabled.
> > >
> > > 2. But I could not find it in mainline,so I guess it was added by Qualcomm.
> > >
> > > 3. Once it was enabled, the VMALLOC_START and VMALLOC_END will be
> > > invalid.The code is some like below:
> > >
> > > 553 #ifdef CONFIG_ENABLE_VMALLOC_SAVING
> > > 554         print_vmalloc_lowmem_info();
> > > 555 #else
> > > 556         pr_notice(
> > > 557                    "    vmalloc : 0x%08lx - 0x%08lx   (%4ld MB)\n"
> > > 558                    "    lowmem  : 0x%08lx - 0x%08lx   (%4ld MB)\n",
> > > 559                         MLM(VMALLOC_START, VMALLOC_END),
> > > 560                         MLM(PAGE_OFFSET, (unsigned long)high_memory));
> > > 561 #endif
> > >
> > > 4. Instead, the vmalloc region follows lowmem region one by one, so my
> > > kernel virtual memory layout as below:
> >
> > You seem to have the intermix patch from Qualcomm:
> >
> > https://lkml.indiana.edu/hypermail/linux/kernel/1401.0/00518.html
> >
> > > [    0.000000] Virtual kernel memory layout:
> > > [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> > > [    0.000000]     fixmap  : 0xffc80000 - 0xfff00000   (2560 kB)
> > > [    0.000000]     vmalloc : 0xf8500000 - 0xff800000   ( 115 MB)  //highmem
> > > [    0.000000]     lowmem  : 0xe1f00000 - 0xf8500000   ( 358 MB)
> > > [    0.000000]     vmalloc : 0xe0e00000 - 0xe1f00000   (  17 MB)
> > > [    0.000000]     lowmem  : 0xe0100000 - 0xe0e00000   (  13 MB)
> > > [    0.000000]     vmalloc : 0xe0000000 - 0xe0100000   (   1 MB)
> > > [    0.000000]     lowmem  : 0xcff17000 - 0xe0000000   ( 256 MB)
> > > [    0.000000]     vmalloc : 0xcab00000 - 0xcff17000   (  84 MB)
> > > [    0.000000]     lowmem  : 0xc6300000 - 0xcab00000   (  72 MB)
> > > [    0.000000]     vmalloc : 0xc5fff000 - 0xc6300000   (   3 MB)
> > > [    0.000000]     lowmem  : 0xc5f10000 - 0xc5fff000   (   0 MB)
> > > [    0.000000]     vmalloc : 0xc5a00000 - 0xc5f10000   (   5 MB)
> > > [    0.000000]     lowmem  : 0xc0000000 - 0xc5a00000   (  90 MB)
> > > [    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
> > > [    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
> > > [    0.000000]       .text : 0x(ptrval) - 0x(ptrval)   (27616 kB)
> > > [    0.000000]       .init : 0x(ptrval) - 0x(ptrval)   (1024 kB)
> > > [    0.000000]       .data : 0x(ptrval) - 0x(ptrval)   (2221 kB)
> > > [    0.000000]        .bss : 0x(ptrval) - 0x(ptrval)   (8100 kB)
> > >
> > > 5. Now my solution is that, add all vmalloc regions above except
> > > highmem to the mapping. Then my machine bringup successfully.
> > > arch/arm/mm/kasan_init.c -> kasan_init() -> create_mapping().
> > >
> > > 6. Next I will continue to try and enjoy your kasan-for-arm32 patch in
> > > my machine.
> > >
> > > Thanks again dear Linus Walleij and Lecopzer.chen,
> > >
> > > Linus Walleij <linus.walleij at linaro.org> 于2022年11月10日周四 17:51写道:
> > >>
> > >> On Wed, Nov 9, 2022 at 12:14 PM 李文杰 <liwenjie.liwenjie at bytedance.com> wrote:
> > >>
> > >> [Contex: porting kasan to kernel v5.4]
> > >>
> > >>> 1. I know why my machine crash after porting the patch.
> > >>> 2. Because the kernel access the vmalloc region, which not shadowed.
> > >>> 3. Now I found at least two places where used vmalloc region:
> > >>>     1). arch/arm/mm/fault-armv.c ->check_writebuffer_bugs() -> vmap();
> > >>>     2). lib/genalloc.c -> chunk = vzalloc_node(nbytes, nid);
> > >>> 4. could I add the vmalloc to shadow memory region?
> > >>
> > >> I think you need to backport at least the following patches from upstream:
> > >>
> > >> 823f606ab6b4 ARM: 9242/1: kasan: Only map modules if CONFIG_KASAN_VMALLOC=n
> > >> 565cbaad83d8 ARM: 9202/1: kasan: support CONFIG_KASAN_VMALLOC
> > >>
> > >> Both from Lecopzer Chen.
> > >>
> > >> Yours,
> > >> Linus Walleij
> > >
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel at lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
> > --
> > Florian
> >



More information about the linux-arm-kernel mailing list