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-next>] [day] [month] [year] [list]
Message-ID: <YMZkwsa4yQ/SsMW/@casper.infradead.org>
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