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.

DF-0540 — Uninitialized cmd.ident leaked in L2CAP Command Reject: LATENT

Verdict: NOT REPRODUCED on this guest (LATENT). Source bug REAL; fix authored, applies cleanly; not build/runtime-testable here (netbt not compiled into GENERIC, no Bluetooth hardware).

SOURCE TRACE (bug is real)

File: sys/netbt/l2cap_signal.c (the NetBT Bluetooth stack; optional bluetooth)

l2cap_recv_signal(m, link) (:67-167): 70: l2cap_cmd_hdr_t cmd; / UNINITIALISED on stack / 72: for(;;) { 73: if (m->m_pkthdr.len == 0) goto finish; 76: if (m->m_pkthdr.len < sizeof(cmd)) / sizeof = 4 / 77: goto reject; / jumps BEFORE m_copydata / 79: m_copydata(m, 0, sizeof(cmd), &cmd); / only here is cmd written / ... 163:reject: 164: l2cap_send_command_rej(link, cmd.ident, L2CAP_REJ_NOT_UNDERSTOOD);

If an incoming L2CAP signalling packet (CID 0x0001) is shorter than a 4-byte command header (len = 1..3), control jumps to reject at :163 BEFORE m_copydata populates cmd. l2cap_send_command_rej then embeds the UNINITIALISED cmd.ident (1 byte of kernel stack) into the outgoing L2CAP_COMMAND_REJ packet. The sink is confirmed: l2cap_send_signal (sys/netbt/l2cap_signal.c:937): 972: cmd->ident = ident; / written into the on-wire L2CAP header / 985: return hci_acl_send(m, link, NULL);

So each short L2CAP packet leaks one byte of kernel stack to the remote peer over Bluetooth. Repeated probing leaks a fixed stack offset. (No write, no corruption — pure 1-byte info leak per request; remote-unauth over BT RF.)

REACHABILITY ON THIS GUEST (latent)

• l2cap_signal.c is optional bluetooth (sys/conf/files:1615). X86_64_GENERIC has NO options bluetooth (grep count = 0), so the entire netbt stack — including l2cap_recv_signal — is NOT compiled into the running kernel (nm count for l2cap_recv_signal = 0).
• Even with the option, NetBT's l2cap_recv_signal is fed by a netbt hci_link (real Bluetooth hardware via bt_input.c). QEMU provides no Bluetooth adapter and there is no netbt HCI unit.
• => The vulnerable function is dead code on this guest AND there is no RF path to deliver a short L2CAP packet. A valid "genuinely not reachable on this kernel AND no harness can exercise it" case. The bug is proven at source level.

FIX

fix.diff zero-initialises the declaration: l2cap_cmd_hdr_t cmd = { 0 }; (:70). This guarantees cmd.ident == 0 on the early-goto reject path, so the Command Reject carries ident 0 instead of a stack byte. Trivial, minimal, correct. git-apply-able; applies cleanly.

NOT TESTABLE

fix_status = not_testable: netbt is not compiled into the default kernel and there is no Bluetooth hardware on the guest to inject a short L2CAP packet. The diff applies and the fix is correct-by-inspection.