# DF-0566 — Bluetooth ACL reassembly uint16_t want overflow

## Bug
`hci_acl_recv` (sys/netbt/hci_link.c:417) accumulates ACL fragments
until a complete L2CAP frame is ready. The completion test at line 509
is:

```c
uint16_t want;            /* line 421 -- 16-bit type */
...
m_copydata(m, 0, sizeof(want), &want);
want = letoh16(want) + sizeof(l2cap_hdr_t) - got;   /* line 509 */

if (want > 0)              /* line 511 */
    return;
...
if (want == 0) {           /* line 516 */
    l2cap_recv_frame(m, link);
    return;
}
```

The right-hand side is computed in `size_t` (because of
`sizeof(l2cap_hdr_t)`), then **truncated to uint16_t** on assignment.
When an HCI ACL START frame or accumulated fragments **overshoot** the
claimed L2CAP length (`got > letoh16(want) + 4`), the subtraction
underflows:

- Arithmetic in size_t: huge 64-bit value
- Truncated to uint16_t: 16-bit pattern (e.g. 0xFF9C for a -100
  overshoot)
- `want > 0` is now true → `return` without delivering or freeing the
  frame

Consequences (DoS, no memory corruption since `want` is just a local
variable):
1. The half-completed frame is stuck in `link->hl_rxp` indefinitely;
   no L2CAP traffic for that handle is ever delivered.
2. Every subsequent FRAGMENT is `m_cat`'d onto `hl_rxp` (line 496)
   without bound, growing it indefinitely → unbounded kernel memory
   consumption.

The opposite-direction bug (got MUCH larger than claimed L2CAP length
due to malicious HCI input) is the more interesting primitive but is
gated behind actual Bluetooth hardware.

## Reachability on this guest
The trigger path requires an HCI ACL packet to reach `hci_acl_recv`.
That function is only called from `hci_unit.c:382` (the HCI unit's RX
queue, drained by the Bluetooth hardware driver). There is **no
virtual Bluetooth device** on DragonFlyBSD and **no in-kernel path
from userspace to hci_acl_recv** — HCI sockets (BTPROTO_HCI) bind to
an existing unit and exchange control commands, they do not inject RX
packets.

The guest has no Bluetooth hardware (`ng_ubt` / `bt3c` / etc. not
loaded; no USB BT dongle). Therefore this bug **cannot be reproduced
at runtime on this guest**. The bug is real and traced line-by-line
into the source (see VERDICT.md); it is a latent defect that would
manifest on any DFly system with a Bluetooth HCI device under
adversarial RF/peer input.

## Fix
Use a wider signed type for the arithmetic (the L2CAP `length` field
read stays 16-bit, but the comparison value is computed in `int`).
See fix.diff. The fix preserves the 2-byte `m_copydata` and fixes the
truncation.