From: Ard Biesheuvel <ardb@kernel.org>
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>
Subject: Re: KASAN Arm: global-out-of-bounds in load_module
Date: Mon, 29 Nov 2021 15:11:11 +0100 [thread overview]
Message-ID: <CAMj1kXH7D-0bhv79cRPergquC8-ryCi7YvTokHSaJ14ZHd_F8w@mail.gmail.com> (raw)
In-Reply-To: <CA+fCnZcUEVDWZTUvD+mbe2OrnrpJCC_OB66YMvbZYak8sKg7cw@mail.gmail.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ardb@kernel.org>
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>
Subject: Re: KASAN Arm: global-out-of-bounds in load_module
Date: Mon, 29 Nov 2021 15:11:11 +0100 [thread overview]
Message-ID: <CAMj1kXH7D-0bhv79cRPergquC8-ryCi7YvTokHSaJ14ZHd_F8w@mail.gmail.com> (raw)
In-Reply-To: <CA+fCnZcUEVDWZTUvD+mbe2OrnrpJCC_OB66YMvbZYak8sKg7cw@mail.gmail.com>
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.
next prev parent reply other threads:[~2021-11-29 14:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2021-11-29 14:11 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMj1kXH7D-0bhv79cRPergquC8-ryCi7YvTokHSaJ14ZHd_F8w@mail.gmail.com \
--to=ardb@kernel.org \
--cc=a.fatoum@pengutronix.de \
--cc=andreyknvl@gmail.com \
--cc=dvyukov@google.com \
--cc=f.fainelli@gmail.com \
--cc=kasan-dev@googlegroups.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miguel.ojeda.sandonis@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.