KASAN Arm: global-out-of-bounds in load_module

KASAN Arm: global-out-of-bounds in load_module

[Miguel Ojeda]

Hi KASAN / Arm folks,

I noticed in our CI that inserting and removing a module, and then
inserting it again, e.g.:

    insmod bcm2835_thermal.ko
    rmmod bcm2835_thermal.ko
    insmod bcm2835_thermal.ko

deterministically triggers the report below in v5.16-rc2. I also tried
it on v5.12 to see if it was a recent thing, but same story.

I could find this other report from May, which may be related:
https://lore.kernel.org/lkml/20210510202653.gjvqsxacw3hcxfvr@pengutronix.de/

Cheers,
Miguel

BUG: KASAN: global-out-of-bounds in load_module+0x1b98/0x33b0
Write of size 16384 at addr bf000000 by task busybox/17

CPU: 0 PID: 17 Comm: busybox Not tainted 5.15.0 #7
Hardware name: Generic DT based system
[<c010f968>] (unwind_backtrace) from [<c010c6f8>] (show_stack+0x10/0x14)
[<c010c6f8>] (show_stack) from [<c0210734>]
(print_address_description+0x58/0x384)
[<c0210734>] (print_address_description) from [<c0210cc8>]
(kasan_report+0x168/0x1fc)
[<c0210cc8>] (kasan_report) from [<c0211230>] (kasan_check_range+0x260/0x2a8)
[<c0211230>] (kasan_check_range) from [<c0211c68>] (memset+0x20/0x44)
[<c0211c68>] (memset) from [<c019d21c>] (load_module+0x1b98/0x33b0)
[<c019d21c>] (load_module) from [<c0199f88>] (sys_init_module+0x198/0x1ac)
[<c0199f88>] (sys_init_module) from [<c0100060>] (ret_fast_syscall+0x0/0x48)
Exception stack(0xc113ffa8 to 0xc113fff0)
ffa0:                   00000000 00002a98 00098038 00002a98 00081483 00093f88
ffc0: 00000000 00002a98 00000000 00000080 00000001 b66ffef0 00081483 000815c7
ffe0: b66ffbd8 b66ffbc8 000207f5 00011cc2


Memory state around the buggy address:
 bf001200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 bf001280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>bf001300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9
                                                     ^
 bf001380: 00 00 07 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
 bf001400: 00 00 f9 f9 f9 f9 f9 f9 00 00 04 f9 f9 f9 f9 f9

Re: KASAN Arm: global-out-of-bounds in load_module

[Dmitry Vyukov]

On Sun, 28 Nov 2021 at 01:43, Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> Hi KASAN / Arm folks,
>
> I noticed in our CI that inserting and removing a module, and then
> inserting it again, e.g.:
>
>     insmod bcm2835_thermal.ko
>     rmmod bcm2835_thermal.ko
>     insmod bcm2835_thermal.ko
>
> deterministically triggers the report below in v5.16-rc2. I also tried
> it on v5.12 to see if it was a recent thing, but same story.
>
> I could find this other report from May, which may be related:
> https://lore.kernel.org/lkml/20210510202653.gjvqsxacw3hcxfvr@pengutronix.de/
>
> Cheers,
> Miguel

HI Miguel,

0xf9 is redzone for global variables:
#define KASAN_GLOBAL_REDZONE    0xF9  /* redzone for global variable */

I would assume this is caused by not clearing shadow of unloaded
modules, so that the next module loaded hits these leftover redzones.

+arm mailing list and Linus W


> BUG: KASAN: global-out-of-bounds in load_module+0x1b98/0x33b0
> Write of size 16384 at addr bf000000 by task busybox/17
>
> CPU: 0 PID: 17 Comm: busybox Not tainted 5.15.0 #7
> Hardware name: Generic DT based system
> [<c010f968>] (unwind_backtrace) from [<c010c6f8>] (show_stack+0x10/0x14)
> [<c010c6f8>] (show_stack) from [<c0210734>]
> (print_address_description+0x58/0x384)
> [<c0210734>] (print_address_description) from [<c0210cc8>]
> (kasan_report+0x168/0x1fc)
> [<c0210cc8>] (kasan_report) from [<c0211230>] (kasan_check_range+0x260/0x2a8)
> [<c0211230>] (kasan_check_range) from [<c0211c68>] (memset+0x20/0x44)
> [<c0211c68>] (memset) from [<c019d21c>] (load_module+0x1b98/0x33b0)
> [<c019d21c>] (load_module) from [<c0199f88>] (sys_init_module+0x198/0x1ac)
> [<c0199f88>] (sys_init_module) from [<c0100060>] (ret_fast_syscall+0x0/0x48)
> Exception stack(0xc113ffa8 to 0xc113fff0)
> ffa0:                   00000000 00002a98 00098038 00002a98 00081483 00093f88
> ffc0: 00000000 00002a98 00000000 00000080 00000001 b66ffef0 00081483 000815c7
> ffe0: b66ffbd8 b66ffbc8 000207f5 00011cc2
>
>
> Memory state around the buggy address:
>  bf001200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  bf001280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >bf001300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9
>                                                      ^
>  bf001380: 00 00 07 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
>  bf001400: 00 00 f9 f9 f9 f9 f9 f9 00 00 04 f9 f9 f9 f9 f9
>
> --
> You received this message because you are subscribed to the Google Groups "kasan-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/CANiq72kGS0JzFkuUS9oN2_HU9f_stm1gA8v79o2pUCb7bNSe0A%40mail.gmail.com.

