linux-kernel - Re: [BUG 4.9/4.10] crash in __d_lookup() due to corrupted dentry

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

Date:   Mon, 20 Mar 2017 13:08:22 +0100
From:   Heiko Carstens <heiko.carstens@...ibm.com>
To:     Al Viro <viro@...IV.linux.org.uk>,
        Gustavo Luiz Ferreira Walbon <gwalbon@...ibm.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [BUG 4.9/4.10] crash in __d_lookup() due to corrupted
 dentry_hashtable

On Fri, Mar 03, 2017 at 02:31:50PM +0100, Heiko Carstens wrote:
> Hello Al,
> 
> Gustavo reported the crash below within __d_lookup() on s390. I'm wondering
> if you can make any sense of it:
> 
> Unable to handle kernel pointer dereference in virtual kernel address space
> Failing address: fffffffffffff000 TEID: fffffffffffff803
> Fault in home space mode while using kernel ASCE.

...

> Kernel panic - not syncing: Fatal exception: panic_on_oops
> 
> Looking at the relevant part of __d_lookup:
> 
> struct dentry *__d_lookup(const struct dentry *parent, const struct qstr *name)
> {
> 	unsigned int hash = name->hash;
> 	struct hlist_bl_head *b = d_hash(hash);  <--- points to corrupted entry
> 	struct hlist_bl_node *node;
> 	struct dentry *found = NULL;
> 	struct dentry *dentry;
> 
> 	rcu_read_lock();
> 	
> 	hlist_bl_for_each_entry_rcu(dentry, node, b, d_hash) {
> 
> 		if (dentry->d_name.hash != hash)
> 			continue;
> ...
> 
> The contents of *b within the dump is:
> 
> > struct hlist_bl_head 000003e0806248f8
> struct hlist_bl_head {
> 	first = 0xffffffffffffffff
> }
> 
> Note that 0x000003e0806248f8 is a valid address within the
> dentry_hashtable. In addition all other entries look ok, as far as I can
> tell. This is the only entry that contains a -1UL value.
> 
> We also have a second dump with a similar crash with a 4.9 kernel. In that
> case there are in total three entries spread within the dentry_hashtable
> with a -1UL value, while all other entries seem to look ok. So there seems
> to be a pattern.
> 
> Note: these kernels do contain addon patches that are not mainline, but I
> don't believe that any of those can explain these corruptions.

Famous last words... it looks like it was indeed one of our addon patches.

At least with the bug fixed Gustavo reported that the system now survives
a 60h stress test, which it previously didn't.