⬢ DragonFlyBSD Kernel Audit
DF-3524 / run.log
← back to finding ↓ download raw
DF-3524 run.log — STOCK kernel (X86_64_GENERIC #0, INVARIANTS), guest dfbsd

[1] # ./l2cap_con con        (graph: socket-node --c0-- l2cap0:hci; the
                              harness forges the ng_hci lower layer)
LP_CON_IND          -> ok          (con created, W4_LP_CON_CFM, LP timer armed)
HCI_NODE_UP         -> ok          (pkt_size=65535, num_pkts=8)
LP_CON_CFM (pos)    -> Operation timed out   <-- ConnectCfm DISCARDED
                                             (ng_l2cap_lp_untimeout() saw
                                              ng_uncallout()==0 for an
                                              ARMED-THEN-CANCELLED timer)
ECHO_RSP            -> NOT RECEIVED (con never OPEN -- DF-3524 wedge)

[2] kernel side (serial console):
    ng_l2cap_lp_receive: l2c0 - unexpected ACL data packet. Connection
    does not exist, con_handle=291
       (291 = 0x123: the handle was never assigned because llpi.c:185
        never ran -- the cfm was discarded at :180-181)

[3] teardown (process exit -> sockets close -> hci hook disconnect):
    panic: ng_l2cap_free_con: l2c0 - timeout pending! state=0, flags=0x28
    (flags 0x28 contains NG_L2CAP_CON_LP_TIMO(0x8): stuck because
     lp_untimeout returned ETIMEDOUT without clearing it; the con is
     then destroyed with a "pending" timeout -> deliberate panic)
    full backtrace in panic.txt:
    ng_l2cap_free_con() <- ng_l2cap_cleanup <- ng_l2cap_disconnect <-
    ng_destroy_hook <- ng_apply_item

[4] same panic reproduced twice (also hit before the arglen fix, with the
    con left in the identical stuck-LP_TIMO state).