PT-2026-52354 · Linux · Linux
Published
2026-06-25
·
Updated
2026-06-25
·
CVE-2026-53259
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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
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].
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux