Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 Jan 2003 22:53:18 +0100
From:      Thomas Moestl <tmoestl@gmx.net>
To:        Martin Blapp <mb@imp.ch>
Cc:        current@freebsd.org, net@freebsd.org
Subject:   Re: PANIC in tcp_syncache.c sonewconn() line 562
Message-ID:  <20030113215318.GA278@crow.dom2ip.de>
In-Reply-To: <20030113173957.T73725@levais.imp.ch>
References:  <20030113173957.T73725@levais.imp.ch>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2003/01/13 at 17:47:11 +0100, Martin Blapp wrote:
> #10 0xc03df350 in trap (frame=
>       {tf_fs = 24, tf_es = -65520, tf_ds = 16, tf_edi = 2, tf_esi = -1031597312,
> tf_ebp = -854635944, tf_isp = -854635988, tf_ebx = -1031595264, tf_edx = 4,
> tf_ecx = 0, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -1071076206, tf_cs
> = 8, tf_eflags = 66050, tf_esp = -1031595264, tf_ss =
> 0}) at /usr/src/sys/i386/i386/trap.c:445
> #11 0xc03cf9f8 in calltrap () at {standard input}:98
> #12 0xc02e1f3f in syncache_socket (sc=0xc2831300, lso=0xc2831300, m=0xc0ed9c00)
>     at /usr/src/sys/netinet/tcp_syncache.c:562
> #13 0xc02e23e8 in syncache_expand (inc=0xcd0f4b4c, th=0xc0ed9c68,
> sop=0xcd0f4b18, m=0xc0ed9c00)
>     at /usr/src/sys/netinet/tcp_syncache.c:781
> #14 0xc02db779 in tcp_input (m=0xc0ed9c68, off0=20) at
> /usr/src/sys/netinet/tcp_input.c:703
> #15 0xc02d409b in ip_input (m=0xc0ed9c00) at /usr/src/sys/netinet/ip_input.c:923
> #16 0xc02d4192 in ipintr () at /usr/src/sys/netinet/ip_input.c:941
> #17 0xc02c1713 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:97
> #18 0xc0238df1 in ithread_loop (arg=0xc0eba000) at
> /usr/src/sys/kern/kern_intr.c:535
> #19 0xc0237cf3 in fork_exit (callout=0xc0238c20 <ithread_loop>, arg=0x0,
> frame=0x0)
>     at /usr/src/sys/kern/kern_fork.c:873
> 
> 562             so = sonewconn(lso, SS_ISCONNECTED);

This seems to actually be a quite old bug: we allow listen() to be
called on connected sockets, which messes up the state of the socket
(it will get SO_ACCEPTCONN set). Before syncache, this would likely
only lead to the connection becoming catatonic, unless a matching SYN
packet came along (in a state where the initial SYN of the connection
was already received). With syncache however, a panic can be triggered
by normal ACK packets.
In your example, the listen is buried in the bowels of the RPC code.

The solution should be to reject the listen() with EINVAL (which seems
to be that standard-mandated error for connected sockets); patch
attached.

Any thoughts on this?

	- Thomas

-- 
Thomas Moestl <tmoestl@gmx.net>	http://www.tu-bs.de/~y0015675/
              <tmm@FreeBSD.org>	http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0  9C0F 1FE6 4F1D 419C 776C

Index: kern/uipc_socket.c
===================================================================
RCS file: /ncvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.140
diff -u -r1.140 uipc_socket.c
--- kern/uipc_socket.c	5 Jan 2003 11:14:04 -0000	1.140
+++ kern/uipc_socket.c	13 Jan 2003 21:43:52 -0000
@@ -266,6 +266,10 @@
 	int s, error;
 
 	s = splnet();
+	if (so->so_state & (SS_ISCONNECTED | SS_ISCONNECTING)) {
+		splx(s);
+		return (EINVAL);
+	}
 	error = (*so->so_proto->pr_usrreqs->pru_listen)(so, td);
 	if (error) {
 		splx(s);

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030113215318.GA278>