El equipo de FreeBSD publico el 29 de abril de 2026 el aviso FreeBSD-SA-26:14.pf, que corrige un fallo en pf, el filtro de paquetes que muchos servidores y firewalls FreeBSD usan a diario. El problema tiene asignado el identificador CVE-2026-7164 y permite que un atacante remoto tumbe el sistema con un solo paquete bien elegido.
Que falla exactamente
pf no se limita a aceptar o descartar paquetes segun tus reglas. Cuando ve trafico SCTP (Stream Control Transmission Protocol) inspecciona el contenido para localizar las direcciones adicionales que un endpoint puede anunciar. Ese analisis recorre los parametros de los chunks SCTP de forma recursiva.
Ahi esta el agujero. La validacion de esos parametros es insuficiente y la recursion no tiene tope. Un paquete preparado a propósito hace que pf se llame a si mismo una y otra vez hasta agotar la pila del kernel. El resultado es un desbordamiento de pila y un panic: la maquina se cae.
A quien afecta
A cualquier sistema FreeBSD con pf procesando trafico, sin importar las reglas que tengas escritas. El aviso es claro en este punto: el ruleset no protege, porque el analisis SCTP ocurre antes de que tus reglas decidan nada. Las versiones afectadas son FreeBSD 13.5, 14.3, 14.4 y 15.0, junto con sus ramas estables.
Eso incluye desde firewalls perimetrales y routers basados en FreeBSD hasta servidores que filtran su propio trafico. Si pf esta activo y ve paquetes que llegan de la red, estas expuesto.
Gravedad
El fallo se clasifica como alto, con CVSS 7.8. No permite ejecutar codigo ni robar datos: el impacto es denegacion de servicio. Pero conviene no restarle importancia. Un atacante remoto, sin autenticarse, puede tirar abajo un firewall enviando un puñado de paquetes SCTP manipulados. Si ese firewall protege una red entera o un servicio critico, la caida se nota.
Lo incomodo es que no hay mitigacion real. El aviso lo dice sin rodeos: la unica forma de no estar expuesto es no usar pf, lo cual rara vez es una opcion. No puedes filtrar el problema con una regla porque el fallo vive en el codigo que se ejecuta antes de aplicar reglas.
Como protegerse
Actualiza. Las correcciones salieron el mismo dia del aviso para las ramas 15.0, 14.4, 14.3 y 13.5. Tienes dos caminos:
- freebsd-update en sistemas binarios: aplica el parche y reinicia para cargar el kernel corregido.
- Parche de codigo fuente si compilas tu propio kernel: descarga el patch del aviso, recompila e instala.
Como el fallo esta en el kernel, necesitas reiniciar despues de actualizar. No basta con recargar el ruleset de pf.
Este no es el primer panic remoto que vemos en FreeBSD por desbordamiento de pila en el kernel: hace unos meses pasaba algo parecido con los routing sockets en CVE-2026-3038. El patron se repite, y la respuesta tambien: parchea y reinicia.
Si por la razon que sea no puedes parchear de inmediato y controlas el perimetro aguas arriba, bloquear el trafico SCTP entrante hacia la maquina afectada reduce la superficie. No es una solucion limpia y depende de tu topologia, pero ayuda a ganar tiempo hasta el reinicio con el kernel corregido.