linux-kernel - Re: 2.6.25-git2: BUG: unable to handle kernel paging request at ffffffffffffffff

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:	Mon, 21 Apr 2008 18:24:41 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-ext4@...r.kernel.org
Subject: Re: 2.6.25-git2: BUG: unable to handle kernel paging request at ffffffffffffffff

On Monday, 21 of April 2008, Linus Torvalds wrote:
> 
> On Sun, 20 Apr 2008, Paul E. McKenney wrote:
> > 
> > And it passes.
> 
> Ok, I applied it, with hopefully an understandable commit message.
> 
> That said, now we just need to figure out what actually caused the bug in 
> question.
> 
> Rafael: if it's a too-early free of the dentry (which could be because 
> somebody didn't do a proper rcu read-lock, or maybe the rcu grace period 
> logic itself got broken?), then enabling SLUB/SLAB debugging should catch 
> it much more quickly (and hopefully we'd see the signature of a 
> use-after-free - the poisoning byte pattern rather than the -1).
> 
> The other alternative is simply memory corruption. Ie the -1 may well be 
> somebody *else* overwritin the ->next pointer because they did a 
> use-after-free and maybe the dentry_cache is shared with some other 
> allocation of the same size (SLUB does that, no?)
> 
> Rafael: your last oops does seem to imply that there is some strange 
> memory corruption going on, because in that case the invalid pointer is 
> different: instead of being all-ones, it is "fff0810023444c98", which is 
> not a possible pointer. It very much looks like a single nybble got 
> cleared (because ffff810023444c98 _would_ be a valid pointer, notice the 
> "fff0" vs "ffff" prefix).
> 
> So I do suspect it's *some* kind of use-after-free thing. But nothing in 
> fs/ has changed, so it's not a dentry bug, I think. Which is why my 
> "preferred" suspect is that "somebody else also does allocations of the 
> same size as the dentry code, and shares the same SLUB alloc space, and 
> does something bad".
> 
> So Rafael - are you using SLUB, and if you are, can you enable SLUB_DEBUG, 
> and then use the "slub_debug" kernel command line to enable it?

Sure, I have SLUB_DEBUG on already, rebooting with "slub_debug".

Thanks,
Rafael
--
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/