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: <37e7909450ebd3b1abcc83119603aa75ab8fc22b.camel@redhat.com>
Date:   Thu, 17 Mar 2022 12:13:41 +0100
From:   Paolo Abeni <pabeni@...hat.com>
To:     Niels Dossche <dossche.niels@...il.com>, netdev@...r.kernel.org,
        David Ahern <dsahern@...nel.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 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?

Thanks!

Paolo