# DF-0540 — Uninitialized `cmd.ident` leaked in L2CAP Command Reject

**Verdict:** LATENT on this guest (source bug real; not runtime-exercisable).
**Fix authored** (`fix.diff`, applies cleanly; `not_testable` — netbt not built).

## Bug
`l2cap_recv_signal()` (`sys/netbt/l2cap_signal.c:67`) declares
`l2cap_cmd_hdr_t cmd;` **uninitialized** on the stack (`:70`). If the incoming
L2CAP packet is shorter than a 4-byte command header, `m->m_pkthdr.len <
sizeof(cmd)` at `:76` jumps to `reject:` at `:163` **before** `m_copydata`
(`:79`) populates `cmd`. `l2cap_send_command_rej(link, cmd.ident, …)` (`:164`)
then embeds the **uninitialized** `cmd.ident` (1 byte of kernel stack) into the
outgoing `L2CAP_COMMAND_REJ` packet — confirmed sink at `l2cap_send_signal:972`
(`cmd->ident = ident;` then `hci_acl_send`). One byte of kernel stack leaked to
the remote Bluetooth peer per short packet.

## Reachability
**Latent on this guest.** `l2cap_signal.c` is `optional bluetooth`
(`sys/conf/files:1615`); `X86_64_GENERIC` has no `options bluetooth`, so
`l2cap_recv_signal` is not compiled into the running kernel (0 symbols), and
there is no Bluetooth HCI hardware to inject a short L2CAP packet.

## Fix
`fix.diff`: `l2cap_cmd_hdr_t cmd = { 0 };` (`:70`) — guarantees `cmd.ident == 0`
on the early-`reject` path. Trivial, minimal, correct. Applies cleanly; not
build-validated (netbt requires `options bluetooth` + BT hardware).

See `VERDICT.md` for the full line-cited trace.