netdev - Re: [PATCH net] ipv6: addrconf: increment ifp refcount before ipv6_del

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: <1af0cf58-cf26-ed98-cb76-9547f3b3eae6@gmail.com>
Date:   Tue, 31 Oct 2017 10:09:40 -0600
From:   David Ahern <dsahern@...il.com>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     netdev <netdev@...r.kernel.org>, David Miller <davem@...emloft.net>
Subject: Re: [PATCH net] ipv6: addrconf: increment ifp refcount before
 ipv6_del_addr()

On 10/30/17 11:47 PM, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@...gle.com>
> 
> In the (unlikely) event fixup_permanent_addr() returns a failure,
> addrconf_permanent_addr() calls ipv6_del_addr() without the
> mandatory call to in6_ifa_hold(), leading to a refcount error,
> spotted by syzkaller :
> 
> WARNING: CPU: 1 PID: 3142 at lib/refcount.c:227 refcount_dec+0x4c/0x50
> lib/refcount.c:227
> Kernel panic - not syncing: panic_on_warn set ...
> 
...
> 
> Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional")
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> Cc: David Ahern <dsahern@...il.com>
> ---
>  net/ipv6/addrconf.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 4a96ebbf8eda5f59a6ff88e836d666a404d2bf0d..8a1c846d3df949a4638589f187120db22a3525ba 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -3335,6 +3335,7 @@ static void addrconf_permanent_addr(struct net_device *dev)
>  		if ((ifp->flags & IFA_F_PERMANENT) &&
>  		    fixup_permanent_addr(idev, ifp) < 0) {
>  			write_unlock_bh(&idev->lock);
> +			in6_ifa_hold(ifp);
>  			ipv6_del_addr(ifp);
>  			write_lock_bh(&idev->lock);
>  
> 
> 

Interestingly, I put the failure sequence into a loop and hit the above
path closing in on 1 million times and I am not seeing a memory leak
with our without this patch.

The above does fix the refcnt and based on other call sites for
ipv6_del_addr is the right thing to do, so...

Acked-by: David Ahern <dsahern@...il.com>