linux-kernel - Re: [PATCH tip/master] [BUGFIX] kprobes/x86: Fix to clear TF bit in fault-on-single-stepping

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: <20160613192019.219a3a5f@gandalf.local.home>
Date:	Mon, 13 Jun 2016 19:20:19 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Masami Hiramatsu <mhiramat@...nel.org>
Cc:	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>,
	Ananth N Mavinakayanahalli <ananth@...ux.vnet.ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H . Peter Anvin" <hpa@...or.com>,
	Andy Lutomirski <luto@...nel.org>, systemtap@...rceware.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	fenghua.yu@...el.com
Subject: Re: [PATCH tip/master] [BUGFIX] kprobes/x86: Fix to clear TF bit in
 fault-on-single-stepping

On Mon, 13 Jun 2016 19:13:45 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:


> >   # cd /sys/kernel/debug/tracing
> >   # echo p copy_user_enhanced_fast_string+5 > kprobe_events
> >   # echo 1 > events/kprobes/enable
> > 
> > And you'll see a kernel panic on do_debug(), since the debug
> > trap is not handled by kprobes.
> > 
> > To fix this problem, we just need to clear the TF bit when
> > resetting running kprobe.
> >   
> 
> This should definitely be marked for stable, and I bisected it all the
> way down to this commit: f4cb1cc18f364d "x86-64, copy_user: Remove zero
> byte check before copy user buffer."
> 
> I reverted that commit and sure enough, this bug goes away. I'm not
> saying the revert should be done. I'm just doing an FYI, and showing how
> changes that appear to be a nice clean up can have subtle effects. I'm
> not even sure how that change caused this to be a problem with kprobes.
> 

Nevermind, reverting that commit only moved the location of the
"rep movsb" that you were placing the kprobe on. When I do:

  echo "p copy_user_enhanced_fast_string+9" > kprobe_events

I get the same result.

That means we need to make that stable tag even earlier.

-- Steve