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

Jiayuan Chen posted 1 patch 3 weeks, 6 days ago
net/rose/af_rose.c | 5 +++++
1 file changed, 5 insertions(+)
[PATCH net v2] net/rose: fix NULL pointer dereference in rose_transmit_link on reconnect
Posted by Jiayuan Chen 3 weeks, 6 days ago
From: Jiayuan Chen <jiayuan.chen@shopee.com>

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: syzbot+d00f90e0af54102fb271@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/69694d6f.050a0220.58bed.0027.GAE@google.com/T/
Suggested-by: Eric Dumazet <edumazet@google.com>
Cc: Jiayuan Chen <jiayuan.chen@linux.dev>
Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com>
---
 net/rose/af_rose.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/net/rose/af_rose.c b/net/rose/af_rose.c
index 841d62481048..ba56213e0a2a 100644
--- a/net/rose/af_rose.c
+++ b/net/rose/af_rose.c
@@ -811,6 +811,11 @@ static int rose_connect(struct socket *sock, struct sockaddr_unsized *uaddr, int
 		goto out_release;
 	}
 
+	if (sk->sk_state == TCP_SYN_SENT) {
+		err = -EALREADY;
+		goto out_release;
+	}
+
 	sk->sk_state   = TCP_CLOSE;
 	sock->state = SS_UNCONNECTED;
 
-- 
2.43.0
Re: [PATCH net v2] net/rose: fix NULL pointer dereference in rose_transmit_link on reconnect
Posted by Eric Dumazet 3 weeks, 6 days ago
On Wed, Mar 11, 2026 at 8:06 AM Jiayuan Chen <jiayuan.chen@linux.dev> wrote:
>
> From: Jiayuan Chen <jiayuan.chen@shopee.com>
>
> 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: syzbot+d00f90e0af54102fb271@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/69694d6f.050a0220.58bed.0027.GAE@google.com/T/
> Suggested-by: Eric Dumazet <edumazet@google.com>
> Cc: Jiayuan Chen <jiayuan.chen@linux.dev>
> Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com>
> ---

Reviewed-by: Eric Dumazet <edumazet@google.com>