CVE-2026-23209
Published: 14 February 2026
Summary
CVE-2026-23209 is a high-severity Use After Free (CWE-416) vulnerability in Linux Linux Kernel. Its CVSS base score is 7.8 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked at the 4.7th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified are NIST 800-53 CM-7 (Least Functionality) and SI-2 (Flaw Remediation).
Deeper analysis
CVE-2026-23209 is a use-after-free vulnerability in the Linux kernel's macvlan driver, specifically in the error recovery path of the macvlan_common_newlink() function. The issue arises when creating a new macvlan link in MACVLAN_MODE_SOURCE mode with the MACVLAN_MACADDR_ADD or MACVLAN_MACADDR_SET parameter, where the lower device already has a macvlan port and register_netdevice() fails, such as due to an invalid link name. This leaves a reference to the freed net_device structure in the lower device's vlan_source_hash, leading to a use-after-free when packets with a matching source MAC address are processed in macvlan_forward_source(). The vulnerability is classified under CWE-416 with a CVSS v3.1 base score of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
A local attacker with low privileges can exploit this vulnerability by performing specific network interface operations, such as creating a veth pair (e.g., p1 and p2), setting a specific MAC address on one peer, bringing both interfaces up, then attempting to add a macvlan link (e.g., mv0) in source mode followed by another with an invalid name (e.g., invalid%) and the MACVLAN_MACADDR_ADD parameter using the same MAC address. When register_netdevice() fails, free_netdev() is called, but the reference persists in the hash table. Sending packets (e.g., ping) on the macvlan port with the matching source MAC then triggers the use-after-free, potentially allowing kernel crashes, denial of service, or arbitrary code execution with high confidentiality, integrity, and availability impacts.
Kernel patches addressing this issue are available in stable repositories, including commits such as 11ba9f0dc865136174cb98834280fb21bbc950c7, 5dae6b36a7cb7a4fcf4121b95e9ca7f96f816c8a, 986967a162142710076782d5b93daab93a892980, c43d0e787cbba569ec9d11579ed370b50fab6c9c, and cdedcd5aa3f3cb8b7ae0f87ab3a936d0bd583d66. The fix ensures macvlan_flush_sources() is called regardless of the @create value whenever the "goto destroy_macvlan_port;" path is taken, properly cleaning up the source hash entries during error recovery. Security practitioners should update to kernels incorporating these patches.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-5839
Vulnerability details
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…
more
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, ¶ms, 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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise TechniquesAI
Why these techniques?
Local low-priv UAF in kernel macvlan driver directly enables exploitation for privilege escalation to achieve arbitrary code execution.
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
SI-2 requires timely remediation of known flaws like CVE-2026-23209 by applying the specific kernel patches that fix the use-after-free in macvlan error recovery.
CM-7 mandates configuring systems to provide only essential capabilities, such as disabling the macvlan kernel module if not required, eliminating the vulnerable interface creation path.
SI-16 implements memory protections like KASLR and SMAP that mitigate exploitation of the use-after-free in macvlan by randomizing addresses and preventing arbitrary execution.