[PATCH net v2] ipv6: anycast: insert aca into global hash under idev->lock

[PATCH net v2] ipv6: anycast: insert aca into global hash under idev->lock

[Jiayuan Chen]

syzbot reported a splat [1]: a slab-use-after-free in
ipv6_chk_acast_addr(), which walks the global inet6_acaddr_lst[] hash
under RCU and dereferences a struct ifacaddr6 that has already been
freed while still linked in the hash, so a later reader walks into a
dangling node.

In __ipv6_dev_ac_inc() the aca is allocated with refcount 1, then
aca_get() bumps it to 2 to keep it alive across the unlocked region.
It is published to idev->ac_list under idev->lock, but
ipv6_add_acaddr_hash() runs after write_unlock_bh(). A concurrent
teardown (ipv6_ac_destroy_dev() from addrconf_ifdown(), under RTNL)
can slip into that window:

  CPU0 __ipv6_dev_ac_inc           CPU1 ipv6_ac_destroy_dev (RTNL)
  ------------------------------   ------------------------------------
  aca_alloc()              refcnt 1
  aca_get()               refcnt 2
  write_lock_bh(idev->lock)
    add aca to ac_list
  write_unlock_bh(idev->lock)
                                   write_lock_bh(idev->lock)
                                     pull aca off ac_list
                                   write_unlock_bh(idev->lock)
                                   ipv6_del_acaddr_hash(aca)
                                     hlist_del_init_rcu() is a no-op,
                                     aca is not in the hash yet
                                   aca_put()           refcnt 2->1
  ipv6_add_acaddr_hash(aca)
    aca now inserted into the hash
  aca_put()                refcnt 1->0
    call_rcu(aca_free_rcu) -> kfree(aca)

The hash removal becomes a no-op because the insertion has not
happened yet, so once CPU0 inserts and drops the last reference, the
aca is freed while still linked in inet6_acaddr_lst[], and readers
dereference freed memory after the slab slot is reused.

This window opened once RTNL stopped serializing the join path against
device teardown. Move ipv6_add_acaddr_hash() inside the idev->lock
section so the ac_list and hash insertions are atomic with respect to
teardown: a racing remover now either misses the aca entirely or finds
it in both lists.

acaddr_hash_lock is now nested under idev->lock, which is acquired in
softirq context, so switch all acaddr_hash_lock sites to spin_lock_bh()
to avoid the irq lock inversion reported in [2].

[1] https://syzkaller.appspot.com/bug?extid=a01df04303c131efbf3a
[2] https://lore.kernel.org/netdev/6a194ef7.ba3b1513.1890b4.0000.GAE@google.com/

Reported-by: syzbot+819eb928d120d2bdad0e@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/6a191f87.ce022c6e.138e56.0003.GAE@google.com/T/
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Fixes: eb1ac9ff6c4a ("ipv6: anycast: Don't hold RTNL for IPV6_JOIN_ANYCAST.")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
 net/ipv6/anycast.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/net/ipv6/anycast.c b/net/ipv6/anycast.c
index 67a42e01dfc3..be6dac8a8566 100644
--- a/net/ipv6/anycast.c
+++ b/net/ipv6/anycast.c
@@ -243,16 +243,16 @@ static void ipv6_add_acaddr_hash(struct net *net, struct ifacaddr6 *aca)
 {
 	unsigned int hash = inet6_acaddr_hash(net, &aca->aca_addr);
 
-	spin_lock(&acaddr_hash_lock);
+	spin_lock_bh(&acaddr_hash_lock);
 	hlist_add_head_rcu(&aca->aca_addr_lst, &inet6_acaddr_lst[hash]);
-	spin_unlock(&acaddr_hash_lock);
+	spin_unlock_bh(&acaddr_hash_lock);
 }
 
 static void ipv6_del_acaddr_hash(struct ifacaddr6 *aca)
 {
-	spin_lock(&acaddr_hash_lock);
+	spin_lock_bh(&acaddr_hash_lock);
 	hlist_del_init_rcu(&aca->aca_addr_lst);
-	spin_unlock(&acaddr_hash_lock);
+	spin_unlock_bh(&acaddr_hash_lock);
 }
 
 static void aca_get(struct ifacaddr6 *aca)
@@ -371,10 +371,10 @@ int __ipv6_dev_ac_inc(struct inet6_dev *idev, const struct in6_addr *addr)
 	aca->aca_next = idev->ac_list;
 	rcu_assign_pointer(idev->ac_list, aca);
 
-	write_unlock_bh(&idev->lock);
-
 	ipv6_add_acaddr_hash(net, aca);
 
+	write_unlock_bh(&idev->lock);
+
 	ip6_ins_rt(net, f6i);
 
 	addrconf_join_solict(idev->dev, &aca->aca_addr);
@@ -649,8 +649,8 @@ void ipv6_anycast_cleanup(void)
 {
 	int i;
 
-	spin_lock(&acaddr_hash_lock);
+	spin_lock_bh(&acaddr_hash_lock);
 	for (i = 0; i < IN6_ADDR_HSIZE; i++)
 		WARN_ON(!hlist_empty(&inet6_acaddr_lst[i]));
-	spin_unlock(&acaddr_hash_lock);
+	spin_unlock_bh(&acaddr_hash_lock);
 }
-- 
2.43.0

Re: [PATCH net v2] ipv6: anycast: insert aca into global hash under idev->lock

[Jakub Kicinski]

On Fri, 29 May 2026 23:22:18 +0800 Jiayuan Chen wrote:
> syzbot reported a splat [1]: a slab-use-after-free in
> ipv6_chk_acast_addr(), which walks the global inet6_acaddr_lst[] hash
> under RCU and dereferences a struct ifacaddr6 that has already been
> freed while still linked in the hash, so a later reader walks into a
> dangling node.

