linux-kernel - Re: [GIT pull] x86/irq for v5.18-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.2203232114180.52439@angie.orcam.me.uk>
Date:   Wed, 23 Mar 2022 21:23:44 +0000 (GMT)
From:   "Maciej W. Rozycki" <macro@...am.me.uk>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
cc:     Thomas Gleixner <tglx@...utronix.de>,
        Dmitry Osipenko <dmitry.osipenko@...labora.com>,
        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, 21 Mar 2022, Linus Torvalds wrote:

> Because that stupid IRT routing table code already been reported to cause bugs:
> 
>     https://lore.kernel.org/all/a2791312-2957-27e6-43af-c805bbb90266@collabora.com/
> 
> which seems to be because the $IRT signature check is complete garbage:
> 
> > +       for (addr = (u8 *)__va(0xf0000); addr < (u8 *)__va(0x100000); addr++) {
> > +               rt = pirq_convert_irt_table(addr);
> > +               if (rt)
> > +                       return rt;
> 
> The above doesn't seem like it could really ever have been tested
> properly, since it will walk off the end of that __va(0x100000)
> address: it will walk every byte up to the 1MB physical address, and
> it will try to find that $IRT signature there, but if it never finds
> it, IT WILL CHECK THE SIGNATURE PAST THE 1MB mark!

 Drat!  I did verify this code in a simulated environment that does supply 
a $IRT table (for a reporter who has an actual system; I'm not lucky 
enough to have one), however somehow I didn't think of verifying it with a 
setup that has neither a $PIR nor a $IRT table.  Therefore this issue has 
slipped ($PIR scanner works in 16-byte intervals, so it escapes the range
overrun), and then of course things started moving only while I am away 
enjoying Italian mountains.  Oh well, nobody's perfect.

 Thanks for narrowing this down, I'll post a fixed version on or shortly 
after this coming weekend.  And sorry for the mess-up!

  Maciej