CVE-2026-53259 | ipv6: anycast: insert aca into global hash under idev->lock

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]/

Published: 2026-06-25 Last update: 2026-06-30 Assigner: 416baaa9-dc9f-4396-8d5f-8c081fb06d67 Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
NVD Status：Awaiting Analysis，CVE State: published
View at NVD, CVE.org, EUVD

CVE-2026-53259 is rated Low Risk (32/100): CVSS High severity, with low exploitation likelihood (EPSS 0.12%). Monitor for updates and reassess as exploit intelligence or EPSS changes.

Risk is dynamic; we continuously reassess and refresh what is shown on this page as upstream context changes.

Exploit prediction scoring system (EPSS) score for CVE-2026-53259

EPSS lead: Daily EPSS estimates relative likelihood of exploitation; percentile ranks this CVE among scored vulnerabilities (higher = more severe relative rank).

# Date Old EPSS score New EPSS score Delta (New - Old)
1 2026-06-28 0.16% 0.12% -0.04%
2 2026-06-25 — 0.16% —

Full EPSS history (2 records total)

Common vulnerability scoring system (CVSS) metrics for CVE-2026-53259

CVSS metrics for this CVE.

Base score Version Severity Vector Exploitability Impact Score source
7.8 3.1 HIGH
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H Click to expand
Attack vector (AV:L)
They already need access on the box, or another person has to do something wrong; it’s not a remote drive-by.
Attack complexity (AC:L)
Once they can reach the bug, pulling it off is straightforward—no weird race conditions or rare setup.
Privileges required (PR:L)
A normal user session is enough; they don’t have to be admin.
User interaction (UI:N)
Nobody has to click “OK” or open a trap file; it can work without a victim helping.
Scope (S:U)
Damage stays in the same “trust bubble” as the broken component—no big spill into unrelated systems.
Confidentiality (C:H)
Serious risk that confidential data gets exposed in a big way.
Integrity (I:H)
They could widely tamper with or forge data—trust in the data is badly hurt.
Availability (A:H)
Could take the service down hard or make it unusable for people who depend on it.
 1.8 5.9 416baaa9-dc9f-4396-8d5f-8c081fb06d67

Weakness enumeration for CVE-2026-53259

GitHub Security Advisory for CVE-2026-53259

GHSA-hqjh-c323-5jv8 · Severity: high — In the Linux kernel, the following vulnerability has been resolved: ipv6: anycast: insert aca...

OS Trackers for CVE-2026-53259

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 5. https://security-tracker.debian.org/tracker/CVE-2026-53259
redhat medium — https://access.redhat.com/security/cve/CVE-2026-53259
suse medium CVE-2026-53259 severity moderate: SUSE including 21 source package names (cluster-md-kmp-default, dlm-kmp-default, …), 199 product×package rows across 40 product lines (SUSE Linux Enterprise High Availability Extension 15 SP7, SUSE Linux Enterprise High Performance Computing 15 SP4-LTSS, … (40 product lines)): Known Not Affected 199. https://www.suse.com/security/cve/CVE-2026-53259/
ubuntu high CVE-2026-53259 high priority: Ubuntu including 161 source packages (linux, linux-allwinner-5.19, …), 1449 status rows across 9 suites (bionic, focal, jammy, noble, questing, resolute, trusty, upstream, xenial): DNE 1044, ignored 172, not-affected 112, released 87, needed 33, needs-triage 1. https://ubuntu.com/security/CVE-2026-53259

Affected software / configurations for CVE-2026-53259

Vendor Product Version Raw 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:*:*:*:*:*:*:*:*

References for CVE-2026-53259

cvelogic Threat Intelligence