linux-kernel - Re: v2.6.31-rc6: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008

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: <20090825142424.GF6114@nowhere>
Date:	Tue, 25 Aug 2009 16:24:27 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-kernel@...r.kernel.org, x86@...nel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: v2.6.31-rc6: BUG: unable to handle kernel NULL pointer
	dereference at 0000000000000008

On Mon, Aug 24, 2009 at 09:10:38PM -0700, Linus Torvalds wrote:
> 
> 
> On Tue, 25 Aug 2009, Frederic Weisbecker wrote:
> > 
> > Now that also makes the TTY_LDISC flag clearing unprotected by
> > tty->ldisc_mutex.
> 
> Yes.
> 
> > tty_set_ldisc() can play concurrently with these flags right?
> 
> .. but that shouldn't matter.
> 
> The actual bit-setting is "atomic" already - and any other atomicity is 
> pretty much unattainable, because all the routines in question drop the 
> lock they need to hold in order to make it really be reliably atomic.
> 
> > tty_ldisc_halt() could remain protected by the mutex, so that the
> > flag is safely toggled. Once it is cleared, we can ensure no more
> > user can ref it and the lock can be relaxed while the pending
> > work is flushed.
> 
> That would make no difference at all. tty_set_ldisc() won't care about the 
> flag (in fact, it will do its own tty_ldisc_halt()), and will be happy to 
> replace the ldisc we just flushed with a new one regardless of whether it 
> was halted before or not. And it will do tty_ldisc_enable() regardless of 
> whether it was enabled or not before.
> 
> In fact, because tty_set_ldisc() itself had to release the ldisc_mutex 
> (for the same reason), you have this issue regardless of whether you hold 
> the lock in tty_hangup() or not: the two will always be able to get "mixed 
> up", because they - by design - have to release that silly lock.



Hmm, that's why I had a headache while trying to imagine every races in this
place...



> That's why I said I was unhappy about the tty layer locking - it really 
> isn't very sane. Things like tty_set_ldisc() will drop the lock in the 
> middle because of that crazy workqueue deadlock - exactly for the same 
> reasons that tty_ldisc_hangup() will need to do that "wait for things to 
> flush" without the lock held.
> 
> So I could have taken the ldisc_mutex, and then just dropped it 
> temporarily while waiting for any workqueue entries, but as far as I can 
> tell, it doesn't actually solve anything.


Yeah, indeed.



> I considered using the TTY_LDISC_CHANGING bit(*) there to protect against 
> tty_set_ldisc(), and it may even be the right solution. But there's no way 
> I'll do that kind of changes this late in the -rc series.
> 
> We also have the "TTY_HUPPED" bit that disables tty_set_ldisc(), but that 
> is set too late by do_tty_hangup(), and so doesn't fix the problem either. 
> Again, moving it earlier may be a solution, but again, it's not 
> appropriate for this late in the -rc.


Ok.

 
> Finally, the solution that is most likely the _real_ solution would be to 
> just fix the locking. The whole "ldisc_mutex" seems dubious. It's not even 
> a real lock - exactly because it's dropped - and we already really use 
> that TTY_LDISC_CHANGING bit to do the _real_ locking. I don't think it 
> needs to be a mutex at all. The locking is just very dubious. 
> 
> And that, least of all, is anything I'm willing to really do in -rc. 
> 
> Anyway, I'll happily be shown wrong. I think the (second) patch I sent out 
> is an acceptable hack in the presense of the current locking, but as I 
> said, I'm not exactly happy about it, because I do think the locking is 
> broken.
> 
> 		Linus
> 
> (*) We already have that hacky open-coded "lock" using TTY_LDISC_CHANGING, 
> which protects two different tty_set_ldisc()'s from screwing up each other 
> when they drop the semaphore. It could be just separated out into a 
> function of its own, and then the hangup code would/could/should be taught 
> to use that logic.


Ok, thanks.

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