Skip to main content
VulnerabilityPublished Updated

CVE-2026-23209: Linux kernel · macvlan: fix error recovery in macvlan_common_newlink()

Affects Linux kernelSource GCVE Database

0
Authoritative record:CVE-2026-23209· High 7.8

Not known to be exploited · CVSS 7.8 High · fixed in 4.15.0-1200.215~14.04.1 : patch Linux kernel soon.

Data as of 26 Oct 2026, 11:07 UTC

CVSS 3.1 base score
7.8High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.1% chance of exploitation in 30 days – higher than 7% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 4.15.0-1200.215~14.04.1, 4.15.0-1191.204~16.04.1, 4.15.0-1200.215~16.04.1 +114
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 14 Feb 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
Ubuntu 25.10linuxpkg:deb/ubuntu/linux?arch=source&distro=questingOther threatsAffected
  • <6.17.0-22.22
Fixed in
  • 6.17.0-22.22
Ubuntu 25.10linux-awspkg:deb/ubuntu/linux-aws?arch=source&distro=questingOther threatsAffected
  • <6.17.0-1012.12
Fixed in
  • 6.17.0-1012.12
Ubuntu 25.10linux-azurepkg:deb/ubuntu/linux-azure?arch=source&distro=questingOther threatsAffected
  • <6.17.0-1013.13
Fixed in
  • 6.17.0-1013.13
Ubuntu 25.10linux-azure-fdepkg:deb/ubuntu/linux-azure-fde?arch=source&distro=questingOther threatsAffected
  • 6.17.0-1003.3 – 6.17.0-1017.17
10 affected builds
Fixed in–
Ubuntu 25.10linux-gcppkg:deb/ubuntu/linux-gcp?arch=source&distro=questingOther threatsAffected
  • <6.17.0-1012.12
Fixed in
  • 6.17.0-1012.12
Ubuntu 25.10linux-oraclepkg:deb/ubuntu/linux-oracle?arch=source&distro=questingOther threatsAffected
  • <6.17.0-1011.11
Fixed in
  • 6.17.0-1011.11

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

Description

In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: <quote valis> The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, &params, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source(). </quote valis> With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever "goto destroy_macvlan_port;" path is taken. Many thanks to valis for following up on this issue.

References

Community reviews

Loading reviews…