Se ha identificado una vulnerabilidad en el código del controlador del protocolo RDS basado en TCP (Reliable Datagram Socket, net/rds/tcp.c) (), lo que puede provocar el acceso a un área de memoria ya liberada y una denegación de servicio (potencialmente, no se excluye la posibilidad de aprovechar el problema para organizar la ejecución del código). El problema se debe a una condición de carrera que puede ocurrir al ejecutar la función rds_tcp_kill_sock mientras se borran los sockets para el espacio de nombres de la red.
Especificación el problema está marcado como explotable de forma remota a través de la red, pero a juzgar por la descripción , sin presencia local en el sistema y manipulación de espacios de nombres, no será posible organizar un ataque de forma remota. En particular, según Los desarrolladores de SUSE, la vulnerabilidad se explota sólo localmente; organizar un ataque es bastante complejo y requiere privilegios adicionales en el sistema. Si en NVD el nivel de peligro se evalúa en 9.3 (CVSS v2) y 8.1 (CVSS v2) puntos, según la calificación SUSE el peligro se evalúa en 6.4 puntos sobre 10.
Los representantes de Ubuntu también el peligro del problema se considera moderado. Al mismo tiempo, de acuerdo con la especificación CVSS v3.0, al problema se le asigna un alto nivel de complejidad de ataque y a la explotabilidad se le asigna solo 2.2 puntos sobre 10.
A juzgar por los de Cisco, la vulnerabilidad se explota de forma remota mediante el envío de paquetes TCP a servicios de red en funcionamiento y ya existe un prototipo del exploit. Aún no está claro hasta qué punto esta información se corresponde con la realidad; tal vez el informe solo enmarque artísticamente las suposiciones de NVD. Por El exploit VulDB aún no se ha creado y el problema sólo se explota localmente.
El problema aparece en kernels anteriores a 5.0.8 y está bloqueado por March , incluido en el kernel 5.0.8. En la mayoría de las distribuciones el problema sigue sin resolverse (, , , ). La solución se ha publicado para SLE12 SP3, openSUSE 42.3 y .
Fuente: opennet.ru