Re: [PATCH net v2] net/rose: fix NULL pointer dereference in rose_transmit_link on reconnect

Eric Dumazet <[email protected]> Wed, 11 Mar 2026 09:24:47 +0100
Newsgroups org.kernel.vger.linux-hams,org.kernel.vger.linux-kernel,org.kernel.vger.netdev
Message-ID <CANn89i+MTAhm+T3dR9T45wOBU3xjiyKfsKXHen3bBLu2T8JD9Q@mail.gmail.com>
On Wed, Mar 11, 2026 at 8:06 AM Jiayuan Chen <[email protected]> wrote:
>
> From: Jiayuan Chen <[email protected]>
>
> syzkaller reported a bug [1], and the reproducer is available at [2].
>
> ROSE sockets use four sk->sk_state values: TCP_CLOSE, TCP_LISTEN,
> TCP_SYN_SENT, and TCP_ESTABLISHED. rose_connect() already rejects
> calls for TCP_ESTABLISHED (-EISCONN) and TCP_CLOSE with SS_CONNECTING
> (-ECONNREFUSED), but lacks a check for TCP_SYN_SENT.
>
> When rose_connect() is called a second time while the first connection
> attempt is still in progress (TCP_SYN_SENT), it overwrites
> rose->neighbour via rose_get_neigh(). If that returns NULL, the socket
> is left with rose->state == ROSE_STATE_1 but rose->neighbour == NULL.
> When the socket is subsequently closed, rose_release() sees
> ROSE_STATE_1 and calls rose_write_internal() ->
> rose_transmit_link(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
> TCP_SYN_SENT to complete the state validation in rose_connect().
>
> [1] https://syzkaller.appspot.com/bug?extid=d00f90e0af54102fb271
> [2] https://gist.github.com/mrpre/9e6779e0d13e2c66779b1653fef80516
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Reported-by: [email protected]
> Closes: https://lore.kernel.org/all/[email protected]/T/
> Suggested-by: Eric Dumazet <[email protected]>
> Cc: Jiayuan Chen <[email protected]>
> Signed-off-by: Jiayuan Chen <[email protected]>
> ---

Reviewed-by: Eric Dumazet <[email protected]>