Vulnerabilidad en kernel de Linux (CVE-2025-37864)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: clean up FDB, MDB, VLAN entries on unbind Como se explica en muchos lugares como la confirmación b117e1e8a86d ("net: dsa: delete dsa_legacy_fdb_add y dsa_legacy_fdb_del"), DSA se escribe asumiendo que las capas superiores tienen adiciones/eliminaciones equilibradas. Como tal, solo tiene sentido ser extremadamente vocal cuando se violan esas suposiciones y el controlador se desvincula con entradas aún presentes. Pero Ido Schimmel señala una situación muy simple donde eso es incorrecto: https://lore.kernel.org/netdev/ZDazSM5UsPPjQuKr@shredder/ (también discutido brevemente por mí en la confirmación mencionada anteriormente). Básicamente, mientras que las operaciones de bypass de puente no son algo que DSA documente explícitamente, y para la mayoría de los controladores DSA esta API simplemente hace que pasen al modo promiscuo, ese no es el caso para todos los controladores. Algunos requisitos para que las operaciones de bypass de puente sean útiles (véase dsa_switch_supports_uc_filtering()). Si bien en tools/testing/selftests/net/forwarding/local_termination.sh nos esforzamos por popularizar mejores mecanismos para gestionar filtros de direcciones en interfaces DSA desde el espacio de usuario (en concreto, macvlan para unidifusión y setsockopt(IP_ADD_MEMBERSHIP) mediante mtools para multidifusión), lo cierto es que «bridge fdb add ... self static local» también existe como UAPI del kernel y podría ser útil, aunque solo sea para una modificación rápida. Parece contraproducente bloquear esa ruta implementando operaciones de shim .ndo_fdb_add y .ndo_fdb_del, que simplemente devuelven -EOPNOTSUPP para impedir la ejecución de ndo_dflt_fdb_add() y ndo_dflt_fdb_del(), aunque podríamos hacerlo. Aceptar la necesidad de una depuración parece ser la única opción. Sobre todo porque parece que también estamos abordando este tema desde una perspectiva diferente. Russell King observa que la función WARN_ON() se activa incluso para las VLAN: https://lore.kernel.org/netdev/Z_li8Bj8bD4-BYKQ@shell.armlinux.org.uk/ Lo que ocurre en el informe de error anterior es que dsa_port_do_vlan_del() falla, la entrada de la VLAN persiste y, a continuación, advertimos sobre la desvinculación y la filtramos. Esto no es una reversión directa de la confirmación criticada, sino que ahora añadimos una impresión informativa al registro del kernel (para seguir viendo la existencia de errores) y algunos comentarios adicionales recopilados de años anteriores para justificar la lógica.