All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
To: kasan-dev <kasan-dev@googlegroups.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: KASAN Arm: global-out-of-bounds in load_module
Date: Sun, 28 Nov 2021 01:43:09 +0100	[thread overview]
Message-ID: <CANiq72kGS0JzFkuUS9oN2_HU9f_stm1gA8v79o2pUCb7bNSe0A@mail.gmail.com> (raw)

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

WARNING: multiple messages have this Message-ID (diff)
From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
To: kasan-dev <kasan-dev@googlegroups.com>,
	 Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 linux-kernel <linux-kernel@vger.kernel.org>
Subject: KASAN Arm: global-out-of-bounds in load_module
Date: Sun, 28 Nov 2021 01:43:09 +0100	[thread overview]
Message-ID: <CANiq72kGS0JzFkuUS9oN2_HU9f_stm1gA8v79o2pUCb7bNSe0A@mail.gmail.com> (raw)

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

             reply	other threads:[~2021-11-28  0:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-28  0:43 Miguel Ojeda [this message]
2021-11-28  0:43 ` KASAN Arm: global-out-of-bounds in load_module 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

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=CANiq72kGS0JzFkuUS9oN2_HU9f_stm1gA8v79o2pUCb7bNSe0A@mail.gmail.com \
    --to=miguel.ojeda.sandonis@gmail.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.