Messages in this thread | | | From | Andrey Konovalov <> | Date | Mon, 29 Nov 2021 13:56:24 +0100 | Subject | Re: KASAN Arm: global-out-of-bounds in load_module |
| |
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!
| |