netdev - Re: [PATCH] ipv6: acquire write lock for addr_list in dev_forward

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

Message-ID: <f5e541f8-2222-8c24-381f-2fa28d37eb5a@gmail.com>
Date:   Thu, 17 Mar 2022 15:51:29 +0100
From:   Niels Dossche <dossche.niels@...il.com>
To:     David Ahern <dsahern@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
        netdev@...r.kernel.org
Cc:     "David S. Miller" <davem@...emloft.net>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>
Subject: Re: [PATCH] ipv6: acquire write lock for addr_list in
 dev_forward_change

On 17/03/2022 15:45, David Ahern wrote:
> On 3/17/22 5:13 AM, Paolo Abeni wrote:
>> On Wed, 2022-03-16 at 00:02 +0100, Niels Dossche wrote:
>>> No path towards dev_forward_change (common ancestor of paths is in
>>> addrconf_fixup_forwarding) acquires idev->lock for idev->addr_list.
>>> Since addrconf_{join,leave}_anycast acquire a write lock on addr_list in
>>> __ipv6_dev_ac_inc and __ipv6_dev_ac_dec, temporarily unlock when calling
>>> addrconf_{join,leave}_anycast analogous to how it's done in
>>> addrconf_ifdown.
>>>
>>> Signed-off-by: Niels Dossche <dossche.niels@...il.com>
>>> ---
>>>  net/ipv6/addrconf.c | 4 ++++
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>>> index f908e2fd30b2..4055ded4b7bf 100644
>>> --- a/net/ipv6/addrconf.c
>>> +++ b/net/ipv6/addrconf.c
>>> @@ -818,14 +818,18 @@ static void dev_forward_change(struct inet6_dev *idev)
>>>  		}
>>>  	}
>>>  
>>> +	write_lock_bh(&idev->lock);
>>>  	list_for_each_entry(ifa, &idev->addr_list, if_list) {
>>>  		if (ifa->flags&IFA_F_TENTATIVE)
>>>  			continue;
>>> +		write_unlock_bh(&idev->lock);
>>
>> This looks weird?!? if 'addr_list' integrity is guaranteed by 
>> idev->lock, than this patch looks incorrect. If addr_list integrity is
>> ensured elsewhere, why acquiring idev->lock at all?
>>
>> @David: can you please comment here?
>>
> 
> I have stared at this change a few times. It does look weird and does
> not seem to be really solving the problem (or completely solving it).
> 
> I think a better option is to investigate moving the locks in the
> anycast functions up a layer or two so that the lock here can be held
> for the entire list walk.

Hi
Thanks for the review.
I can write a patch today that fixes it the way you suggest and then send it as a v2.