[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whi5jG0PjXmG6UHvvmZm5Y0MrLeBWbC=JQma1Upm-z6rA@mail.gmail.com>
Date: Mon, 21 Mar 2022 12:27:40 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Thomas Gleixner <tglx@...utronix.de>,
"Maciej W. Rozycki" <macro@...am.me.uk>,
Dmitry Osipenko <dmitry.osipenko@...labora.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: [GIT pull] x86/irq for v5.18-rc1
On Mon, Mar 21, 2022 at 12:17 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> The fix seems obvious (you don't walk every byte to 1M, you walk to 1M
> - the size of the struct, and then you also check that the number of
> entries actually fits - Dmitry can presumably test), but no way do I
> want to get this kind of clearly broken thing this merge window.
Side note: the $PIRQ case avoids this because it walks 16 bytes at a
time, so the $PIRQ signature check itself will never overflow past the
1M mark.
But that code doesn't verify that the table itself then stays inside
that range, so that code is a bit fragile too.
At the same time, at least it has properly verified that it found the
right BIOS signature marker, so if the table is then bad and crosses
the 1M mark, it's arguably a BIOS bug (not that those don't happen,
and we should catch it).
In contrat, the $IRT code will walk over the boundary just *looking*
for the signature and not finding it (and not finding it is presumably
the normal thing, since $IRT is some odd legacy AMI-only thing).
Linus
Powered by blists - more mailing lists