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 Tom -- TJU13-ARIN
Tom Judge <tom@tomjudge.com> 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.htmlI don't have a 8.0-RELEASE with a "specific network driver" around for testing, but at least on 9.0-CURRENT amd64 with iwn and bge it doesn't seem to work: fk@r500 ~/test/freebsd $./freebsd-crash SUCCESS! SUCCESS! SUCCESS! fk@r500 ~/test/freebsd $sudo ./freebsd-crash Password: SUCCESS! SUCCESS! SUCCESS! Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20110128/7dff0dab/signature.pgp
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 /usr/src/sys/kern/uipc_syscalls.c:1335 #14 0xc092ed1e in setsockopt (td=0xc33b1b40, uap=0xcd0cccec) at /usr/src/sys/kern/uipc_syscalls.c:1290 #15 0xc08fc103 in syscallenter (td=0xc33b1b40, sa=0xcd0ccce4) at /usr/src/sys/kern/subr_trap.c:318 #16 0xc0bfc804 in syscall (frame=0xcd0ccd28) at /usr/src/sys/i386/i386/trap.c:1095 #17 0xc0be5ef1 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:266 #18 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) None ESXi armv5te IOP 80321 current -r216409 - Not repeatable. I am in the process of building a more up to date current to do another test. Tom -- TJU13-ARIN
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) atThis 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? -- John Baldwin
On 01/29/11 11:30, Christian Peron wrote:> On Fri, Jan 28, 2011 at 02:27:18PM -0500, John Baldwin wrote: > [..] >> ==================================================================>> --- 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; > > I was thinking of correcting it the same way.. I might even do something > like: > > else { > if (tp->t_flags & TF_NOPUSH) { > tp->t_flags &= ~TF_NOPUSH; > if (TCPS_HAVEESTABLISHED(tp->t_state)) > error = tcp_output(tp); > } > } > > By default, this mask is not set.. so un-setting it and calling tcp_output() > if it was not already set seems wastefulApologies for tuning in late, but FWIW I concur and think the above patch is appropriate. Cheers, Lawrence
Hi all, So then, this just crashes in current?? else... is it known which kernel nic drivers cause this?. I have attempted to crash a 8.1-release on vmware fusion virtual machine without success... Thanks a lot!, Bye! El 31/01/2011, a las 23:40, Lawrence Stewart escribi?:> On 01/29/11 11:30, Christian Peron wrote: >> On Fri, Jan 28, 2011 at 02:27:18PM -0500, John Baldwin wrote: >> [..] >>> ==================================================================>>> --- 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; >> >> I was thinking of correcting it the same way.. I might even do something >> like: >> >> else { >> if (tp->t_flags & TF_NOPUSH) { >> tp->t_flags &= ~TF_NOPUSH; >> if (TCPS_HAVEESTABLISHED(tp->t_state)) >> error = tcp_output(tp); >> } >> } >> >> By default, this mask is not set.. so un-setting it and calling tcp_output() >> if it was not already set seems wasteful > > Apologies for tuning in late, but FWIW I concur and think the above > patch is appropriate. > > Cheers, > Lawrence > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
Hi all!, I have seen the patch has been applied in releng_7_4, releng_8_2, stable, head... but not in releng_8_1 or releng_8_0... is it planned to be applied too on this branches?? Thanks a lot. Bye! El 03/02/2011, a las 17:19, Egoitz Aurrekoetxea Aurre escribi?:> Hi all, > > So then, this just crashes in current?? else... is it known which kernel nic drivers cause this?. I have attempted to crash a 8.1-release on vmware fusion virtual machine without success... > > Thanks a lot!, > Bye! > > > El 31/01/2011, a las 23:40, Lawrence Stewart escribi?: > >> On 01/29/11 11:30, Christian Peron wrote: >>> On Fri, Jan 28, 2011 at 02:27:18PM -0500, John Baldwin wrote: >>> [..] >>>> ==================================================================>>>> --- 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; >>> >>> I was thinking of correcting it the same way.. I might even do something >>> like: >>> >>> else { >>> if (tp->t_flags & TF_NOPUSH) { >>> tp->t_flags &= ~TF_NOPUSH; >>> if (TCPS_HAVEESTABLISHED(tp->t_state)) >>> error = tcp_output(tp); >>> } >>> } >>> >>> By default, this mask is not set.. so un-setting it and calling tcp_output() >>> if it was not already set seems wasteful >> >> Apologies for tuning in late, but FWIW I concur and think the above >> patch is appropriate. >> >> Cheers, >> Lawrence >> _______________________________________________ >> freebsd-security@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-security >> To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"