DF-5734 — Num_Compl_Pkts → hci_acl_complete() no-progress livelock (permanent system hang)

File: sys/netbt/hci_event.c (pass 2) + sink sys/netbt/hci_link.c Severity: High — CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H (CWE-835) Verdict: REPRODUCED — one injected 8-byte HCI event permanently wedges the kernel.

Root cause

hci_event_num_compl_pkts() (sys/netbt/hci_event.c:380-405) takes the attacker-controlled compl_pkts count from the event and passes it unvalidated to hci_acl_complete(link, num) (sys/netbt/hci_event.c:393).

hci_acl_complete() (sys/netbt/hci_link.c:708-748) loops:

while (num > 0) {
        pdu = TAILQ_FIRST(&link->hl_txq);
        if (pdu == NULL) { ...; return; }
        if (num >= pdu->lp_pending) {
                num -= pdu->lp_pending;
                pdu->lp_pending = 0;
                if (IF_QEMPTY(&pdu->lp_data)) { ...remove/complete... }
                /* else: NOTHING — pdu stays, lp_pending now 0 */
        } else { ... }
}

If the head PDU has lp_pending == 0 with data still queued — the normal state whenever a PDU is queued while the controller reported zero free buffers (hci_acl_start() returns early at sys/netbt/hci_link.c:631-632) — then num -= 0 never decrements num, the queue never changes, and the loop never terminates. Any num >= 1 wedges the bluetooth NETISR thread (btintr() → hci_intr() → hci_event(), sys/netbt/bt_input.c:31-40, sys/netbt/hci_unit.c:329-352) while it holds the mplock (sys/netbt/bt_input.c:36), starving the kernel. This is distinct from the pass-1 parse-loop findings (DF-0558): different function, different root cause (no-progress iteration vs. unbounded parse).

Also fixed here: chan->lc_pending-- (sys/netbt/hci_link.c:734) is a uint8_t that can underflow to 0xFF when completion credit exceeds outstanding fragments, permanently stalling the L2CAP channel (l2cap_lower.c:174, l2cap_upper.c:244 both gate on lc_pending == 0).

Threat model

The event source is the Bluetooth controller (or anything able to inject HCI events to the host: malicious/compromised controller firmware, hostile USB device presenting a bt controller, HCI transport injection). No authentication exists on the HCI transport. Net effect from ONE well-formed 8-byte event: total system unavailability (hard reset required).

Build & run (inside the guest, as root)

cd /root/hcih && sh build.sh     # copies VERBATIM /usr/src/sys/netbt sources,
                                 # builds hci_event_harness.ko
kldload ./hci_event_harness.ko
sysctl hw.hcih_setup=1           # attach fake unit + ACL link #5 (OPEN)
sysctl hw.hcih_arm_pdu=1         # queue 1 unsent PDU fragment, lp_pending=0
sysctl hw.hcih_fire_numcompl=1   # inject Num_Compl_Pkts(handle=5, num=1)

Expected result (baseline)

Console prints the pre-fire state, the injection marker — then goes silent; the guest stops responding entirely (ssh banner timeout, vm.sh status ⇒ down). No panic: a livelock. See run.log.

Fix validation

Apply fix.diff (progress guard in hci_acl_complete + lc_pending underflow guard) to /usr/src/sys/netbt, rebuild the harness (build.sh copies the patched sources verbatim), rerun the identical trigger: the sysctl returns (SYSCTL_RC=0), the guest stays alive and keeps processing further triggers (fix_run.log). The guard's execution is directly evidenced by the intermediate fix build (fix_guard_panic_serial.txt): its diagnostic device_get_nameunit() call faulted on the harness's fake device_t, proving the new code path is reached in netisr context. See VERDICT.md for the full narrative.

DF-5734 VERDICT — REPRODUCED (permanent kernel livelock / total system hang)

Bottom line

Reproduced, deterministic, root-caused, fix validated. A single well-formed 8-byte HCI Num_Compl_Pkts event — deliverable by any malicious/compromised Bluetooth controller or HCI-transport injector — drives hci_event_num_compl_pkts() (sys/netbt/hci_event.c:380-405) into hci_acl_complete(link, num) (sys/netbt/hci_link.c:708-748) whose completion loop can make no progress when the head PDU of the link txq has lp_pending == 0 with data still queued (the routine state for a PDU waiting for free controller buffers). The loop decrements num by 0 forever; the bluetooth NETISR thread (btintr, sys/netbt/bt_input.c:31-40) spins permanently while holding the mplock, and the guest becomes totally unresponsive — no panic, no recovery short of reset.

Why the injected path is the production path

