CVE-2026-53259

In the Linux kernel, the following vulnerability has been resolved:

ipv6: anycast: insert aca into global hash under idev->lock

syzbot reported a splat [1]: a slab-use-after-free in ipv6chkacastaddr(), which walks the global inet6acaddr_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 __ipv6devacinc() the aca is allocated with refcount 1, then acaget() bumps it to 2 to keep it alive across the unlocked region. It is published to idev->aclist under idev->lock, but ipv6addacaddrhash() runs after writeunlockbh(). A concurrent teardown (ipv6acdestroydev() from addrconfifdown(), under RTNL) can slip into that window:

CPU0 __ipv6devacinc CPU1 ipv6acdestroydev (RTNL) ------------------------------ ------------------------------------ acaalloc() refcnt 1 acaget() refcnt 2 writelockbh(idev->lock) add aca to aclist writeunlockbh(idev->lock) writelockbh(idev->lock) pull aca off aclist writeunlockbh(idev->lock) ipv6delacaddrhash(aca) hlistdelinitrcu() is a no-op, aca is not in the hash yet acaput() refcnt 2->1 ipv6addacaddrhash(aca) aca now inserted into the hash acaput() refcnt 1->0 callrcu(acafreercu) -> 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 inet6acaddrlst[], 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 ipv6addacaddrhash() inside the idev->lock section so the aclist and hash insertions are atomic with respect to teardown: a racing remover now either misses the aca entirely or finds it in both lists.

acaddrhashlock is now nested under idev->lock, which is acquired in softirq context, so switch all acaddrhashlock sites to spinlockbh() 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/