From: Dennis Zhou <dennis@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
Yury Norov <yury.norov@gmail.com>,
Russell King - ARM Linux <linux@armlinux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 5.19-rc8
Date: Tue, 26 Jul 2022 10:39:50 -0700 [thread overview]
Message-ID: <YuAm5h1B6bsrR/9q@fedora> (raw)
In-Reply-To: <CAHk-=whtGUwJwHUSNsXd4g7cok=n0Zwje7nACp8skh1fa2NtJA@mail.gmail.com>
Hello,
On Mon, Jul 25, 2022 at 10:55:18AM -0700, Linus Torvalds wrote:
> On Mon, Jul 25, 2022 at 9:11 AM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > BUG: KFENCE: out-of-bounds read in _find_next_bit_le+0x10/0x48
>
> Ok, I was hoping somebody more ARMy would look at this, particularly
> since there is no call trace beyond the actual fault.
>
> So it shows that it happens in _find_next_bit_le(), but not who called it.
>
> It does show "who allocated the page", and I can see the message that
> is printed afterwards, so it comes from that
>
> static void __init test_bitmap_printlist(void)
>
> function, so I guess we know the call chain:
>
> test_bitmap_printlist ->
> bitmap_print_to_pagebuf ->
> scnprintf "%*pbl\n" ->
> pointer ->
> bitmap_list_string ->
> for_each_set_bitrange
>
> and I think I see what's wrong in there. That thing does
>
> (b) = find_next_bit((addr), (size), (e) + 1), \
> (e) = find_next_zero_bit((addr), (size), (b) + 1))
>
> for the end of the range, and looking at the oops, the instruction
> that oopses is
>
> ldrb r3, [r0, r2, lsr #3]
>
> where 'r2' is the bit position, and 'r0' is the start of the bitmap.
>
> And:
>
> > r10: 00000000 r9 : 0000002d r8 : ef59d000
> > r7 : c0e55514 r6 : c2215000 r5 : 00008000 r4 : 00008000
> > r3 : 845cac12 r2 : 00008001 r1 : 00008000 r0 : ef59d000
>
> Lookie here: r1 contains the size, and r2 is past the end of the size.
>
> So pick your poison: either the bug is in
>
> (a) the bitmap region iterators shouldn't even ask for past-the-end results
>
> I've added Dennis Zhou who did that first
> bitmap_for_each_set_region() in commit e837dfde15a4 ("bitmap:
> genericize percpu bitmap region iterators"), and Yuri Norov who
> renamed and moved it to for_each_set_bitrange() in commit ec288a2cf7ca
> ("bitmap: unify find_bit operations").
>
It seems like this is mostly taken care of by migrating arm to use the
generic implementations, but I just want to cover our basis here.
Are we okay with adding the contract find_*_bit() operations must handle
asking for past size properly? FWIW, we'd have to modify most of the
iterators in find.h.
Thanks,
Dennis
next prev parent reply other threads:[~2022-07-26 17:40 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-24 20:42 Linux 5.19-rc8 Linus Torvalds
2022-07-25 16:11 ` Guenter Roeck
2022-07-25 17:55 ` Linus Torvalds
2022-07-25 18:49 ` Linus Torvalds
2022-07-25 20:35 ` Yury Norov
2022-07-25 20:40 ` Linus Torvalds
2022-07-26 15:51 ` Yury Norov
2022-07-25 19:41 ` Yury Norov
2022-07-26 9:12 ` Russell King (Oracle)
2022-07-26 15:35 ` Yury Norov
2022-07-28 18:28 ` Russell King (Oracle)
2022-07-29 0:11 ` Guenter Roeck
2022-07-26 17:39 ` Dennis Zhou [this message]
2022-07-26 17:51 ` Linus Torvalds
2022-07-26 18:18 ` Yury Norov
2022-07-26 18:36 ` Linus Torvalds
2022-07-26 19:44 ` Russell King (Oracle)
2022-07-26 20:20 ` Linus Torvalds
2022-07-27 0:15 ` Russell King (Oracle)
2022-07-27 1:33 ` Yury Norov
2022-07-27 7:43 ` Russell King (Oracle)
2022-07-30 21:38 ` Yury Norov
2022-08-01 15:48 ` Russell King (Oracle)
2022-08-01 15:54 ` Russell King (Oracle)
2022-07-27 7:46 ` David Laight
2022-07-25 20:34 ` Build regressions/improvements in v5.19-rc8 Geert Uytterhoeven
2022-07-25 20:39 ` Geert Uytterhoeven
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=YuAm5h1B6bsrR/9q@fedora \
--to=dennis@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linux@roeck-us.net \
--cc=torvalds@linux-foundation.org \
--cc=yury.norov@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox