netdev - Re: RCU lock bug in 3.0.21 (bisected to: 682cb56a, fix NULL dereferences in check_peer

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4F71508C.908@candelatech.com>
Date:	Mon, 26 Mar 2012 22:30:52 -0700
From:	Ben Greear <greearb@...delatech.com>
To:	paulmck@...ux.vnet.ibm.com
CC:	Eric Dumazet <eric.dumazet@...il.com>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	gregkh@...uxfoundation.org
Subject: Re: RCU lock bug in 3.0.21 (bisected to: 682cb56a, fix NULL dereferences
 in check_peer_redir)

On 03/26/2012 10:11 PM, Paul E. McKenney wrote:
> On Tue, Mar 27, 2012 at 02:07:14AM +0200, Eric Dumazet wrote:
>> On Mon, 2012-03-26 at 16:46 -0700, Ben Greear wrote:
>>
>>> The 3.0.21 kernel doesn't appear to have a rcu_read_lock_return(),
>>> so I can't use your patch below.
>>
>> This patch was only to show the point (I also CCed Paul, he might have
>> some time to think about it, after he clears the inline stuff with
>> Linus)
>
> There is an rcu_preempt_depth() that returns rcu_read_lock() nesting
> level for CONFIG_PREEMPT_RCU=y on the one hand and returns zero
> for CONFIG_PREEMPT_RCU=n on the other.  So if you can reproduce
> with CONFIG_PREEMPT_RCU=y, you can substitute rcu_preempt_depth()
> rcu_read_lock_return() in Eric's earlier patch.

I'll try looking at that tomorrow.  I tried adding some code to check for
recursive calls to the fib-dump, and didn't see it ever hit, though
the bug continued to happen readily.

I just #if 0 the part between rcu-read-lock and read-unlock, and
the problem went away..but of course you can't dump ipv6
routes then...

The actual logic to dump the fib is quite complex, full of
opaque types and other stuff ripe for bugs.  But, I don't see
how it could cause the rcu splats in such a repeatable manner.

The bug is always reported as being in the same place, so if
there is any other debugging code you can think of to help
shed light on this, I'll be happy to add it and give it a try.
For instance, is there a way to dump (print) all current holders of
the rcu_read_lock?  I could call that before/during/after in that
method and maybe get a clue.

Thanks,
Ben

>
> 							Thanx, Paul
>
>> As I said, I was referreing to you adding stuff in rcu. ;)
>>
>> Unfortunately I wont have time in the near future to do so myself.
>>
>>
>>

-- 
Ben Greear <greearb@...delatech.com>
Candela Technologies Inc  http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html