Re: Recent full disclosure post - Local DOS

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.

Tom

--
TJU13-ARIN
_______________________________________________
freebsd-security@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Recent full disclosure post - Local DOS
    ... On Friday, January 28, 2011 12:38:22 pm Tom Judge wrote: ... I have done some simple tests on ESXi 4.1.0, ... Unread portion of the kernel message buffer: ... #0 doadump at pcpu.h:231 ...
    (FreeBSD-Security)
  • ath0 induced panic additional info
    ... By increasing the kernel message buffer, ... get the previous "Unread portion" im my last email. ... KDB: enter: witness_checkorder ... mobile:rootexit ...
    (freebsd-stable)
  • Re: Recent full disclosure post - Local DOS
    ... On Friday, January 28, 2011 11:08:37 am Tom Judge wrote: ... I have done some simple tests on ESXi 4.1.0, ... Unread portion of the kernel message buffer: ... #0 doadump at pcpu.h:231 ...
    (FreeBSD-Security)
  • Re: 6.0 random freezes
    ... >>>no keyboard response, no mouse, and after several minutes it reboots ... > Unread portion of the kernel message buffer: ... page fault while in kernel mode ...
    (freebsd-stable)
  • Re: zpool scrub causes geli vdev to detach
    ... but then I added ad0s2.eli and now scrubbing the pool leads to: ... Unread portion of the kernel message buffer: ...
    (freebsd-current)