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
| ||
|
Date: Sun, 13 Jun 2021 21:04:18 +0100 From: Matthew Wilcox <willy@...radead.org> To: David Mozes <david.mozes@...k.us> Cc: "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>, Darren Hart <dvhart@...radead.org>, linux-kernel@...r.kernel.org Subject: Re: futex/call -to plist_for_each_entry_safe with head=NULL On Sun, Jun 13, 2021 at 12:24:52PM +0000, David Mozes wrote: > Hi *, > Under a very high load of io traffic, we got the below BUG trace. > We can see that: > plist_for_each_entry_safe(this, next, &hb1->chain, list) { > if (match_futex (&this->key, &key1)) > > were called with hb1 = NULL at futex_wake_up function. > And there is no protection on the code regarding such a scenario. > > The NULL can be geting from: > hb1 = hash_futex(&key1); > > How can we protect against such a situation? Can you reproduce it without loading proprietary modules? Your analysis doesn't quite make sense: hb1 = hash_futex(&key1); hb2 = hash_futex(&key2); retry_private: double_lock_hb(hb1, hb2); If hb1 were NULL, then the oops would come earlier, in double_lock_hb(). > RIP: 0010:do_futex+0xdf/0xa90 > > 0xffffffff81138eff is in do_futex (kernel/futex.c:1748). > 1743 put_futex_key(&key1); > 1744 cond_resched(); > 1745 goto retry; > 1746 } > 1747 > 1748 plist_for_each_entry_safe(this, next, &hb1->chain, list) { > 1749 if (match_futex (&this->key, &key1)) { > 1750 if (this->pi_state || this->rt_waiter) { > 1751 ret = -EINVAL; > 1752 goto out_unlock; > (gdb) > > > > plist_for_each_entry_safe(this, next, &hb1->chain, list) { > if (match_futex (&this->key, &key1)) { > > > > > This happened in kernel 4.19.149 running on Azure vm > > > Thx > David > Reply > Forward > MO >
Powered by blists - more mailing lists