On 10/30/17 11:47 PM, Eric Dumazet wrote:
> From: Eric Dumazet <eduma...@google.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 <eduma...@google.com>
> Cc: David Ahern <dsah...@gmail.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 <dsah...@gmail.com>
