# DF-0566 — Verdict: NOT TESTABLE (no Bluetooth hardware)

## Verdict
CONFIRMED by source trace; NOT TESTABLE at runtime on this guest
(no Bluetooth HCI device or virtual BT path; the only caller of
`hci_acl_recv` is the HCI unit RX queue fed by a BT driver).

## Bug confirmation (source-only)
- sys/netbt/hci_link.c:421 — `uint16_t want;` (16-bit type)
- sys/netbt/hci_link.c:508 — `m_copydata(m, 0, sizeof(want), &want);`
  reads 2 bytes (the L2CAP `length` field). Correct.
- sys/netbt/hci_link.c:509 — `want = letoh16(want) + sizeof(l2cap_hdr_t)
  - got;` arithmetic in size_t (because `sizeof` returns size_t),
  truncated to uint16_t on assignment.
- sys/netbt/l2cap.h:219-220 — `l2cap_hdr_t` is `{ uint16_t length;
  uint16_t dcid; }` (4 bytes packed). So `sizeof(l2cap_hdr_t) == 4`.
- sys/netbt/hci_link.c:511 — `if (want > 0) return;` takes the
  "incomplete" branch forever once `want` has wrapped, because the
  truncated value is non-zero.
- sys/netbt/hci_link.c:516 — `if (want == 0)` deliver branch never
  taken.
- sys/netbt/hci_link.c:495-498 — fragment branch: `got = m->m_pkthdr.len
  + link->hl_rxp->m_pkthdr.len; m_cat(...); m->m_pkthdr.len = got;`
  — subsequent fragments pile onto hl_rxp without bound.

The reviewer's analysis is correct. The truncation math is real.

## Trigger unreachability on this guest
- `hci_acl_recv` is called ONLY from `sys/netbt/hci_unit.c:382` which
  dequeues from `unit->hci_aclrxq`.
- The RX queue is fed by Bluetooth HCI drivers (e.g. `ng_ubt`,
  `bt3c`). None are loaded on this guest and no virtual BT device
  exists in DFly.
- The BTPROTO_HCI socket family (`sys/netbt/hci_socket.c`) binds to an
  existing unit; it does NOT inject RX packets.
- Confirmed by `kldstat`: only ehci/xhci USB host controllers, no BT
  modules. No BT hardware in QEMU config.

Therefore: this is a **latent bug**. To exercise it on a DFly system
requires either:
- A physical USB BT dongle plugged in, with a malicious peer that
  sends ACL packets overshooting the L2CAP length, OR
- A kernel-module test harness that allocates a `struct hci_unit`,
  synthesizes ACL mbufs, and calls `hci_acl_recv` directly.

The latter would be a developer-only characterization (the
`kldload`-based test harness is explicitly OUT OF SCOPE for
escalation per the bright-line rule, but is mentioned here as the
concrete next step for a maintainer wanting to exercise the path).

## Impact ceiling
- Per-link DoS: L2CAP traffic stalls; hl_rxp grows unbounded.
- No memory corruption primitive (the truncated `want` is a local;
  the only effect is wrong control flow + unbounded m_cat).
- Affects only systems with active Bluetooth HCI (small subset of
  DFly deployments).

## Fix validation
Not testable at runtime (no BT hardware). Validated by:
1. Source line-by-line trace (above).
2. fix.diff applies cleanly with `patch -p1 --dry-run` against
   sys/netbt/hci_link.c (single hunk, line 509).

## Kernel references
- sys/netbt/hci_link.c:421 — uint16_t want declaration
- sys/netbt/hci_link.c:508 — m_copydata read (correct)
- sys/netbt/hci_link.c:509 — truncating arithmetic (BUG)
- sys/netbt/hci_link.c:511 — broken `want > 0` return
- sys/netbt/hci_link.c:516 — unreachable `want == 0` deliver
- sys/netbt/hci_link.c:495-498 — fragment pile-on
- sys/netbt/l2cap.h:219-220 — l2cap_hdr_t is 4 bytes
- sys/netbt/hci_unit.c:382 — sole caller, fed by BT driver RX queue