Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

Vulnerabilidad en Linux (CVE-2026-23209)

Gravedad:
Pendiente de análisis
Tipo:
No Disponible / Otro tipo
Fecha de publicación:
14/02/2026
Última modificación:
18/02/2026

Descripción

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> macvlan: arreglar la recuperación de errores en macvlan_common_newlink()<br /> <br /> valis proporcionó una buena reproducción para colapsar el kernel:<br /> <br /> ip link add p1 type veth peer p2<br /> ip link set address 00:00:00:00:00:20 dev p1<br /> ip link set up dev p1<br /> ip link set up dev p2<br /> <br /> ip link add mv0 link p2 type macvlan mode source<br /> ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20<br /> <br /> ping -c1 -I p1 1.2.3.4<br /> <br /> También proporcionó un análisis muy detallado:<br /> <br /> &amp;#39;El problema se activa cuando se crea un nuevo enlace macvlan con el modo MACVLAN_MODE_SOURCE y el parámetro 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álido).<br /> <br /> En este caso, macvlan_hash_add_source es llamado desde macvlan_change_sources() / macvlan_common_newlink():<br /> <br /> Esto añade una referencia a vlan al vlan_source_hash del puerto usando macvlan_source_entry.<br /> <br /> vlan es un puntero a los datos privados del enlace que se está creando.<br /> <br /> Cuando register_netdevice() falla, el error es devuelto desde macvlan_newlink() a rtnl_newlink_create():<br /> <br /> if (ops-&amp;gt;newlink)<br /> err = ops-&amp;gt;newlink(dev, &amp;amp;params, extack);<br /> else<br /> err = register_netdevice(dev);<br /> if (err &amp;lt; 0) {<br /> free_netdev(dev);<br /> goto out;<br /> }<br /> <br /> y se llama a free_netdev(), causando un kvfree() en la estructura net_device que todavía está referenciada en la entrada de origen adjunta al puerto macvlan del dispositivo inferior.<br /> <br /> Ahora, todos los paquetes enviados en el puerto macvlan con una dirección MAC de origen coincidente activarán un uso después de liberación en macvlan_forward_source().&amp;#39;<br /> <br /> Con todo eso, mi solución 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;".<br /> <br /> Muchas gracias a valis por hacer seguimiento de este problema.

Impacto