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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.02.1404170951080.22697@ionos.tec.linutronix.de>
Date:	Thu, 17 Apr 2014 09:59:01 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Greg KH <greg@...ah.com>
cc:	Vince Weaver <vincent.weaver@...ne.edu>,
	LKML <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: rb tree hrtimer lockup bug (found by perf_fuzzer)

On Wed, 16 Apr 2014, Greg KH wrote:
> On Thu, Apr 17, 2014 at 01:00:53AM +0200, Thomas Gleixner wrote:
> > And cdevs is an array of  struct cdev:
> > 
> > struct cdev {
> > 	struct kobject kobj;
> 
> Those are not "real" kobjects, and are never registered with the kobject
> core.
> 
> I really need to go rename those one of these days, and just make them a
> separate object, as they have nothing to do with a "normal" kobject
> other than the reference count and the use of the kobject map stuff.
> 
> So if this is showing up as a problem, something else is going on here,
> as this should not be an issue at all.

As far as I decoded it from Vince traces the issue is only with
DEBUG_KOBJECT_RELEASE=y. That deferres the release to a workqueue.

Now the cdevs in tty are allocated ahead and not freed on
release. They stay in the cdevs[] array of the tty drivers.

Now if a cdev is released the kobject debug stuff schedules the
delayed work, but the tty core can reuse the cdev.before the delayed
work has been executed and first thing it does is calling cdev_init()
which does a

     memset(cdev, 0, sizeof *cdev);

which of course includes the enqueued timer and the scheduled work. Go
figure how well that goes.

Thanks,

	tglx

--
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/