CVE-2026-23460: net/rose: fix NULL pointer dereference in rose_transmit_link on reconnect
In the Linux kernel, the following vulnerability has been resolved:
net/rose: fix NULL pointer dereference in rosetransmitlink on reconnect
syzkaller reported a bug [1], and the reproducer is available at [2].
ROSE sockets use four sk->skstate values: TCPCLOSE, TCPLISTEN, TCPSYNSENT, and TCPESTABLISHED. roseconnect() already rejects calls for TCPESTABLISHED (-EISCONN) and TCPCLOSE with SSCONNECTING (-ECONNREFUSED), but lacks a check for TCPSYNSENT.
When roseconnect() is called a second time while the first connection attempt is still in progress (TCPSYNSENT), it overwrites rose->neighbour via rosegetneigh(). If that returns NULL, the socket is left with rose->state == ROSESTATE1 but rose->neighbour == NULL. When the socket is subsequently closed, roserelease() sees ROSESTATE1 and calls rosewriteinternal() -> rosetransmitlink(skb, NULL), causing a NULL pointer dereference.
Per connect(2), a second connect() while a connection is already in progress should return -EALREADY. Add this missing check for TCPSYNSENT to complete the state validation in roseconnect().
[1] https://syzkaller.appspot.com/bug?extid=d00f90e0af54102fb271 [2] https://gist.github.com/mrpre/9e6779e0d13e2c66779b1653fef80516
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the crash?
A local attacker or process needs to use a ROSE socket, call connect() again while its first connection attempt is still in progress (TCP_SYN_SENT), and cause the second attempt's rose_get_neigh() call to return NULL. Closing the socket afterward triggers the NULL pointer dereference.
What is the expected impact of successful exploitation?
The vulnerability has availability impact only: the provided CVSS vector identifies no confidentiality or integrity impact and a high availability impact. It can cause a NULL pointer dereference in the Linux kernel.
How does the fix change behavior for a second connect() call?
The fix adds validation for the TCP_SYN_SENT state in rose_connect(). A second connect() while a connection is already in progress returns -EALREADY, as specified by connect(2), rather than overwriting the socket's neighbour state.