CVE-2026-23209

Advisory lineage Upstream: 0 Downstream: 180
Modified
Published: 14 Feb 2026, 16:27
Last modified:11 May 2026, 22:02

Vulnerability Summary

Overall Risk (default)
medium
31/100
CVSS Score
7.8 HIGH
v3.1 (nvd)
EPSS Score
0.02% LOW
0% probability 0.00%
KEV
Not listed
Ransomware
No reports
Public exploits
None found
Dark Web
Not detected

Timeline

14 Feb 2026, 16:27
Published
Vulnerability first disclosed
11 May 2026, 22:02
Last Modified
Vulnerability information updated

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.

CVSS Metrics

  • v3.1•HIGH•Score: 7.8CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

EPSS Trends

Current EPSS score: 0.02%• Percentile: 5%

Techniques & Countermeasures

  • CWE-416•Use After Free

    The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.

Affected Systems

  • linux•linux

    ≥ aa5fd0fb77486b8a6764ead8627baa14790e4280, < da5c6b8ae47e414be47e5e04def15b25d5c962dc | ≥ aa5fd0fb77486b8a6764ead8627baa14790e4280, < 5dae6b36a7cb7a4fcf4121b95e9ca7f96f816c8a | ≥ aa5fd0fb77486b8a6764ead8627baa14790e4280, < c43d0e787cbba569ec9d11579ed370b50fab6c9c | ≥ aa5fd0fb77486b8a6764ead8627baa14790e4280, < 11ba9f0dc865136174cb98834280fb21bbc950c7 | ≥ aa5fd0fb77486b8a6764ead8627baa14790e4280, < 986967a162142710076782d5b93daab93a892980 | ≥ aa5fd0fb77486b8a6764ead8627baa14790e4280, < cdedcd5aa3f3cb8b7ae0f87ab3a936d0bd583d66 | ≥ aa5fd0fb77486b8a6764ead8627baa14790e4280, < f8db6475a83649689c087a8f52486fcc53e627e9 | 4.9

  • linux•linux_kernel

    ≥ 4.9.1, < 5.10.250 | ≥ 5.11, < 5.15.200 | ≥ 5.16, < 6.1.163 | ≥ 6.2, < 6.6.124 | ≥ 6.7, < 6.12.70 | ≥ 6.13, < 6.18.10 | 4.9 | 4.9:rc6 | 4.9:rc7 | 4.9:rc8 | 6.19:rc1 | 6.19:rc2 | 6.19:rc3 | 6.19:rc4 | 6.19:rc5 | 6.19:rc6 | 6.19:rc7 | 6.19:rc8

References (7)