linux-kernel - Re: [PATCH] x86/pat: Fix off-by-one bugs in interval tree search

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: <20191201195521.GC3615@gmail.com>
Date:   Sun, 1 Dec 2019 20:55:21 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     "Kenneth R. Crudup" <kenny@...ix.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>, mceier@...il.com,
        Davidlohr Bueso <dave@...olabs.net>,
        kernel test robot <rong.a.chen@...el.com>,
        Davidlohr Bueso <dbueso@...e.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Borislav Petkov <bp@...en8.de>,
        LKML <linux-kernel@...r.kernel.org>, lkp@...ts.01.org
Subject: Re: [PATCH] x86/pat: Fix off-by-one bugs in interval tree search


* Kenneth R. Crudup <kenny@...ix.com> wrote:

> 
> On Sun, 1 Dec 2019, Ingo Molnar wrote:
> 
> > So it would be nice if everyone who is seeing this bug could test the
> > patch below against Linus's latest tree - does it fix the regression?
> 
> The patch fixes the issue for me.

Great, thanks!

> > If not then please send the before/after dump of
> > /sys/kernel/debug/x86/pat_memtype_list - and even if it works please send
> > the dumps so we can double check it all.
> 
> I don't have the "before patch" (but could if it is absolutely needed) but
> here's the "after patch":

> uncached-minus @ 0xfed91000-0xfed92000
> uncached-minus @ 0xff340000-0xff341000
> write-combining @ 0x4000000000-0x4010000000
> uncached-minus @ 0x4010000000-0x4010001000

I believe this is the region that caused the problem, the 0x4010000000 
'end' address of the WC region is the same as the 0x4010000000 'start' 
address of the UC- region that follows it.

> write-combining @ 0x604a800000-0x604b000000
> uncached-minus @ 0x604b100000-0x604b110000

This WC region was probably unaffected by the bug.

Thanks,

	Ingo