MIME-Version: 1.0
References: <CANiq72kGS0JzFkuUS9oN2_HU9f_stm1gA8v79o2pUCb7bNSe0A@mail.gmail.com>
 <CACT4Y+Z7bD62SkYGQH2tXV0Zx2MFojYoZzA2R+4J-CrXa6siMw@mail.gmail.com> <CA+fCnZcUEVDWZTUvD+mbe2OrnrpJCC_OB66YMvbZYak8sKg7cw@mail.gmail.com>
In-Reply-To: <CA+fCnZcUEVDWZTUvD+mbe2OrnrpJCC_OB66YMvbZYak8sKg7cw@mail.gmail.com>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Mon, 29 Nov 2021 15:11:11 +0100
Message-ID: <CAMj1kXH7D-0bhv79cRPergquC8-ryCi7YvTokHSaJ14ZHd_F8w@mail.gmail.com>
Subject: Re: KASAN Arm: global-out-of-bounds in load_module
To:     Andrey Konovalov <andreyknvl@gmail.com>
Cc:     Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        kasan-dev <kasan-dev@googlegroups.com>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Linus Walleij <linus.walleij@linaro.org>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Ahmad Fatoum <a.fatoum@pengutronix.de>,
        Dmitry Vyukov <dvyukov@google.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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.