Recent full disclosure post - Local DOS

[John Baldwin]

On Friday, January 28, 2011 12:38:22 pm Tom Judge wrote:
> On 01/28/2011 11:09 AM, John Baldwin wrote:
> > On Friday, January 28, 2011 11:08:37 am Tom Judge wrote:
> >> On 01/28/2011 08:29 AM, Tom Judge wrote:
> >>>
> >>> Has anyone looked at this:
> >>>
> >>> [Full-disclosure] FreeBSD local denial of service - forced reboot
> >>>
> >>> http://lists.grok.org.uk/pipermail/full-disclosure/2011-
> > January/078836.html
> >>>
> >>
> >> I have done some simple tests on ESXi 4.1.0, 260247.
> >>
> >> releng/8.1 - i386 - Not repeatable.
> >>
> >> releng/8.2-RC1 - amd64 - Not repeatable.
> >>
> >>
> >> current 9.0-CURRENT-201011 - i386 - Repeatable:
> >>
> >> Unread portion of the kernel message buffer:
> >> panic: tcp_output: mbuf chain shorter than expected
> >> cpuid = 0
> >> KDB: enter: panic
> >> Physical memory: 239 MB
> >> Dumping 99 MB: 84 68 52 36 20 4
> >>
> >>
> >> (kgdb) bt
> >> #0  doadump () at pcpu.h:231
> >> #1  0xc04d5809 in db_fncall (dummy1=1, dummy2=0, dummy3=-1057111072,
> >> dummy4=0xcd0cc78c "") at /usr/src/sys/ddb/db_command.c:548
> >> #2  0xc04d5c01 in db_command (last_cmdp=0xc0e0e27c, cmd_table=0x0,
> >> dopager=1) at /usr/src/sys/ddb/db_command.c:445
> >> #3  0xc04d5d5a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498
> >> #4  0xc04d7c7d in db_trap (type=3, code=0) at 
/usr/src/sys/ddb/db_main.c:229
> >> #5  0xc08ee99e in kdb_trap (type=3, code=0, tf=0xcd0cc930) at
> >> /usr/src/sys/kern/subr_kdb.c:546
> >> #6  0xc0bfcf5b in trap (frame=0xcd0cc930) at
> >> /usr/src/sys/i386/i386/trap.c:732
> >> #7  0xc0be5e8c in calltrap () at /usr/src/sys/i386/i386/exception.s:168
> >> #8  0xc08eeb6a in kdb_enter (why=0xc0cddbdf "panic", msg=0xc0cddbdf
> >> "panic") at cpufunc.h:71
> >> #9  0xc08bba04 in panic (fmt=0xc0cfb014 "%s: mbuf chain shorter than
> >> expected") at /usr/src/sys/kern/kern_shutdown.c:574
> >> #10 0xc0a3ecc6 in tcp_output (tp=0xc2789768) at
> >> /usr/src/sys/netinet/tcp_output.c:1084
> >> #11 0xc0a4a309 in tcp_ctloutput (so=0xc3a179a8, sopt=0xcd0ccc0c) at
> >> /usr/src/sys/netinet/tcp_usrreq.c:1328
> >> #12 0xc092742d in sosetopt (so=0xc3a179a8, sopt=0xcd0ccc0c) at
> >> /usr/src/sys/kern/uipc_socket.c:2396
> >> #13 0xc092ec95 in kern_setsockopt (td=0xc33b1b40, s=4, level=6, name=4,
> >> val=0xbfbfdacc, valseg=UIO_USERSPACE, valsize=4) at
> > 
> > This is an IPPROTO_TCP, TCP_NOPUSH with an optval of 0.
> > 
> > Can you try making a far simpler program that just does:
> > 
> > 	int optval, s;
> > 
> > 	s = socket(PF_INET, SOCK_STREAM, 0);
> > 	if (s < 0)
> > 		err(1, "socket");
> > 	optval = 0;
> > 	if (setsockopt(s, IPPROTO_TCP, TCP_NOPUSH, &optval, sizeof(optval)) < 
0)
> > 		err(1, "setsockopt");
> > 
> > and see if that breaks?
> > 
> 
> Hi John,
> 
> I can't repeat this with the code you sent.  I tried this in a while (1)
> loop and had 4 instances running without issue.

Humm.  That is the only setsockopt for TCP that can trigger a call to 
tcp_output().

I have a possible fix I'm just not sure if it is completely correct:

Index: tcp_usrreq.c
===================================================================
--- tcp_usrreq.c	(revision 218018)
+++ tcp_usrreq.c	(working copy)
@@ -1330,7 +1330,8 @@ tcp_ctloutput(struct socket *so, struct sockopt *s
 				tp->t_flags |= TF_NOPUSH;
 			else {
 				tp->t_flags &= ~TF_NOPUSH;
-				error = tcp_output(tp);
+				if (TCPS_HAVEESTABLISHED(tp->t_state))
+					error = tcp_output(tp);
 			}
 			INP_WUNLOCK(inp);
 			break;

-- 
John Baldwin