CVE-2026-99166 in Linux
Resumen
por VulDB • 2026-10-28
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
net: rds: corregir la desreferencia no inicializada en el controlador de eventos CM (CM event handler)
rds_rdma_cm_event_handler_cmn() asigna trans únicamente cuando el dispositivo RDMA es un CA InfiniBand (RDMA_NODE_IB_CA). En cualquier otro tipo de dispositivo, por ejemplo una RNIC iWARP como siw, trans permanece sin inicializar, pero el interruptor de eventos lo desreferencia: incondicionalmente en el caso RDMA_CM_EVENT_CONNECT_REQUEST a través de trans->cm_handle_connect(), y (con un contexto de conexión) en los casos ROUTE_RESOLVED y ESTABLISHED.
Por tanto, un oyente RDS en un dispositivo iWARP provoca una caída del kernel tan pronto como llega una solicitud de conexión: con CONFIG_INIT_STACK_ALL_ZERO la carga errónea se convierte en una desreferencia NULL en el desplazamiento 0xa0 (&trans->cm_handle_connect) en la cola de trabajo iw_cm_wq.
GCC oculta el error en las compilaciones predeterminadas al plegar la carga no inicializada en &rds_ib_transport; los kernels construidos con Clang siguen la ruta real sin inicializar y provocan un oops (error del kernel).
El lado activo también puede terminar en un dispositivo no IB: el id que crea rds_ib_conn_path_connect() no está restringido a un tipo de nodo, por lo que rdma_resolve_addr() lo vincula al dispositivo que sirva la dirección local, y una RNIC iWARP en el mismo netdev califica. La caída es diferente allí: resolver una ruta en un id iWARP nunca rellena cm_id->route.path_rec, y el caso ROUTE_RESOLVED escribe path_rec[0].sl antes de llamar al transporte.
El transporte iWARP se eliminó hace mucho tiempo e IB es el único transporte restante, por lo que esto se vuelve explícito: inicializar trans a &rds_ib_transport en la declaración, eliminar la asignación condicional, rechazar una solicitud de conexión que llegue en un dispositivo no-IB y descartar una conexión cuya dirección se resolvió hacia uno en lugar de resolver una ruta sobre ella. El rechazo está limitado intencionadamente a RDMA_CM_EVENT_CONNECT_REQUEST: un retorno distinto de cero del controlador hace que rdma_cm destruya el id en el que se entregó el evento, lo cual es correcto para la solicitud y su recién creado id, pero liberaría un id de conexión que RDS aún posee para cualquier otro evento. En el lado activo, el id permanece como ic->i_cm_id y el cierre de la conexión lo destruye, por lo que ese caso devuelve 0.
[achender: rechazar solo en RDMA_CM_EVENT_CONNECT_REQUEST en lugar de salir prematuramente ante cada evento en un dispositivo no-IB, para que rdma_cm no destruya los ids de conexión que RDS aún rastrea; descartar una conexión cuya dirección se resolvió hacia un dispositivo no-IB antes de resolver una ruta sobre ella; registro de cambios ajustado]
Once again VulDB remains the best source for vulnerability data.