Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

CVE-2026-23460

Gravedad:
Pendiente de análisis
Tipo:
No Disponible / Otro tipo
Fecha de publicación:
03/04/2026
Última modificación:
03/04/2026

Descripción

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/rose: fix NULL pointer dereference in rose_transmit_link on reconnect<br /> <br /> syzkaller reported a bug [1], and the reproducer is available at [2].<br /> <br /> ROSE sockets use four sk-&gt;sk_state values: TCP_CLOSE, TCP_LISTEN,<br /> TCP_SYN_SENT, and TCP_ESTABLISHED. rose_connect() already rejects<br /> calls for TCP_ESTABLISHED (-EISCONN) and TCP_CLOSE with SS_CONNECTING<br /> (-ECONNREFUSED), but lacks a check for TCP_SYN_SENT.<br /> <br /> When rose_connect() is called a second time while the first connection<br /> attempt is still in progress (TCP_SYN_SENT), it overwrites<br /> rose-&gt;neighbour via rose_get_neigh(). If that returns NULL, the socket<br /> is left with rose-&gt;state == ROSE_STATE_1 but rose-&gt;neighbour == NULL.<br /> When the socket is subsequently closed, rose_release() sees<br /> ROSE_STATE_1 and calls rose_write_internal() -&gt;<br /> rose_transmit_link(skb, NULL), causing a NULL pointer dereference.<br /> <br /> Per connect(2), a second connect() while a connection is already in<br /> progress should return -EALREADY. Add this missing check for<br /> TCP_SYN_SENT to complete the state validation in rose_connect().<br /> <br /> [1] https://syzkaller.appspot.com/bug?extid=d00f90e0af54102fb271<br /> [2] https://gist.github.com/mrpre/9e6779e0d13e2c66779b1653fef80516

Impacto