linux-kernel - Re: rb tree hrtimer lockup bug (found by perf

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]

Date:	Wed, 26 Mar 2014 23:00:52 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Vince Weaver <vincent.weaver@...ne.edu>
cc:	LKML <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>, Greg KH <greg@...ah.com>
Subject: Re: rb tree hrtimer lockup bug (found by perf_fuzzer)

On Wed, 26 Mar 2014, Vince Weaver wrote:
> On Tue, 25 Mar 2014, Thomas Gleixner wrote:
> > Do you happen to have the full bootlog up to the crash handy?
> 
> attached is the full bootlog followed by the tracedump.

Ok. So we know now what we are looking for.

[    1.579996] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
ÿ[    1.607279] 00:09: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[    1.615032] kobject: 'ttyS1' (ffff88011772ac10): kobject_release, parent           (null) (delayed 250)
[    1.624534] kobject: '(null)' (ffff8801177400f0): kobject_release, parent           (null) (delayed 500)
[    1.654213] 0000:00:16.3: ttyS1 at I/O 0xf0e0 (irq = 19, base_baud = 115200) is a 16550A

[    3.294047] Invalid timer base: tmr ffff880117740150 tmr->base           (null) base ffff880118898000

1634110us : obj: ffff880117740130 initialized kobject_delayed_cleanup+0x0/0x90

So that happens in the context of the 8250 serial driver.
 
> > Adding "initcall_debug" to the kernel command line might give us a
> > further hint what is adding the delayed_work, but I guess once we see
> > the function in the trace we have a good chance to find the place
> > right away. Then we have to figure out what scribbles over it .....
> 
> I haven't tried the initcall_debug yet but can if needed.

Below is a patch which gives us the call path of the unnamed object
which causes the crash.

Greg???

Thanks,

	tglx

---
 lib/kobject.c |    3 +++
 1 file changed, 3 insertions(+)

Index: linux-2.6/lib/kobject.c
===================================================================
--- linux-2.6.orig/lib/kobject.c
+++ linux-2.6/lib/kobject.c
@@ -645,6 +645,9 @@ static void kobject_release(struct kref
 	struct kobject *kobj = container_of(kref, struct kobject, kref);
 #ifdef CONFIG_DEBUG_KOBJECT_RELEASE
 	unsigned long delay = HZ + HZ * (get_random_int() & 0x3);
+
+	WARN_ON(!kobject_name(kobj));
+
 	pr_info("kobject: '%s' (%p): %s, parent %p (delayed %ld)\n",
 		 kobject_name(kobj), kobj, __func__, kobj->parent, delay);
 	INIT_DELAYED_WORK(&kobj->release, kobject_delayed_cleanup);