[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2026021439-CVE-2026-23209-9ad6@gregkh>
Date: Sat, 14 Feb 2026 17:29:06 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2026-23209: macvlan: fix error recovery in macvlan_common_newlink()
From: Greg Kroah-Hartman <gregkh@...nel.org>
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, ¶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.
The Linux kernel CVE team has assigned CVE-2026-23209 to this issue.
Affected and fixed versions
===========================
Issue introduced in 4.9 with commit aa5fd0fb77486b8a6764ead8627baa14790e4280 and fixed in 5.10.250 with commit da5c6b8ae47e414be47e5e04def15b25d5c962dc
Issue introduced in 4.9 with commit aa5fd0fb77486b8a6764ead8627baa14790e4280 and fixed in 5.15.200 with commit 5dae6b36a7cb7a4fcf4121b95e9ca7f96f816c8a
Issue introduced in 4.9 with commit aa5fd0fb77486b8a6764ead8627baa14790e4280 and fixed in 6.1.163 with commit c43d0e787cbba569ec9d11579ed370b50fab6c9c
Issue introduced in 4.9 with commit aa5fd0fb77486b8a6764ead8627baa14790e4280 and fixed in 6.6.124 with commit 11ba9f0dc865136174cb98834280fb21bbc950c7
Issue introduced in 4.9 with commit aa5fd0fb77486b8a6764ead8627baa14790e4280 and fixed in 6.12.70 with commit 986967a162142710076782d5b93daab93a892980
Issue introduced in 4.9 with commit aa5fd0fb77486b8a6764ead8627baa14790e4280 and fixed in 6.18.10 with commit cdedcd5aa3f3cb8b7ae0f87ab3a936d0bd583d66
Issue introduced in 4.9 with commit aa5fd0fb77486b8a6764ead8627baa14790e4280 and fixed in 6.19 with commit f8db6475a83649689c087a8f52486fcc53e627e9
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2026-23209
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
drivers/net/macvlan.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/da5c6b8ae47e414be47e5e04def15b25d5c962dc
https://git.kernel.org/stable/c/5dae6b36a7cb7a4fcf4121b95e9ca7f96f816c8a
https://git.kernel.org/stable/c/c43d0e787cbba569ec9d11579ed370b50fab6c9c
https://git.kernel.org/stable/c/11ba9f0dc865136174cb98834280fb21bbc950c7
https://git.kernel.org/stable/c/986967a162142710076782d5b93daab93a892980
https://git.kernel.org/stable/c/cdedcd5aa3f3cb8b7ae0f87ab3a936d0bd583d66
https://git.kernel.org/stable/c/f8db6475a83649689c087a8f52486fcc53e627e9
Powered by blists - more mailing lists