* KASAN Arm: global-out-of-bounds in load_module
@ 2021-11-28 0:43 ` Miguel Ojeda
0 siblings, 0 replies; 8+ messages in thread
From: Miguel Ojeda @ 2021-11-28 0:43 UTC (permalink / raw)
To: kasan-dev, Linux ARM, linux-kernel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* KASAN Arm: global-out-of-bounds in load_module @ 2021-11-28 0:43 ` Miguel Ojeda 0 siblings, 0 replies; 8+ messages in thread From: Miguel Ojeda @ 2021-11-28 0:43 UTC (permalink / raw) To: kasan-dev, Linux ARM, linux-kernel 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: KASAN Arm: global-out-of-bounds in load_module 2021-11-28 0:43 ` Miguel Ojeda @ 2021-11-29 6:37 ` Dmitry Vyukov -1 siblings, 0 replies; 8+ messages in thread From: Dmitry Vyukov @ 2021-11-29 6:37 UTC (permalink / raw) To: Miguel Ojeda, Linux ARM Cc: kasan-dev, linux-kernel, Linus Walleij, Ard Biesheuvel, Florian Fainelli, Ahmad Fatoum 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: KASAN Arm: global-out-of-bounds in load_module @ 2021-11-29 6:37 ` Dmitry Vyukov 0 siblings, 0 replies; 8+ messages in thread From: Dmitry Vyukov @ 2021-11-29 6:37 UTC (permalink / raw) To: Miguel Ojeda, Linux ARM Cc: kasan-dev, linux-kernel, Linus Walleij, Ard Biesheuvel, Florian Fainelli, Ahmad Fatoum 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: KASAN Arm: global-out-of-bounds in load_module 2021-11-29 6:37 ` Dmitry Vyukov @ 2021-11-29 12:56 ` Andrey Konovalov -1 siblings, 0 replies; 8+ messages in thread From: Andrey Konovalov @ 2021-11-29 12:56 UTC (permalink / raw) To: Miguel Ojeda Cc: Linux ARM, kasan-dev, linux-kernel, Linus Walleij, Ard Biesheuvel, Florian Fainelli, Ahmad Fatoum, Dmitry Vyukov 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! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: KASAN Arm: global-out-of-bounds in load_module @ 2021-11-29 12:56 ` Andrey Konovalov 0 siblings, 0 replies; 8+ messages in thread From: Andrey Konovalov @ 2021-11-29 12:56 UTC (permalink / raw) To: Miguel Ojeda Cc: Linux ARM, kasan-dev, linux-kernel, Linus Walleij, Ard Biesheuvel, Florian Fainelli, Ahmad Fatoum, Dmitry Vyukov 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! ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: KASAN Arm: global-out-of-bounds in load_module 2021-11-29 12:56 ` Andrey Konovalov @ 2021-11-29 14:11 ` Ard Biesheuvel -1 siblings, 0 replies; 8+ messages in thread From: Ard Biesheuvel @ 2021-11-29 14:11 UTC (permalink / raw) To: Andrey Konovalov Cc: Miguel Ojeda, Linux ARM, kasan-dev, linux-kernel, Linus Walleij, Florian Fainelli, Ahmad Fatoum, Dmitry Vyukov 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: KASAN Arm: global-out-of-bounds in load_module @ 2021-11-29 14:11 ` Ard Biesheuvel 0 siblings, 0 replies; 8+ messages in thread From: Ard Biesheuvel @ 2021-11-29 14:11 UTC (permalink / raw) To: Andrey Konovalov Cc: Miguel Ojeda, Linux ARM, kasan-dev, linux-kernel, Linus Walleij, Florian Fainelli, Ahmad Fatoum, Dmitry Vyukov 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-11-29 16:09 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-11-28 0:43 KASAN Arm: global-out-of-bounds in load_module Miguel Ojeda 2021-11-28 0:43 ` Miguel Ojeda 2021-11-29 6:37 ` Dmitry Vyukov 2021-11-29 6:37 ` Dmitry Vyukov 2021-11-29 12:56 ` Andrey Konovalov 2021-11-29 12:56 ` Andrey Konovalov 2021-11-29 14:11 ` Ard Biesheuvel 2021-11-29 14:11 ` Ard Biesheuvel
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.