linux-kernel - [BUG] kprobes crashing because of preempt count

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-next>] [day] [month] [year] [list]

Date:	Thu, 30 Jun 2011 09:23:33 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>
Subject: [BUG] kprobes crashing because of preempt count

Hi Masami,

While testing some changes in -rt against kprobes, I hit a crash that
exists in mainline. If we stick a probe in a location that reads
preempt_count, we corrupt the kernel itself.

Reason is that the kprobe single step handler disables preemption, sets
up the single step, returns to the code to execute that single step,
takes the trap, enables preemption, and continues.

The issue, is because we disabled preemption in the trap, returned, then
enabled it again in another trap, we just changed what the code sees
that does that single step.

If we add a kprobe on a inc_preempt_count() call:

	[ preempt_count = 0 ]

	ld preempt_count, %eax	<<--- trap

		<trap>
		preempt_disable();
		[ preempt_count = 1]
		setup_singlestep();
		<trap return>

	[ preempt_count = 1 ]

	ld preempt_count, %eax

	[ %eax = 1 ]

		<trap>
		post_kprobe_handler()
			preempt_enable_no_resched();
			[ preempt_count = 0 ]
		<trap return>

	[ %eax = 1 ]

	add %eax,1

	[ %eax = 2 ]

	st %eax, preempt_count

	[ preempt_count = 2 ]

We just caused preempt count to increment twice when it should have only
incremented once, and this screws everything else up.

Do we really need to have preemption disabled throughout this? Is it
because we don't want to migrate or call schedule? Not sure what the
best way to fix this is. Perhaps we add a kprobe_preempt_disable() that
is checked as well?

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/