DF-3524 VERDICT — verified end-to-end on the QEMU guest

Status: REPRODUCED (stock kernel) — impact: kernel panic (+ total L2CAP connection-establishment outage + con/cmd leaks). FIX VALIDATED (kernel #1 + stock ng7 modules).

Root cause (certain)

ng_l2cap_lp_untimeout() / ng_l2cap_command_untimeout() (sys/netgraph7/bluetooth/l2cap/ng_l2cap_misc.c:493-504 / command variant) interpret ng_uncallout() == 0 as "the timer already fired" and return ETIMEDOUT:

if (ng_uncallout(&con->con_timo, con->l2cap->node) == 0)
    return (ETIMEDOUT);
con->flags &= ~NG_L2CAP_CON_LP_TIMO;

Under the DF-3515 callout_stop(9) contract violation (kern_timeout.c _callout_cancel_or_stop completes an armed STOP inline, without setting CALLOUT_PREVENTED, then early-exits with return 0 at :888-891), callout_stop() of an ARMED, not-yet-fired timer returns 0 -- so a successfully cancelled timer is indistinguishable from a fired one. callout_cancel() suffers the identical early-exit (verified by experiment: swapping stop->cancel in ng7 ng_uncallout did NOT fix the wedge; only the kern_timeout fix did).

Consequences, all in my audited file ng_l2cap_llpi.c:

1. ng_l2cap_lp_con_cfm (:180-181): every positive LP_ConnectCfm that arrives while the LP timer is armed (i.e. every real one) is DISCARDED with ETIMEDOUT before :183-186 assigns con_handle/state -- no L2CAP connection can ever reach CON_OPEN. The synchronous control-message reply carries ETIMEDOUT to userspace (observed). NG_L2CAP_CON_LP_TIMO stays set with NO timer running (zombie con); the con descriptor + its channels leak.
2. ng_l2cap_lp_discon_ind (:330-332): same pattern -- DisconInd ignored, con stays OPEN with AUTO_DISCON_TIMO stuck.
3. Every L2CAP signaling response (evnt.c, command_untimeout callers) is treated as "too late" -> commands never complete -> channel setup impossible -> DoS + pending-cmd leak.
4. Node teardown with a zombie con hits the deliberate panic("timeout pending") in ng_l2cap_free_con (ng_l2cap_misc.c:280) -- deterministic kernel panic: observed twice on the stock guest (panic.txt), backtrace ng_l2cap_free_con <- ng_l2cap_cleanup <- ng_l2cap_disconnect <- ng_destroy_hook <- ng_apply_item.

Corroboration: DF-3513's pack independently recorded the same class ("DF-3515: callout_stop() returns 0 for an armed callout, so complete_command() always takes the silent ETIMEDOUT path") wedging the HCI layer.

Reproduction (guest, X86_64_GENERIC #0, INVARIANTS)

Graph: ng7 control socket --c0-- l2cap0:hci (the socket node forges the ng_hci lower layer; ng7 data sockets have no privilege check, the whole attack loop runs as uid 65534).

# ./l2cap_con con LP_CON_IND -> ok HCI_NODE_UP -> ok LP_CON_CFM (pos) -> Operation timed out <-- cfm DISCARDED ECHO_RSP -> NOT RECEIVED (con never OPEN) (process exit) -> panic: ng_l2cap_free_con: timeout pending! state=0, flags=0x28 [guest down]

Kernel side: ng_l2cap_lp_receive: unexpected ACL data packet. Connection does not exist, con_handle=291 -- 0x123 was never assigned because llpi.c:185 never ran.

Fix validation

Applied the DF-3521-validated kern_timeout.c fix (inline-completed stop/cancel reports PREVENTED -> callout_stop(armed) returns 1), full kernel rebuild (make nativekernel, RC=0, kernel #1), STOCK ng7 modules (ng_uncallout untouched, still callout_stop):

# ./l2cap_con con LP_CON_CFM (pos) -> ok (connection accepted -> CON_OPEN) ECHO_RSP -> received 17 bytes -- echo works exit=0 (NO teardown panic)

The bug is reachable by any local user (ng7 socket attach is unprivileged) whenever an ng_l2cap node is wired to an HCI lower layer (real Bluetooth stack or any netgraph graph); on real hardware the same discard hits every remote-peer-driven connect/disconnect.

Impact ceiling: deterministic unprivileged local kernel panic + complete L2CAP protocol outage; no memory-corruption primitive found (the stuck flags only poison state, they do not corrupt memory).

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.