Please do not violate the 24h repost grace period on netdev.
We are tracking the violations now, if you keep doing this 
there will be consequences..

Re: [PATCH net v2] ipv6: anycast: insert aca into global hash under idev->lock

[Jiayuan Chen]

On 5/30/26 4:51 AM, Jakub Kicinski wrote:
> On Fri, 29 May 2026 23:22:18 +0800 Jiayuan Chen wrote:
>> syzbot reported a splat [1]: a slab-use-after-free in
>> ipv6_chk_acast_addr(), which walks the global inet6_acaddr_lst[] hash
>> under RCU and dereferences a struct ifacaddr6 that has already been
>> freed while still linked in the hash, so a later reader walks into a
>> dangling node.
> Please do not violate the 24h repost grace period on netdev.
> We are tracking the violations now, if you keep doing this
> there will be consequences..


Oops, sorry about that. I slept on it and somehow got confused about the 
timing.

I will make sure to wait for the full 24 hours next time.

Re: [PATCH net v2] ipv6: anycast: insert aca into global hash under idev->lock

[Ido Schimmel]

On Fri, May 29, 2026 at 11:22:18PM +0800, Jiayuan Chen wrote:
> syzbot reported a splat [1]: a slab-use-after-free in
> ipv6_chk_acast_addr(), which walks the global inet6_acaddr_lst[] hash
> under RCU and dereferences a struct ifacaddr6 that has already been
> freed while still linked in the hash, so a later reader walks into a
> dangling node.
> 
> In __ipv6_dev_ac_inc() the aca is allocated with refcount 1, then
> aca_get() bumps it to 2 to keep it alive across the unlocked region.
> It is published to idev->ac_list under idev->lock, but
> ipv6_add_acaddr_hash() runs after write_unlock_bh(). A concurrent
> teardown (ipv6_ac_destroy_dev() from addrconf_ifdown(), under RTNL)
> can slip into that window:
> 
>   CPU0 __ipv6_dev_ac_inc           CPU1 ipv6_ac_destroy_dev (RTNL)
>   ------------------------------   ------------------------------------
>   aca_alloc()              refcnt 1
>   aca_get()               refcnt 2
>   write_lock_bh(idev->lock)
>     add aca to ac_list
>   write_unlock_bh(idev->lock)
>                                    write_lock_bh(idev->lock)
>                                      pull aca off ac_list
>                                    write_unlock_bh(idev->lock)
>                                    ipv6_del_acaddr_hash(aca)
>                                      hlist_del_init_rcu() is a no-op,
>                                      aca is not in the hash yet
>                                    aca_put()           refcnt 2->1
>   ipv6_add_acaddr_hash(aca)
>     aca now inserted into the hash
>   aca_put()                refcnt 1->0
>     call_rcu(aca_free_rcu) -> kfree(aca)
> 
> The hash removal becomes a no-op because the insertion has not
> happened yet, so once CPU0 inserts and drops the last reference, the
> aca is freed while still linked in inet6_acaddr_lst[], and readers
> dereference freed memory after the slab slot is reused.
> 
> This window opened once RTNL stopped serializing the join path against
> device teardown. Move ipv6_add_acaddr_hash() inside the idev->lock
> section so the ac_list and hash insertions are atomic with respect to
> teardown: a racing remover now either misses the aca entirely or finds
> it in both lists.
> 
> acaddr_hash_lock is now nested under idev->lock, which is acquired in
> softirq context, so switch all acaddr_hash_lock sites to spin_lock_bh()
> to avoid the irq lock inversion reported in [2].
> 
> [1] https://syzkaller.appspot.com/bug?extid=a01df04303c131efbf3a
> [2] https://lore.kernel.org/netdev/6a194ef7.ba3b1513.1890b4.0000.GAE@google.com/
> 
> Reported-by: syzbot+819eb928d120d2bdad0e@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/6a191f87.ce022c6e.138e56.0003.GAE@google.com/T/
> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
> Fixes: eb1ac9ff6c4a ("ipv6: anycast: Don't hold RTNL for IPV6_JOIN_ANYCAST.")
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>

Reviewed-by: Ido Schimmel <idosch@nvidia.com>

There's a comment from Sashiko about UAF / leak with regards to the
associated route, but I don't think it can happen:

"
This is a pre-existing issue, but could a race condition here cause a
use-after-free of the fib6_info object and leak the net_device?

Since ip6_ins_rt() is called after dropping the idev->lock, what happens if
a concurrent device teardown via ipv6_ac_destroy_dev() intervenes?

If ipv6_ac_destroy_dev() acquires the lock right after it is dropped here,
it would find the newly published aca in idev->ac_list, unlink it, and call
ip6_del_rt().

Since the route isn't inserted yet, ip6_del_rt() fails to remove it but
still calls fib6_info_release(), dropping the refcount of f6i to zero.
When this thread resumes, would ip6_ins_rt() then insert the 0-refcount
route into the FIB tree?
"

I don't believe the reference count drops to 0 since the address is
still alive and aca_alloc() acquires a reference on the route via
fib6_info_hold().

"
Since device unregistration has already flushed all routes, it appears this
orphaned route is never removed. Would this cause unregister_netdevice()
to hang indefinitely due to the held net_device reference?

Could ip6_ins_rt() be moved inside the idev->lock critical section to
prevent this race?
"

The kernel will emit NETDEV_UNREGISTER until the netdev reference count
drops to 1 and the route will be cleaned via addrconf_notify() ->
addrconf_ifdown() -> rt6_disable_ip()

Racing addrconf_{join,leave}_solict() also seems fine since
__ipv6_dev_mc_inc() will be a NOP due to the in6_dev_get() check.