FKIE_CVE-2026-23209
Vulnerability from fkie_nvd - Published: 2026-02-14 17:15 - Updated: 2026-02-18 17:52
Severity ?
Summary
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.
References
Impacted products
| Vendor | Product | Version |
|---|
{
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmacvlan: fix error recovery in macvlan_common_newlink()\n\nvalis provided a nice repro to crash the kernel:\n\nip link add p1 type veth peer p2\nip link set address 00:00:00:00:00:20 dev p1\nip link set up dev p1\nip link set up dev p2\n\nip link add mv0 link p2 type macvlan mode source\nip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20\n\nping -c1 -I p1 1.2.3.4\n\nHe also gave a very detailed analysis:\n\n\u003cquote valis\u003e\n\nThe issue is triggered when a new macvlan link is created with\nMACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or\nMACVLAN_MACADDR_SET) parameter, lower device already has a macvlan\nport and register_netdevice() called from macvlan_common_newlink()\nfails (e.g. because of the invalid link name).\n\nIn this case macvlan_hash_add_source is called from\nmacvlan_change_sources() / macvlan_common_newlink():\n\nThis adds a reference to vlan to the port\u0027s vlan_source_hash using\nmacvlan_source_entry.\n\nvlan is a pointer to the priv data of the link that is being created.\n\nWhen register_netdevice() fails, the error is returned from\nmacvlan_newlink() to rtnl_newlink_create():\n\n if (ops-\u003enewlink)\n err = ops-\u003enewlink(dev, \u0026params, extack);\n else\n err = register_netdevice(dev);\n if (err \u003c 0) {\n free_netdev(dev);\n goto out;\n }\n\nand free_netdev() is called, causing a kvfree() on the struct\nnet_device that is still referenced in the source entry attached to\nthe lower device\u0027s macvlan port.\n\nNow all packets sent on the macvlan port with a matching source mac\naddress will trigger a use-after-free in macvlan_forward_source().\n\n\u003c/quote valis\u003e\n\nWith all that, my fix is to make sure we call macvlan_flush_sources()\nregardless of @create value whenever \"goto destroy_macvlan_port;\"\npath is taken.\n\nMany thanks to valis for following up on this issue."
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nmacvlan: arreglar la recuperaci\u00f3n de errores en macvlan_common_newlink()\n\nvalis proporcion\u00f3 una buena reproducci\u00f3n para colapsar el kernel:\n\nip link add p1 type veth peer p2\nip link set address 00:00:00:00:00:20 dev p1\nip link set up dev p1\nip link set up dev p2\n\nip link add mv0 link p2 type macvlan mode source\nip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20\n\nping -c1 -I p1 1.2.3.4\n\nTambi\u00e9n proporcion\u00f3 un an\u00e1lisis muy detallado:\n\n\u0027El problema se activa cuando se crea un nuevo enlace macvlan con el modo MACVLAN_MODE_SOURCE y el par\u00e1metro MACVLAN_MACADDR_ADD (o MACVLAN_MACADDR_SET), el dispositivo inferior ya tiene un puerto macvlan y register_netdevice() llamado desde macvlan_common_newlink() falla (por ejemplo, debido al nombre de enlace no v\u00e1lido).\n\nEn este caso, macvlan_hash_add_source es llamado desde macvlan_change_sources() / macvlan_common_newlink():\n\nEsto a\u00f1ade una referencia a vlan al vlan_source_hash del puerto usando macvlan_source_entry.\n\nvlan es un puntero a los datos privados del enlace que se est\u00e1 creando.\n\nCuando register_netdevice() falla, el error es devuelto desde macvlan_newlink() a rtnl_newlink_create():\n\n if (ops-\u0026gt;newlink)\n err = ops-\u0026gt;newlink(dev, \u0026amp;params, extack);\n else\n err = register_netdevice(dev);\n if (err \u0026lt; 0) {\n free_netdev(dev);\n goto out;\n }\n\ny se llama a free_netdev(), causando un kvfree() en la estructura net_device que todav\u00eda est\u00e1 referenciada en la entrada de origen adjunta al puerto macvlan del dispositivo inferior.\n\nAhora, todos los paquetes enviados en el puerto macvlan con una direcci\u00f3n MAC de origen coincidente activar\u00e1n un uso despu\u00e9s de liberaci\u00f3n en macvlan_forward_source().\u0027\n\nCon todo eso, mi soluci\u00f3n es asegurarme de que llamamos a macvlan_flush_sources() independientemente del valor de @create cada vez que se toma la ruta \"goto destroy_macvlan_port;\".\n\nMuchas gracias a valis por hacer seguimiento de este problema."
}
],
"id": "CVE-2026-23209",
"lastModified": "2026-02-18T17:52:22.253",
"metrics": {},
"published": "2026-02-14T17:15:58.803",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/11ba9f0dc865136174cb98834280fb21bbc950c7"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/5dae6b36a7cb7a4fcf4121b95e9ca7f96f816c8a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/986967a162142710076782d5b93daab93a892980"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/c43d0e787cbba569ec9d11579ed370b50fab6c9c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/cdedcd5aa3f3cb8b7ae0f87ab3a936d0bd583d66"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/da5c6b8ae47e414be47e5e04def15b25d5c962dc"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/f8db6475a83649689c087a8f52486fcc53e627e9"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…