From: David Ahern <dsah...@kernel.org>
Date: Mon, 30 Sep 2019 20:28:34 -0700

> From: David Ahern <dsah...@gmail.com>
> 
> Rajendra reported a kernel panic when a link was taken down:
 ...
> addrconf_dad_work is kicked to be scheduled when a device is brought
> up. There is a race between addrcond_dad_work getting scheduled and
> taking the rtnl lock and a process taking the link down (under rtnl).
> The latter removes the host route from the inet6_addr as part of
> addrconf_ifdown which is run for NETDEV_DOWN. The former attempts
> to use the host route in ipv6_ifa_notify. If the down event removes
> the host route due to the race to the rtnl, then the BUG listed above
> occurs.
> 
> This scenario does not occur when the ipv6 address is not kept
> (net.ipv6.conf.all.keep_addr_on_down = 0) as addrconf_ifdown sets the
> state of the ifp to DEAD. Handle when the addresses are kept by checking
> IF_READY which is reset by addrconf_ifdown.
> 
> The 'dead' flag for an inet6_addr is set only under rtnl, in
> addrconf_ifdown and it means the device is getting removed (or IPv6 is
> disabled). The interesting cases for changing the idev flag are
> addrconf_notify (NETDEV_UP and NETDEV_CHANGE) and addrconf_ifdown
> (reset the flag). The former does not have the idev lock - only rtnl;
> the latter has both. Based on that the existing dead + IF_READY check
> can be moved to right after the rtnl_lock in addrconf_dad_work.
> 
> Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional")
> Reported-by: Rajendra Dendukuri <rajendra.denduk...@broadcom.com>
> Signed-off-by: David Ahern <dsah...@gmail.com>

Applied and queued up for -stable.

Reply via email to