GHSA-hqjh-c323-5jv8 · 深刻度： unknown — In the Linux kernel, the following vulnerability has been resolved: ipv6: anycast: insert aca...
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]. [1] https://syzkaller.appspot.com/bug?extid=a01df04303c131efbf3a [2] https://lore.kernel.org/netdev/[email protected]/
総合評価: CVE-2026-53259 は低リスク（5.7/100）。悪用される可能性が高い（EPSS 0.16%、6 パーセンタイル） 推奨対応: 総合リスクは低く緊急対応は不要です。通常の保守サイクルでパッチを適用し、CVSS / EPSS が上昇したら優先度を見直してください。
リスクは変動します。再評価に基づき、本ページの表示内容を更新しています。
EPSS は日次で悪用されやすさの相対度合いを推定します。パーセンタイルは採点済み CVE の中での相対位置（高いほど相対的に深刻）を示します。
| # | 日付 | 旧 EPSS スコア | 新 EPSS スコア | Δ（新 − 旧） |
|---|---|---|---|---|
| 1 | 2026-06-25 | — | 0.16% | — |
EPSS の全履歴 （全 1 件）
この CVE の CVSS 指標。
この CVE のデータセットに CVSS はありません。
GHSA-hqjh-c323-5jv8 · 深刻度： unknown — In the Linux kernel, the following vulnerability has been resolved: ipv6: anycast: insert aca...
| vendor | priority | summary | link |
|---|---|---|---|
debian
|
unimportant | CVE-2026-53259 unimportant priority: Debian including 1 source packages (linux), 5 status rows across 5 suites (bookworm, bullseye, forky, sid, trixie): resolved 4, open 1. | https://security-tracker.debian.org/tracker/CVE-2026-53259 |
redhat
|
medium | — | https://access.redhat.com/security/cve/CVE-2026-53259 |
| ベンダー | 製品 | バージョン | 生の CPE |
|---|---|---|---|
| linux | linux_kernel | >= 6.17, < 6.18.36 | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
| linux | linux_kernel | >= 6.17, < 7.0.13 | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
| linux | linux_kernel | >= 6.17, < 7.1 | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |