>Number:         12027
>Category:       kern
>Synopsis:       accept(2) during SO_ISDISCONNECTED state -> strange sockaddr returned
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jan 22 09:27:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Jun-ichiro itojun Hagino
>Release:        1.5, 1.5.1_ALPHA, 1.5Q
>Organization:
	itojun.org
>Environment:
System: NetBSD starfruit.itojun.org 1.5Q NetBSD 1.5Q (STARFRUIT) #334: Mon Jan 22 16:42:39 JST 2001 itojun@starfruit.itojun.org:/usr/home/itojun/NetBSD/src/sys/arch/i386/compile/STARFRUIT i386
Architecture: i386
Machine: i386
>Description:
	if accept(2) is called while a listening socket is in
	SO_ISDISCONNECTED state, accept(2) can return bogus sockaddr.

	we experienced bogus sockaddr came back from accept(2) with
	positive return value (so accept succeed with bogus sockaddr), with
	the configuration presented in "how-to-repeat" section.

	tracked down a little bit, and found that so->so_state was set to
	SS_ISDISCONNECTED | SS_NBIO | SS_CANTRCVMORE | SS_CANTSENDMORE
	when accept(2) was called.

	if a socket is in SS_ISDISCONNECTED state,
	sys/kern/uipc_socket.c:soaccept will do nothing about the mbuf
	passed from sys/kern/uipc_syscalls.c:sys_accept() for sockaddr,
	and returns 0.  normally the mbuf contains junk data, and the junk
	data will be sent up to the userland as sockaddr.

>How-To-Repeat:
	run thttpd (pkgsrc/www/thttpd) on 1.5 or 1.5.1_ALPHA box.
	run nmap on the other end, like:
		# nmap -P0 -sT -v -p 80 target
		# nmap -P0 -sT -v -p 0-300 target
	thttpd dies with illegal address family.
	diagnose, and see sockaddr like this:

return value from accept: 7
3rd arg to accept(len): 40
content of sockaddr:
38e0cac02800000000000000001093db00000000000000000000000094d8bfbf007bd9c0007bd9c0

	sample packet trace is presented below.

01:55:25.117648 210.160.95.106.53010 > 210.160.95.104.80: S [tcp sum ok] 365377691:365377691(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 62363 0> (ttl 64, id 7819)
0x0000   4500 003c 1e8b 0000 4006 f81d d2a0 5f6a        E..<....@....._j
0x0010   d2a0 5f68 cf12 0050 15c7 389b 0000 0000        .._h...P..8.....
0x0020   a002 4000 9593 0000 0204 05b4 0103 0300        ..@.............
0x0030   0101 080a 0000 f39b 0000 0000                  ............
01:55:25.118219 210.160.95.104.80 > 210.160.95.106.53010: S [tcp sum ok] 1116983005:1116983005(0) ack 365377692 win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 1087 62363> (ttl 64, id 12)
0x0000   4500 003c 000c 0000 4006 169d d2a0 5f68        E..<....@....._h
0x0010   d2a0 5f6a 0050 cf12 4293 cedd 15c7 389c        .._j.P..B.....8.
0x0020   a012 4000 7fd2 0000 0204 05b4 0103 0300        ..@.............
0x0030   0101 080a 0000 043f 0000 f39b                  .......?....
01:55:25.118283 210.160.95.106.53010 > 210.160.95.104.80: . [tcp sum ok] ack 1 win 17520 <nop,nop,timestamp 62363 1087> (ttl 64, id 7820)
0x0000   4500 0034 1e8c 0000 4006 f824 d2a0 5f6a        E..4....@..$.._j
0x0010   d2a0 5f68 cf12 0050 15c7 389c 4293 cede        .._h...P..8.B...
0x0020   8010 4470 a726 0000 0101 080a 0000 f39b        ..Dp.&..........
0x0030   0000 043f                                      ...?
01:55:25.118356 210.160.95.106.53010 > 210.160.95.104.80: R [tcp sum ok] 1:1(0) ack 1 win 17520 (ttl 64, id 7821)
0x0000   4500 0028 1e8d 0000 4006 f82f d2a0 5f6a        E..(....@../.._j
0x0010   d2a0 5f68 cf12 0050 15c7 389c 4293 cede        .._h...P..8.B...
0x0020   5014 4470 d814 0000                            P.Dp....

>Fix:
	not 100% sure, but probably soaccept() should return some error
	instead of zero (if data is no longer queued)?  ECONNABORTED?

	or sys_accept() should check the situation before calling soaccept()?

	http://www.opengroup.org/onlinepubs/007908799/xns/accept.html
>Release-Note:
>Audit-Trail:
>Unformatted: