linux-kernel - Re: [GIT PULL] please pull one bug fix for v4.4

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: <CAO6TR8WQW+BJmaAVeodMS460ppRpK5p6zeLn8gULS0i3SzooXA@mail.gmail.com>
Date:	Mon, 11 Jan 2016 14:27:20 -0700
From:	Jeff Merkey <linux.mdb@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andy Lutomirski <luto@...capital.net>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Andy Lutomirski <luto@...nel.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Borislav Petkov <bp@...en8.de>, Jiri Olsa <jolsa@...nel.org>
Subject: Re: [GIT PULL] please pull one bug fix for v4.4

On 1/11/16, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> The merge window is open, so I started looking at this that I had
> ignored as being too late last time..
>
> On Sun, Dec 13, 2015 at 7:02 PM, Jeff Merkey <linux.mdb@...il.com> wrote:
>> Patch address with email included:
>>
>> https://github.com/jeffmerkey/linux/commit/e1d3c76814c839a835286843f0bca33b0c5d0dd8.patch
>
> So at a minimum, I'd like a sign-off for the patch. But also, can you
> describe how to actually trigger the problem? Is this actually
> triggerable without an ICE?
>
>                 Linus
>

Hi Linus,

It is triggerable without an ice, any module can call set_debugreg dr7
and trigger it, and some do, and I suspect a lot of cases where folks
see hard hangs are related to this issue if some program happens to
stuff bogus data into dr6 -- most folks just don't know this is what
causes it.

That being said,  it seems to require an ICE of some sort fiddling
with the debug registers to cause it, though there are places in the
code I based on what I reviewed where someone running GDB from
userspace could trigger it because thread.debugreg6 gets whacked.
Not all of the code paths clear the trap flag in debugreg6 after a
trap occurs and this bit seems to get recycled.

I will send you an updated pull location properly signed off.

Jeff