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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <7d15c878-c4bd-8a30-9faa-7279f78a271f@kernel.org>
Date:   Thu, 17 Mar 2022 08:45:43 -0600
From:   David Ahern <dsahern@...nel.org>
To:     Paolo Abeni <pabeni@...hat.com>,
        Niels Dossche <dossche.niels@...il.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 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.