CVE-2026-72124 in Linux
Resumen
por VulDB • 2026-08-16
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
can: isotp: serializar las transiciones del estado TX bajo so->rx_lock
La máquina de estados TX (so->tx.state) es controlada desde tres contextos: sendmsg() reclamando y avanzando una transferencia; la ruta RX consumiendo tramas de Control de Flujo/eco; y dos hrtimers que agotan el tiempo de espera para detener una transferencia bloqueada. La combinación de un reclamo cmpxchg() sin bloqueo en sendmsg() con llamadas a hrtimer_cancel() realizadas bajo so->rx_lock en otro lugar dejaba ventanas donde una trama o la devolución de llamada (callback) del temporizador podía actuar sobre un estado que ya había cambiado, corrompiendo así una transferencia no relacionada.
so->rx_lock ahora cubre todo el ciclo de vida de un reclamo TX: sendmsg() lo toma para verificar que so->tx.state sea ISOTP_IDLE, cambiarlo a ISOTP_SENDING, incrementar so->tx_gen y vaciar los temporizadores de la transferencia anterior; todo ello como una única sección crítica. isotp_rcv_fc()/isotp_rcv_cf() ya se ejecutan bajo este bloqueo a través de isotp_rcv(), e isotp_rcv_echo() ahora lo toma por sí mismo, por lo que ninguno de ellos puede observar nunca una transferencia durante el reclamo. Esto también significa que una transferencia ya no puede ser entregada a las rutas de limpieza de sendmsg() (señal o envío de error) mientras otro hilo está reclamándola o finalizándola concurrentemente, por lo que esas rutas pueden cancelar los temporizadores y restablecer el estado incondicionalmente.
isotp_release() reclama el socket de la misma manera, por lo que un sendmsg() en carrera ve un ISOTP_SHUTDOWN consistente y omite armar su temporizador o enviar datos.
Solo las devoluciones de llamada (callbacks) de hrtimer permanecen fuera de so->rx_lock, ya que se ejecutan bajo la cancelación de so->rx_lock en otro lugar y tomarlo ellas mismas provocaría un bloqueo mutuo (deadlock). so->tx_gen les permite reconocer si la transferencia cuyo tiempo ha expirado sigue siendo la actualmente activa, por lo que no informan un error contra una transferencia que ya se haya completado o sustituido.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.