NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

kern/44059: panic in pf_modulate_sack after receipt of an TCP segment specifying invalid options

>Number:         44059
>Category:       kern
>Synopsis:       panic in pf_modulate_sack after receipt of an TCP segment 
>specifying invalid options
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Nov 07 17:40:00 +0000 2010
>Originator:     Lucio Albornoz
>Release:        NetBSD 5.0.1-RELEASE
NetBSD 5.0.1 NetBSD 5.0.1 (AMAL) #0: Fri Nov  5 23:54:02 CET 2010 i386

        pf_modulate_sack may cause a panic(9) given pf(4) and receipt of 
certain TCP
segments amending, at least as exhibited in this case, the unassigned TCP 
option 81
(pertaining to the Unassigned range as per[1]) alongside a length octet 
with the total header size as per the Data offset field.  The resulting 
analysed post-mortem appears, on the surface, quite similar to[2]; unfortunately
however, no further details relating to the immediate circumstance were 
included and
thus may or may not serve as reference.

#0  0xc03592dd in cpu_reboot (howto=260, bootstr=0x0) at 
#1  0xc02bce9b in panic (fmt=0xc0417f7b "trap") at 
#2  0xc035bc76 in trap (frame=0xcb07d774) at 
#3  0xc010cb60 in calltrap ()
#4  0xc03549f6 in db_read_bytes (addr=4, size=4, data=0xcb07d7dc 
"\200!g\n<&#9618;\a&#9618;<&#9618;\a&#9618;\004") at 
#5  0xc019f552 in db_get_value (addr=4, size=4, is_signed=false) at 
#6  0xc0355337 in db_stack_trace_print (addr=-888678188, have_addr=true, 
count=65535, modif=0xc0403e6c "", pr=0xc02bcc8c <printf>)
    at ../../../../arch/i386/i386/db_trace.c:147
#7  0xc02bce6c in panic (fmt=0xc0417f7b "trap") at 
#8  0xc035bc76 in trap (frame=0xcb07d998) at 
#9  0xc010cb60 in calltrap ()
#10 0xc017f9e9 in pf_modulate_sack (m=0xc2221800, off=20, pd=0xcb07dbb4, 
th=0xcb07dc2c, dst=0xc2706e60) at ../../../../dist/pf/net/pf.c:1600
#11 0xc0188261 in pf_test_state_tcp (state=0xcb07dc48, direction=1, 
kif=0xc19ad400, m=0xc2221800, off=20, h=0xcac82016, pd=0xcb07dbb4,
    reason=0xcb07dc52) at ../../../../dist/pf/net/pf.c:4060
#12 0xc018a86f in pf_test (dir=1, ifp=0xc19e0000, m0=0xcb07dcc0, eh=0x0) at 
#13 0xc018d4ba in pfil4_wrapper (arg=0x0, mp=0xcb07dcc0, ifp=0xc19e0000, dir=1) 
at ../../../../dist/pf/net/pf_ioctl.c:3184
#14 0xc0322fd1 in pfil_run_hooks (ph=0xc0466640, mp=0xcb07dd28, ifp=0xc19e0000, 
dir=1) at ../../../../net/pfil.c:70
#15 0xc0125e9a in ip_input (m=0xc2221800) at ../../../../netinet/ip_input.c:662
#16 0xc0126702 in ipintr () at ../../../../netinet/ip_input.c:476
#17 0xc02a32fd in softint_dispatch (pinned=0xcab07c80, s=4) at 
#18 0xc0100e4d in Xsoftintr ()
#19 0x00000000 in ?? ()

        The immediate culprit as visible from the core dump appears to comprise
the following condition:

        [ ... ]
        #10 0xc017f9e9 in pf_modulate_sack (m=0xc2221800, off=20, 
pd=0xcb07dbb4, th=0xcb07dc2c, dst=0xc2706e60) at 
        1600                    olen = opt[1];
        (gdb) print opt
        $28 = (u_int8_t *) 0xcb099000 <Address 0xcb099000 out of bounds>
        [ ... ]

        A tcpdump (8) of the relevant headers [bar IP addresses and TCP ports] 
of the
offending TCP segment as contained within the supplied mbuf structure for quick
reference follows:

ip: (tos 0x0, ttl 116, id 23046, offset 0, flags [DF], proto TCP (6), length 
1480) > FP, cksum 0x3f64 (correct), 
3560130094:3560131502(1408) ack 1812274157 win 58486 <[bad opt]>
        0x0000:  4500 05c8 5a06 4000 7406 c56d 0000 0000  E...Z.@.t..m....
        0x0010:  0000 0000 0000 0000 d433 462e 6c05 1bed  .........3F.l...
        0x0020:  d019 e476 3f64 0000 519d 4575 76d9 92a4  ...v?d..Q.Euv...
        0x0030:  941f b737 f62a aa11 0bbe 9ff6 7102 e8fe  ...7.*......q...
        0x0040:  d06a 15aa b470 5ef6 4254 172c 6f85 1be0  .j...p^.BT.,o...

        I can provide the full TCP segment, core file, kernel, kernel 
        etc. if necessary.

N.B.    The above behaviour has presented itself on numerous occasions over the
        timeframe of at least half a year, spanning NetBSD 5.0-RELEASE up until
        until 5.0.1-RELEASE, exhibiting an irregularity that may have one be led
        to presume either recurring hardware failure or a bug in the network 
        either exploited or inadvertently triggered; I have thus far not
        investigated this occurrence up until now and do therefore unfortunately
        find myself incapable of providing coredumps or backtraces applying to
        prior incidents of the same nature.

[1] TCP Option Kind Numbers - 
[2] pf(4) panic in pf_modulate_sack() on netbsd-5 - 


Home | Main Index | Thread Index | Old Index