Re: KASAN Arm: global-out-of-bounds in load_module

[Andrey Konovalov]

On Mon, Nov 29, 2021 at 7:37 AM 'Dmitry Vyukov' via kasan-dev
<kasan-dev@googlegroups.com> wrote:
>
> On Sun, 28 Nov 2021 at 01:43, Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
> >
> > Hi KASAN / Arm folks,
> >
> > I noticed in our CI that inserting and removing a module, and then
> > inserting it again, e.g.:
> >
> >     insmod bcm2835_thermal.ko
> >     rmmod bcm2835_thermal.ko
> >     insmod bcm2835_thermal.ko
> >
> > deterministically triggers the report below in v5.16-rc2. I also tried
> > it on v5.12 to see if it was a recent thing, but same story.
> >
> > I could find this other report from May, which may be related:
> > https://lore.kernel.org/lkml/20210510202653.gjvqsxacw3hcxfvr@pengutronix.de/
> >
> > Cheers,
> > Miguel
>
> HI Miguel,
>
> 0xf9 is redzone for global variables:
> #define KASAN_GLOBAL_REDZONE    0xF9  /* redzone for global variable */
>
> I would assume this is caused by not clearing shadow of unloaded
> modules, so that the next module loaded hits these leftover redzones.

Hi Miguel,

Adding to what Dmitry mentioned:

The code that's responsible for allocating&clearing/freeing shadow for
modules is at the very end of mm/kasan/shadow.c. It's only required
when CONFIG_KASAN_VMALLOC is not supported/enabled.

As 32-bit arm doesn't select HAVE_ARCH_KASAN_VMALLOC, perhaps it needs
something along the lines of what kasan_module_alloc() does with
regards to clearing shadow? I assume arm doesn't call that function
directly due to a different shadow allocation scheme.

Just a guess.

Thanks!

Re: KASAN Arm: global-out-of-bounds in load_module

[Ard Biesheuvel]

On Mon, 29 Nov 2021 at 13:56, Andrey Konovalov <andreyknvl@gmail.com> wrote:
>
> On Mon, Nov 29, 2021 at 7:37 AM 'Dmitry Vyukov' via kasan-dev
> <kasan-dev@googlegroups.com> wrote:
> >
> > On Sun, 28 Nov 2021 at 01:43, Miguel Ojeda
> > <miguel.ojeda.sandonis@gmail.com> wrote:
> > >
> > > Hi KASAN / Arm folks,
> > >
> > > I noticed in our CI that inserting and removing a module, and then
> > > inserting it again, e.g.:
> > >
> > >     insmod bcm2835_thermal.ko
> > >     rmmod bcm2835_thermal.ko
> > >     insmod bcm2835_thermal.ko
> > >
> > > deterministically triggers the report below in v5.16-rc2. I also tried
> > > it on v5.12 to see if it was a recent thing, but same story.
> > >
> > > I could find this other report from May, which may be related:
> > > https://lore.kernel.org/lkml/20210510202653.gjvqsxacw3hcxfvr@pengutronix.de/
> > >
> > > Cheers,
> > > Miguel
> >
> > HI Miguel,
> >
> > 0xf9 is redzone for global variables:
> > #define KASAN_GLOBAL_REDZONE    0xF9  /* redzone for global variable */
> >
> > I would assume this is caused by not clearing shadow of unloaded
> > modules, so that the next module loaded hits these leftover redzones.
>
> Hi Miguel,
>
> Adding to what Dmitry mentioned:
>
> The code that's responsible for allocating&clearing/freeing shadow for
> modules is at the very end of mm/kasan/shadow.c. It's only required
> when CONFIG_KASAN_VMALLOC is not supported/enabled.
>
> As 32-bit arm doesn't select HAVE_ARCH_KASAN_VMALLOC, perhaps it needs
> something along the lines of what kasan_module_alloc() does with
> regards to clearing shadow? I assume arm doesn't call that function
> directly due to a different shadow allocation scheme.
>

Side note: vmap'ed stacks support is being added to ARM,  so it would
be worth it to investigate whether we can support
HAVE_ARCH_KASAN_VMALLOC on ARM as well, otherwise we cannot enable
vmap'ed stacks and KASAN at the same time.