1. Home
  2. Vulnerabilities
  3. CVE-2026-23209
0.0
NA
CVE-2026-23209
macvlan: fix error recovery in macvlan_common_newlink()
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.

INFO

Published Date :

Feb. 14, 2026, 5:15 p.m.

Last Modified :

Feb. 14, 2026, 5:15 p.m.

Remotely Exploit :

No

Source :

416baaa9-dc9f-4396-8d5f-8c081fb06d67
Affected Products

The following products are affected by CVE-2026-23209 vulnerability. Even if cvefeed.io is aware of the exact versions of the products that are affected, the information is not represented in the table below.

ID Vendor Product Action
1 Linux linux_kernel
: Total Affected Vendor : 1 | Products : 1
Solution
Apply the Linux kernel patch to fix a use-after-free vulnerability in macvlan module.
  • Update the Linux kernel to the patched version.
  • Verify the integrity of the kernel installation.
  • Reboot the system after the update.
  • Monitor system stability post-remediation.
References to Advisories, Solutions, and Tools

Here, you will find a curated list of external links that provide in-depth information, practical solutions, and valuable tools related to CVE-2026-23209.

URL Resource
https://git.kernel.org/stable/c/11ba9f0dc865136174cb98834280fb21bbc950c7
https://git.kernel.org/stable/c/5dae6b36a7cb7a4fcf4121b95e9ca7f96f816c8a
https://git.kernel.org/stable/c/986967a162142710076782d5b93daab93a892980
https://git.kernel.org/stable/c/c43d0e787cbba569ec9d11579ed370b50fab6c9c
https://git.kernel.org/stable/c/cdedcd5aa3f3cb8b7ae0f87ab3a936d0bd583d66
https://git.kernel.org/stable/c/da5c6b8ae47e414be47e5e04def15b25d5c962dc
https://git.kernel.org/stable/c/f8db6475a83649689c087a8f52486fcc53e627e9
CWE - Common Weakness Enumeration

While CVE identifies specific instances of vulnerabilities, CWE categorizes the common flaws or weaknesses that can lead to vulnerabilities. CVE-2026-23209 is associated with the following CWEs:

Common Attack Pattern Enumeration and Classification (CAPEC)

Common Attack Pattern Enumeration and Classification (CAPEC) stores attack patterns, which are descriptions of the common attributes and approaches employed by adversaries to exploit the CVE-2026-23209 weaknesses.

We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).

Results are limited to the first 15 repositories due to potential performance issues.

The following list is the news that have been mention CVE-2026-23209 vulnerability anywhere in the article.

Results are limited to the first 20 news articles due to potential performance issues.

The following table lists the changes that have been made to the CVE-2026-23209 vulnerability over time.

Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.

  • New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

    Feb. 14, 2026

    Action Type Old Value New Value
    Added 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.
    Added Reference https://git.kernel.org/stable/c/11ba9f0dc865136174cb98834280fb21bbc950c7
    Added Reference https://git.kernel.org/stable/c/5dae6b36a7cb7a4fcf4121b95e9ca7f96f816c8a
    Added Reference https://git.kernel.org/stable/c/986967a162142710076782d5b93daab93a892980
    Added Reference https://git.kernel.org/stable/c/c43d0e787cbba569ec9d11579ed370b50fab6c9c
    Added Reference https://git.kernel.org/stable/c/cdedcd5aa3f3cb8b7ae0f87ab3a936d0bd583d66
    Added Reference https://git.kernel.org/stable/c/da5c6b8ae47e414be47e5e04def15b25d5c962dc
    Added Reference https://git.kernel.org/stable/c/f8db6475a83649689c087a8f52486fcc53e627e9
EPSS is a daily estimate of the probability of exploitation activity being observed over the next 30 days. Following chart shows the EPSS score history of the vulnerability.
Vulnerability Scoring Details
No CVSS metrics available for this vulnerability.