• The KLD compiles hci_event.c, hci_link.c, hci_misc.c, hci_unit.c, bt_input.c copied verbatim from /usr/src/sys/netbt — md5s identical to the audit tree and to the guest's /usr/src (baseline: hci_event.c c3e1e3ea…, hci_link.c a2ee71c2…, hci_unit.c d7f992b1…, bt_input.c 35d12188…; recorded in build.log/setup.log).
• The harness attaches the unit through the production hci_attach() and injects the event through the production entry point hci_input_event() → netisr(NETISR_BLUETOOTH) → btintr() → hci_intr() → hci_event() — the exact path a controller driver (ubt/btuart) feeds.
• The stuck precondition (PDU queued, lp_pending == 0, data queued) is the routine production state created by hci_acl_send() whenever unit->hci_num_acl_pkts == 0: hci_acl_start() returns at sys/netbt/hci_link.c:631-632 leaving the PDU queued-but-unsent. The harness reproduces it with the production functions (hci_link_alloc + a PDU enqueued exactly as l2cap_lower.c does).

Observed sequence (run.log + serial console)

1. hw.hcih_setup=1 — unit + ACL link #5 (OPEN) attached via production hci_attach().
2. hw.hcih_arm_pdu=1 — [harness] armed: 1 PDU on link #5 txq, lp_pending=0, lp_data qlen=1.
3. hw.hcih_fire_numcompl=1 — [harness] pre-fire state: head lp_pending=0, head lp_data qlen=1; event 04 13 05 01 05 00 01 00 (Num_Compl_Pkts, handle 5, num 1) handed to hci_input_event().
4. Console prints the harness "injected" marker — then silence. The triggering sysctl never completes (hw.hcih_fire_numcompl: 0 printed, the -> 1 epilogue never appears: the syscall thread is starved too).
5. Post-trigger probes: Connection timed out during banner exchange (x2), vm.sh status ⇒ down. No panic signature anywhere on the serial console — this is a livelock, not a crash.

Distinction from the pass-1 family

DF-0558 (unbounded num_con_handles parse loop), DF-0559/0560/0561 all concern parsing trust (event length fields / KKASSERT guards) with short/malformed packets. DF-5734 is a different bug class in a different loop: the packet here is well-formed; the defect is the completion accounting state machine (hci_acl_complete) lacking a progress guarantee. Both bugs are reachable from the same event, but neither subsumes the other; the fixes are disjoint.

Impact ceiling — availability, not memory corruption

The primitive is an infinite spin in a softint thread holding the mplock: no attacker-controlled memory write occurs before the spin (the loop body only touches num, pdu->lp_pending and the PDU list head). There is no slab-groom/forge route from this bug. Adjacent accounting corruption (chan->lc_pending uint8_t underflow, sys/netbt/hci_link.c:734) only poisons flow control (channel stall), not memory layout. Impact = permanent, unauthenticated total-system DoS from the controller side.

Fix validation

fix.diff adds a no-progress guard (if (pdu->lp_pending == 0) return;) and an lc_pending underflow guard. Applied to the guest's /usr/src/sys/netbt, harness rebuilt against the patched sources, identical trigger re-run:

• SYSCTL_RC=0, ALIVE_AFTER_3S, guest fully responsive (fix_run.log).
• Link-state transition observed on the fixed build proves the guard path executes: after the event, the armed PDU moved from lp_pending=0, qlen=1 to lp_pending=1, qlen=0 — i.e. hci_acl_complete() returned via the new guard, hci_event_num_compl_pkts() then credited unit->hci_num_acl_pkts += 1 and hci_acl_start() transmitted the fragment (sys/netbt/hci_link.c:646-669).
• Direct proof the guard is reached in netisr context: the first fix-build attempt used device_get_nameunit() in the guard's diagnostic kprintf and panicked inside that call evaluating the argument (fix_guard_panic_serial.txt: Stopped at device_get_nameunit: movq 0x58(%rdi),%rax) — the guard ran; the print argument was a harness artifact (fake device_t). The final guard print (device-independent) does not appear in msgbuf — netisr-context kprintf output is dropped by the console layer on this guest — but the state transition above is the behavioral proof.
• Normal completion still works post-fix: a follow-up Num_Compl_Pkts on a PDU with lp_pending=1, qlen=0 completed it and freed the PDU cleanly (guest stayed alive through three more triggers on the same boot).

Reproduction & stress

Baseline wedge reproduced on the first firing; repeated probes confirmed permanence (no recovery over ~2 minutes). Post-fix, the same trigger ran cleanly twice on one boot alongside the DF-5735/DF-5736 triggers.

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.