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

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

[Jiayuan Chen]

From: Jiayuan Chen <jiayuan.chen@shopee.com>

syzkaller reported a bug [1], and the reproducer is available at [2].

When rose_connect() is called a second time on an already-connecting
socket, it overwrites rose->neighbour with the result of rose_get_neigh()
without releasing the previous reference. If rose_get_neigh() returns
NULL, the socket is left in an inconsistent state: rose->state remains
ROSE_STATE_1 from the first connect while rose->neighbour is 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 when accessing neigh->loopback.

Fix this by:
1. Releasing the old neighbour reference before attempting a reconnect
2. Resetting rose->state to ROSE_STATE_0 before the new connect attempt,
   so a failure leaves the socket in a clean state
3. Setting rose->neighbour to NULL in all error paths after
   rose_neigh_put() to prevent use-after-free on subsequent reconnects

[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/
Cc: Jiayuan Chen <jiayuan.chen@linux.dev>
Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com>
---
 net/rose/af_rose.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/net/rose/af_rose.c b/net/rose/af_rose.c
index 841d62481048..d9bf32ac3df3 100644
--- a/net/rose/af_rose.c
+++ b/net/rose/af_rose.c
@@ -814,6 +814,14 @@ static int rose_connect(struct socket *sock, struct sockaddr_unsized *uaddr, int
 	sk->sk_state   = TCP_CLOSE;
 	sock->state = SS_UNCONNECTED;
 
+	/* Release previous neighbour ref if reconnecting */
+	if (rose->neighbour) {
+		rose_neigh_put(rose->neighbour);
+		rose->neighbour = NULL;
+	}
+
+	rose->state = ROSE_STATE_0;
+
 	rose->neighbour = rose_get_neigh(&addr->srose_addr, &cause,
 					 &diagnostic, 0);
 	if (!rose->neighbour) {
@@ -825,6 +833,7 @@ static int rose_connect(struct socket *sock, struct sockaddr_unsized *uaddr, int
 	if (!rose->lci) {
 		err = -ENETUNREACH;
 		rose_neigh_put(rose->neighbour);
+		rose->neighbour = NULL;
 		goto out_release;
 	}
 
@@ -837,6 +846,7 @@ static int rose_connect(struct socket *sock, struct sockaddr_unsized *uaddr, int
 		if (!dev) {
 			err = -ENETUNREACH;
 			rose_neigh_put(rose->neighbour);
+			rose->neighbour = NULL;
 			goto out_release;
 		}
 
@@ -844,6 +854,7 @@ static int rose_connect(struct socket *sock, struct sockaddr_unsized *uaddr, int
 		if (!user) {
 			err = -EINVAL;
 			rose_neigh_put(rose->neighbour);
+			rose->neighbour = NULL;
 			dev_put(dev);
 			goto out_release;
 		}
-- 
2.43.0

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

[Eric Dumazet]

On Tue, Mar 10, 2026 at 11:14 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].
>
> When rose_connect() is called a second time on an already-connecting
> socket, it overwrites rose->neighbour with the result of rose_get_neigh()
> without releasing the previous reference. If rose_get_neigh() returns
> NULL, the socket is left in an inconsistent state: rose->state remains
> ROSE_STATE_1 from the first connect while rose->neighbour is 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 when accessing neigh->loopback.
>
> Fix this by:
> 1. Releasing the old neighbour reference before attempting a reconnect
> 2. Resetting rose->state to ROSE_STATE_0 before the new connect attempt,
>    so a failure leaves the socket in a clean state
> 3. Setting rose->neighbour to NULL in all error paths after
>    rose_neigh_put() to prevent use-after-free on subsequent reconnects
>
> [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/
> Cc: Jiayuan Chen <jiayuan.chen@linux.dev>
> Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com>
> ---
>  net/rose/af_rose.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)

Normally, a connect() on a socket already connected should return an error.

disconnect is a special operation involving AF_UNSPEC

man connect
...
       Some  protocol  sockets  (e.g., TCP sockets as well as datagram
sockets in the UNIX and Internet domains) may dissolve the association
by
       connecting to an address with the sa_family member of sockaddr
set to AF_UNSPEC; thereafter, the socket can be connected to  another
ad‐
       dress.  (AF_UNSPEC is supported since Linux 2.2.)

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

[Jiayuan Chen]

March 10, 2026 at 18:24, "Eric Dumazet" <edumazet@google.com mailto:edumazet@google.com?to=%22Eric%20Dumazet%22%20%3Cedumazet%40google.com%3E > wrote:


> 
> On Tue, Mar 10, 2026 at 11:14 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].
> > 
> >  When rose_connect() is called a second time on an already-connecting
> >  socket, it overwrites rose->neighbour with the result of rose_get_neigh()
> >  without releasing the previous reference. If rose_get_neigh() returns
> >  NULL, the socket is left in an inconsistent state: rose->state remains
> >  ROSE_STATE_1 from the first connect while rose->neighbour is 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 when accessing neigh->loopback.
> > 
> >  Fix this by:
> >  1. Releasing the old neighbour reference before attempting a reconnect
> >  2. Resetting rose->state to ROSE_STATE_0 before the new connect attempt,
> >  so a failure leaves the socket in a clean state
> >  3. Setting rose->neighbour to NULL in all error paths after
> >  rose_neigh_put() to prevent use-after-free on subsequent reconnects
> > 
> >  [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/
> >  Cc: Jiayuan Chen <jiayuan.chen@linux.dev>
> >  Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com>
> >  ---
> >  net/rose/af_rose.c | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> > 
> Normally, a connect() on a socket already connected should return an error.
> 
> disconnect is a special operation involving AF_UNSPEC
> 
> man connect
> ...
>  Some protocol sockets (e.g., TCP sockets as well as datagram
> sockets in the UNIX and Internet domains) may dissolve the association
> by
>  connecting to an address with the sa_family member of sockaddr
> set to AF_UNSPEC; thereafter, the socket can be connected to another
> ad‐
>  dress. (AF_UNSPEC is supported since Linux 2.2.)
>

Thanks for pointing this out. I should have checked the man page earlier.

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;


Tested and the panic is gone. Will send v2 after the cool-down period.