DF-0558 — hci_event_num_compl_pkts unbounded loop

Verdict

NOT TESTABLE at runtime (no Bluetooth hardware) — bug CONFIRMED at source (certain). Fix authored in fix.diff; compiled cleanly as part of a combined nativekernel build (netbt.ko) carrying all four verified findings' fixes.

Mechanism (source trace, every hop cited)

hci_event() (sys/netbt/hci_event.c:160-230) is the single HCI event dispatcher. It reads the 4-byte hci_event_hdr_t, m_adjs it off, then switches on hdr.event. For HCI_EVENT_NUM_COMPL_PKTS it calls hci_event_num_compl_pkts(unit, m) at hci_event.c:186.

hci_event_num_compl_pkts() (sys/netbt/hci_event.c:368-432): - KKASSERT(m->m_pkthdr.len >= sizeof(ep)) (:376) — only verifies the 1-byte hci_num_compl_pkts_ep header is present. Reads ep.num_con_handles (a uint8_t, 0-255, attacker-controlled) and m_adjs it off (:377-378). - while (ep.num_con_handles--) (:380) — the unbounded loop. Each iteration consumes sizeof(handle)+sizeof(num) = 4 bytes via m_copydata+m_adj (:381-386) with no check that the mbuf chain still contains 4 bytes. - ep.num_con_handles is taken straight from the controller's event and is never validated against m->m_pkthdr.len (the remaining bytes), nor is hci_event_hdr_t.length (:168) consulted anywhere on this path.

If a controller (or a malicious Bluetooth adapter / injected HCI event) sends num_con_handles = N but fewer than 4*N follow-on bytes, the loop runs off the end of the mbuf chain: - m_copydata on an empty/exhausted chain returns with m == NULL and KASSERT(m != NULL) trips (INVARIANTS ON in X86_64_GENERIC, :56) → panic; or - on a non-INVARIANTS kernel a NULL-deref in m_copydata/m_adj → panic.

INVARIANTS is ON in the default X86_64_GENERIC, so the panic is the production-default behavior — a remote unauthenticated Bluetooth DoS (the event can arrive from any paired/scanning controller with no application-level auth).

Why not reproduced live (the realistic constraint)

The QEMU/KVM audit guest has no Bluetooth controller hardware. netbt is shipped only as the netbt.ko module (NOT compiled into the kernel; nm on /boot/kernel/kernel shows no hci_event_* symbols), and is not loaded. Crucially, even loading netbt.ko does not create a struct hci_unit — that only happens when a real controller driver (ubt/bt3c/bcsp/…) attaches. With no unit, hci_input() is never called and hci_event() is unreachable. So no harness on this guest can deliver a crafted HCI event; the bug is a genuine latent/net path that is only live on a machine with a Bluetooth radio. The netbt-twin finding DF-0543 (netgraph7 BT) is the same defect in the older stack.

Fix (fix.diff)

Add an explicit upfront bounds check after reading ep, before the loop: bound ep.num_con_handles * (sizeof(handle)+sizeof(num)) against the remaining m->m_pkthdr.len, log + return on a malformed event. This is the minimal targeted fix: it makes the loop provably unable to run off the chain and supersedes reliance on the INVARIANTS-only KKASSERT.

PoC changes

findings/poc/DF-0558/ was empty on arrival (no reviewer PoC). This runner authored: fix.diff, build.sh, run.sh, README.md, VERDICT.md, manifest.json, env.txt.