linux-kernel - Re: KASAN Arm: global-out-of-bounds in load

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 29 Nov 2021 13:56:24 +0100
From:   Andrey Konovalov <andreyknvl@...il.com>
To:     Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc:     Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        kasan-dev <kasan-dev@...glegroups.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Ahmad Fatoum <a.fatoum@...gutronix.de>,
        Dmitry Vyukov <dvyukov@...gle.com>
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@...glegroups.com> wrote:
>
> On Sun, 28 Nov 2021 at 01:43, Miguel Ojeda
> <miguel.ojeda.sandonis@...il.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!