CVE-2026-53259

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: anycast: insert aca into global hash under idev-&gt;lock<br /> <br /> syzbot reported a splat [1]: a slab-use-after-free in<br /> ipv6_chk_acast_addr(), which walks the global inet6_acaddr_lst[] hash<br /> under RCU and dereferences a struct ifacaddr6 that has already been<br /> freed while still linked in the hash, so a later reader walks into a<br /> dangling node.<br /> <br /> In __ipv6_dev_ac_inc() the aca is allocated with refcount 1, then<br /> aca_get() bumps it to 2 to keep it alive across the unlocked region.<br /> It is published to idev-&gt;ac_list under idev-&gt;lock, but<br /> ipv6_add_acaddr_hash() runs after write_unlock_bh(). A concurrent<br /> teardown (ipv6_ac_destroy_dev() from addrconf_ifdown(), under RTNL)<br /> can slip into that window:<br /> <br /> CPU0 __ipv6_dev_ac_inc CPU1 ipv6_ac_destroy_dev (RTNL)<br /> ------------------------------ ------------------------------------<br /> aca_alloc() refcnt 1<br /> aca_get() refcnt 2<br /> write_lock_bh(idev-&gt;lock)<br /> add aca to ac_list<br /> write_unlock_bh(idev-&gt;lock)<br /> write_lock_bh(idev-&gt;lock)<br /> pull aca off ac_list<br /> write_unlock_bh(idev-&gt;lock)<br /> ipv6_del_acaddr_hash(aca)<br /> hlist_del_init_rcu() is a no-op,<br /> aca is not in the hash yet<br /> aca_put() refcnt 2-&gt;1<br /> ipv6_add_acaddr_hash(aca)<br /> aca now inserted into the hash<br /> aca_put() refcnt 1-&gt;0<br /> call_rcu(aca_free_rcu) -&gt; kfree(aca)<br /> <br /> The hash removal becomes a no-op because the insertion has not<br /> happened yet, so once CPU0 inserts and drops the last reference, the<br /> aca is freed while still linked in inet6_acaddr_lst[], and readers<br /> dereference freed memory after the slab slot is reused.<br /> <br /> This window opened once RTNL stopped serializing the join path against<br /> device teardown. Move ipv6_add_acaddr_hash() inside the idev-&gt;lock<br /> section so the ac_list and hash insertions are atomic with respect to<br /> teardown: a racing remover now either misses the aca entirely or finds<br /> it in both lists.<br /> <br /> acaddr_hash_lock is now nested under idev-&gt;lock, which is acquired in<br /> softirq context, so switch all acaddr_hash_lock sites to spin_lock_bh()<br /> to avoid the irq lock inversion reported in [2].<br /> <br /> [1] https://syzkaller.appspot.com/bug?extid=a01df04303c131efbf3a<br /> [2] https://lore.kernel.org/netdev/6a194ef7.ba3b1513.1890b4.0000.GAE@google.com/