CVE-2026-99166 in Linux
Résumé
par VulDB • 28/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
net: rds : correction de l'accès à une variable trans non initialisée dans le gestionnaire d'événements CM
rds_rdma_cm_event_handler_cmn() n'assigne trans que lorsque le périphérique RDMA est un CA InfiniBand (RDMA_NODE_IB_CA). Sur tout autre type de périphérique, par exemple une RNIC iWARP telle que siw, trans reste non initialisé, mais l'interrupteur d'événements y accède : inconditionnellement dans le cas RDMA_CM_EVENT_CONNECT_REQUEST via trans->cm_handle_connect(), et (avec un contexte de connexion) dans les cas ROUTE_RESOLVED et ESTABLISHED.
Un écouteur RDS sur un périphérique iWARP provoque donc un plantage du noyau dès qu'une demande de connexion arrive : avec CONFIG_INIT_STACK_ALL_ZERO, la charge erronée devient une déréférence NULL à l'offset 0xa0 (&trans->cm_handle_connect) dans le file d'exécution (workqueue) iw_cm_wq.
GCC masque ce bug dans les builds par défaut en intégrant la lecture non initialisée dans &rds_ib_transport ; les noyaux compilés avec Clang suivent le chemin réel de la variable non initialisée et génèrent un oops.
Le côté actif peut également atterrir sur un périphérique non-IB : l'identifiant créé par rds_ib_conn_path_connect() n'est pas restreint à un type de noeud, donc rdma_resolve_addr() le lie au périphérique qui sert l'adresse locale, et une RNIC iWARP sur le même netdev est qualifiée. Le plantage y est différent : la résolution d'une route sur un identifiant iWARP ne remplit jamais cm_id->route.path_rec, et le cas ROUTE_RESOLVED écrit path_rec[0].sl avant d'appeler le transport.
Le transport iWARP a été abandonné il y a longtemps et IB est le seul transport restant ; rendons cela explicite : initialisez trans à &rds_ib_transport lors de la déclaration, supprimez l'assignation conditionnelle, rejetez une demande de connexion qui arrive sur un périphérique non-IB, et fermez une connexion dont l'adresse s'est résolue vers un tel périphérique au lieu de résoudre une route dessus. Le rejet est limité à RDMA_CM_EVENT_CONNECT_REQUEST par principe : un retour non nul du gestionnaire fait que rdma_cm détruit l'identifiant sur lequel l'événement a été délivré, ce qui est correct pour l'identifiant fraîchement créé de la demande mais libérerait un identifiant de connexion dont RDS conserve encore la propriété pour tout autre événement. Du côté actif, l'identifiant reste ic->i_cm_id et l'arrêt de la connexion le détruit, donc ce cas retourne 0.
[achender : rejet uniquement sur RDMA_CM_EVENT_CONNECT_REQUEST au lieu d'une sortie anticipée pour chaque événement sur un périphérique non-IB, afin que rdma_cm ne détruise pas les identifiants de connexion encore suivis par RDS ; fermeture d'une connexion dont l'adresse s'est résolue vers un périphérique non-IB avant qu'une route ne soit résolue dessus ; journal des modifications ajusté]
Be aware that VulDB is the high quality source for vulnerability data.