Look up another CVE · open CVE-2026-64580 in the interactive tracker
CVE-2026-64580
xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst()
Published 2026-08-05 (2 months ago) by the Linux kernel CNA. Subsystem net/ipv6. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-64580 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4777-1 · 2026-09-08 · text | 6.1.187-1 | Update the kernel and reboot. DLA-4777-1 shipped the fix on 2026-09-08, in 6.1.187-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6415-1 · 2026-08-06 · text | 6.12.101-1 | Update the kernel and reboot. DSA-6415-1 shipped the fix on 2026-08-06, in 6.12.101-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.6-1 | Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.6-1 | Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4745-1 · 2026-08-18 · text | 6.12.101-1~deb12u1 | Update the kernel and reboot. DLA-4745-1 shipped the fix on 2026-08-18, in 6.12.101-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst() releases the device reference with netdev_put() but leaves xdst->u.dst.dev set. dst_destroy() later calls netdev_put(dst->dev) again, so the same net_device reference is released twice, underflowing its refcount (ref_tracker WARNING + "unregister_netdevice: waiting for <dev> to become free"). Clear xdst->u.dst.dev after the netdev_put(), the same way the XFRM device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in net/xfrm/xfrm_device.c NULL ->dev when releasing the reference on error. ref_tracker: reference already released. ref_tracker: allocated in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86) ... udpv6_sendmsg (net/ipv6/udp.c:1696) ... ref_tracker: freed in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90) ... WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780 dst_destroy (net/core/dst.c:115) rcu_core handle_softirqs ...
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/ipv6/xfrm6_policy.c
- What this is
- NETWORKING [IPSEC]MAINTAINERS section matched on net/ipv6/xfrm* · netdev@vger.kernel.org · Maintained
Check it on the machine
grep -wE 'CONFIG_IPV6|CONFIG_XFRM' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sid, bookworm · linux-6.12y
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switches
- CONFIG_IPV6, CONFIG_XFRM
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-05 (2 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.12%, higher than 1.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/ipv6
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 3.10 | 6.1.183 | 97e032e5733e |
| 3.10 | 6.6.148 | df6856c2dda9 |
| 3.10 | 6.12.101 | 43de8a49335e |
| 3.10 | 6.18.42 | ff636d7b7cba |
| 3.10 | 7.1.6 | e078da1b4e11 |
| 3.10 | 7.2 | 136992de9bb9 |
| 3.0.79 | 0 | 0 |
| 3.2.46 | 0 | 0 |
| 3.4.46 | 0 | 0 |
| 3.9.3 | 0 | 0 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4777-1 | 2026-09-08 | bookworm 6.1.187-1 | tracker |
| DLA-4745-1 | 2026-08-18 | bookworm 6.12.101-1~deb12u1 | tracker |
| DSA-6415-1 | 2026-08-06 | trixie 6.12.101-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The bug is reached on the local IPv6 outbound path (udpv6_sendmsg → xfrm_lookup → xfrm6_fill_dst) after configuring XFRM policy/state via netlink or IPV6_XFRM_POLICY; a remote peer cannot drive that configuration or the device state that makes in6_dev_get fail.
- AC:LAttack complexity, low
- An attacker in their own netns can create interfaces, install IPv6 XFRM policy/state, generate matching UDP traffic, and concurrently drop MTU below IPV6_MIN_MTU or unregister the device to clear ip6_ptr, so they control both sides of the window that hits the error path; once entered, the double netdev_put is deterministic.
- PR:LPrivileges required, low
- XFRM configuration requires CAP_NET_ADMIN via netlink_net_capable/sockopt_ns_capable, which is ns_capable() in the netns user_ns, so an unprivileged user obtains it with unshare -Urn rather than real init-namespace root.
- UI:NUser interaction, none
- No victim action is required; the attacker configures XFRM, manipulates their own netdevs, and sends packets entirely with their own processes.
- S:UScope, unchanged
- The impact is kernel net_device refcount corruption within the same host kernel authority; this is ordinary local privilege-escalation/DoS territory, not a VM escape or IOMMU/sandbox boundary cross.
- C:HConfidentiality impact, high
- The leftover dst.dev causes a second netdev_put in dst_destroy, underflowing the net_device refcount and enabling use-after-free of the device object, which per kernel UAF guidance yields a high confidentiality/info-disclosure primitive.
- I:HIntegrity impact, high
- A net_device refcount underflow/UAF is heap memory corruption that can be shaped via reuse/spraying into arbitrary write or control-flow hijack, so integrity impact is high.
- A:HAvailability impact, high
- Even without full exploitation, the double put triggers ref_tracker warnings and can oops/panic or hang device unregister (unregister_netdevice waiting for the device to become free), so availability impact is high.