From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-177.mta1.migadu.com (out-177.mta1.migadu.com [95.215.58.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 78F483876D0 for ; Tue, 10 Mar 2026 11:28:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773142121; cv=none; b=lZUvlyJcj9klIiZjx0dx3WJDf9kBNjM11b84FuZE89Ht/si2XgwY1/tgzBMtS1OZQhoiHDOxRnpCc+hfRwlm/zQmoDDezZnrrHYzon/3LLfiHWblDKBPOwfoDL6349JYcNmzuaJ1SGvmFI/GBha9ir8d22wDn44X2kl53nT4b1Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773142121; c=relaxed/simple; bh=KQqnhr6YlAa/gpy+sTU5GHwCZhZ6qW8rmLEx/uTsI6M=; h=MIME-Version:Date:Content-Type:From:Message-ID:Subject:To:Cc: In-Reply-To:References; b=fxmqUmJ9fTZ1W6yEjEmjN6DmNlxx0EDbUoPSbrLBwqtBOt1jx+v7EaMEnSj5nGUwPXPIdOz2FMnnrDKmgYZ/b5owksXxBRO9I2QcmlR9G+IPJqwdTZXB0a73bj/FE3YCWgOUHWaA9TmbVneNxSHQ0xgFVIovORNLMjrobPVpO2A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=iaqdFc3R; arc=none smtp.client-ip=95.215.58.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="iaqdFc3R" Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1773142108; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QEgXSRi8An7XY2t213VJlqkfT5N4BKHBSmPFM54cjbw=; b=iaqdFc3RsLQKWQKQN/Dj5JCr7ZNoeWvtHZhT7DR5h1QYm2oa4XgZvbw4/kPBEWPd89jzwA 0gP34tz/uVYgVBFIgPMRmTV3V7rgQhBJ19wM5DjxuFlL1/L572bIg2VeFVMWWrBNrZQNMx LClaA0J8SKfUHY/P7jBfYRlDUzZRa50= Date: Tue, 10 Mar 2026 11:28:25 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "Jiayuan Chen" Message-ID: <215d34adafe389a6792b2ca111ac3ec7ccc079ca@linux.dev> TLS-Required: No Subject: Re: [PATCH net v1] net/rose: fix NULL pointer dereference in rose_transmit_link on reconnect To: "Eric Dumazet" Cc: netdev@vger.kernel.org, "Jiayuan Chen" , syzbot+d00f90e0af54102fb271@syzkaller.appspotmail.com, "David S. Miller" , "Jakub Kicinski" , "Paolo Abeni" , "Simon Horman" , "Kees Cook" , "Takamitsu Iwai" , "Pwnverse" , "Ingo Molnar" , linux-hams@vger.kernel.org, linux-kernel@vger.kernel.org In-Reply-To: References: <20260310101349.50993-1-jiayuan.chen@linux.dev> X-Migadu-Flow: FLOW_OUT March 10, 2026 at 18:24, "Eric Dumazet" = wrote: >=20 >=20On Tue, Mar 10, 2026 at 11:14 AM Jiayuan Chen wrote: >=20 >=20>=20 >=20> From: Jiayuan Chen > >=20 >=20> syzkaller reported a bug [1], and the reproducer is available at [= 2]. > >=20 >=20> When rose_connect() is called a second time on an already-connecti= ng > > socket, it overwrites rose->neighbour with the result of rose_get_ne= igh() > > without releasing the previous reference. If rose_get_neigh() return= s > > NULL, the socket is left in an inconsistent state: rose->state remai= ns > > ROSE_STATE_1 from the first connect while rose->neighbour is NULL. > >=20 >=20> When the socket is subsequently closed, rose_release() sees ROSE_S= TATE_1 > > and calls rose_write_internal() -> rose_transmit_link(skb, NULL), ca= using > > a NULL pointer dereference when accessing neigh->loopback. > >=20 >=20> Fix this by: > > 1. Releasing the old neighbour reference before attempting a reconne= ct > > 2. Resetting rose->state to ROSE_STATE_0 before the new connect atte= mpt, > > 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 > >=20 >=20> [1] https://syzkaller.appspot.com/bug?extid=3Dd00f90e0af54102fb271 > > [2] https://gist.github.com/mrpre/9e6779e0d13e2c66779b1653fef80516 > >=20 >=20> 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 > > Signed-off-by: Jiayuan Chen > > --- > > net/rose/af_rose.c | 11 +++++++++++ > > 1 file changed, 11 insertions(+) > >=20 >=20Normally, a connect() on a socket already connected should return an = error. >=20 >=20disconnect is a special operation involving AF_UNSPEC >=20 >=20man 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=E2=80=90 > 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 =3D=3D TCP_SYN_SENT) { + err =3D -EALREADY; + goto out_release; + } + sk->sk_state =3D TCP_CLOSE; sock->state =3D SS_UNCONNECTED; Tested and the panic is gone. Will send v2 after the cool-down period.