DF-5764 — l2cap_start() unbalanced lc_pending on hci_acl_send() failure

sys/netbt/l2cap_lower.c:203-204 (pass 2)

What

l2cap_start() raises chan->lc_pending before the fallible hci_acl_send() call:

IF_DEQUEUE(&chan->lc_txq, m);           /* l2cap_lower.c:195 */
...
chan->lc_pending++;             /* :203 */
return hci_acl_send(m, chan->lc_link, chan);    /* :204 — can FAIL */

hci_acl_send() has two failure returns that free m and create no l2cap_pdu: ENETDOWN (link->hl_state == HCI_LINK_CLOSED, hci_link.c:546-549) and ENOMEM (zalloc/m_split, hci_link.c:551-553, 568-570, 592-599). lc_pending is only ever decremented for a PDU found on link->hl_txq with lp_chan == chan (hci_acl_complete, hci_link.c:730-742) — a PDU that does not exist. The counter is permanently inflated for the channel's lifetime, and the leak COMPOUNDS (every later l2cap_start() caller — l2cap_send(), hci_acl_complete(), hci_acl_start() streaming — burns another blackholed SDU and raises it again).

Consequences, each gated on lc_pending == 0:

1. l2cap_send() (l2cap_upper.c:398) never calls l2cap_start() again: every further send(2) silently succeeds into lc_txq and nothing is ever transmitted — permanent TX blackhole for the connection.
2. l2cap_disconnect(chan, linger) (l2cap_upper.c:244) never starts the graceful L2CAP disconnect handshake — the channel can only die by force-close (close(2) → detach).
3. l2cap_start()'s own L2CAP_SHUTDOWN flush path (l2cap_lower.c:173-179) is unreachable.

Evidence (findings/poc/DF-5764/)

KLD rig (l2pw_harness.ko) compiling the VERBATIM production l2cap_upper.c, l2cap_lower.c (file under audit), l2cap_misc.c, l2cap_signal.c and hci_link.c (so the ENETDOWN failure branch under test is production code) against minimal stubs. Channel/link state is exactly what production builds: l2cap_attach() + l2cap_cid_alloc() + one hci_acl_open() reference + L2CAP_OPEN on a HCI_LINK_CLOSED link (what hci_link_alloc() returns — and the state left behind by the DF-5737 teardown race window; an ENOMEM under memory pressure produces the identical imbalance).

Build & run INSIDE the guest as root:

cd /root/l2pw && ./build.sh && ./run.sh

EXPECTED (unfixed): hw.l2pw_wedge_proven = 1, hw.l2pw_ctl_ok = 1, no panic. Round prints go to the console (run.sh dumps them):

W1 send#1 ret=50 (ENETDOWN=50) lc_pending=1 link_txq_empty=1 lc_txq_len=0
W1 PASS: pending==1 but NO pdu exists on the link that could ever decrement it
W2 64 more sends: ret==0 all, lc_txq_len=64 (blackholed) lc_pending=1
W3 l2cap_disconnect(linger) ret=0 state=5 (OPEN=5) reqs_empty=1   <- handshake dead
W4 l2cap_start ret=50 lc_txq_len=63 lc_pending=2                   <- leak compounds

The CONTROL round (link OPEN + production hci_acl_complete()) proves the healthy lc_pending 1→0 round-trip works and that the SHUTDOWN disconnect fires exactly when pending reaches 0 — i.e. the wedge is caused precisely by the failed-send increment.

Fix

fix.diff (validated): only count the PDU when one was actually created —

-   chan->lc_pending++;
-   return hci_acl_send(m, chan->lc_link, chan);
+   err = hci_acl_send(m, chan->lc_link, chan);
+   if (err == 0)
+       chan->lc_pending++;
+   return err;

Apply to /usr/src inside the guest, rebuild the module (./build.sh re-copies the verbatim source), re-run: wedge_proven flips to 0 (failed send leaves lc_pending == 0; further sends get honest ENETDOWN per call with an empty queue; l2cap_disconnect() closes the channel), ctl_ok stays 1. See fix_run.log.

Impact

Local/remote DoS of an established L2CAP connection's transmit path (silent data blackhole + stuck graceful-disconnect), triggerable by any hci_acl_send() failure while OPEN — ENOMEM under memory pressure, or ENETDOWN in the link-teardown window (co-fires with DF-5737's race). No memory corruption; stuck mbufs are bounded by the socket send buffer (l2cap_ssend appends the original to so_snd before handing the copy down). Severity Low.

DF-5764 — VERDICT

Status: reproduced (KLD rig, production code compiled verbatim; fix validated) Impact: dos (connection-level TX blackhole + graceful-disconnect disabled) Confidence: certain (defect proven deterministically through shipped code paths; fix discriminates baseline vs patched)

Root cause (path:line)

sys/netbt/l2cap_lower.c:195-204 — l2cap_start():

IF_DEQUEUE(&chan->lc_txq, m);           /* :195  m leaves the channel queue */
KKASSERT(chan->lc_link != NULL);        /* :197 */
KKASSERT(m != NULL);                    /* :198 */
chan->lc_pending++;                     /* :203  raised BEFORE the fallible call */
return hci_acl_send(m, chan->lc_link, chan);   /* :204  ENETDOWN / ENOMEM */

hci_acl_send() failure returns free m and create no l2cap_pdu:

• ENETDOWN — link->hl_state == HCI_LINK_CLOSED → m_freem(m); return ENETDOWN; (sys/netbt/hci_link.c:546-549)
• ENOMEM — zalloc(l2cap_pdu_pool) NULL (hci_link.c:551-553) or m_split() NULL (hci_link.c:566-570) → nomem: frees everything (hci_link.c:592-599)

lc_pending is only decremented in hci_acl_complete() for a PDU found on link->hl_txq with lp_chan == chan (hci_link.c:730-742). After a failed send no such PDU exists, so the counter is permanently inflated — and every subsequent l2cap_start() invocation (from l2cap_send() when lc_pending == 0 never fires; but also from hci_acl_complete()/hci_acl_start() streaming callers) that dequeues another SDU increments it again: compounding.

All three consumers of lc_pending gate on == 0:

Reproduction (baseline)

Rig: l2pw_harness.ko — VERBATIM production l2cap_upper.c, l2cap_lower.c, l2cap_misc.c, l2cap_signal.c, hci_link.c (the failure branch under test is production code), minimal stubs for the transport/socket layers (md5s recorded in setup.log). Channel state built with production calls: l2cap_attach() + l2cap_cid_alloc() + one hci_acl_open()-style reference + L2CAP_OPEN (post-config state, l2cap_signal.c:605) on a link in HCI_LINK_CLOSED (what hci_link_alloc() returns, hci_link.c:909 — and the state the DF-5737 teardown race window leaves behind; ENOMEM under pressure hits the same imbalance).

Observed (run.log, decisive lines):

l2pw: W1 send#1 ret=50 (ENETDOWN=50) lc_pending=1 link_txq_empty=1 lc_txq_len=0
l2pw: W1 PASS: pending==1 but NO pdu exists ...
l2pw: W2 64 more sends: ret==0 all, lc_txq_len=64 (blackholed) lc_pending=1
l2pw: W3 l2cap_disconnect(linger) ret=0 state=5 (OPEN=5) reqs_empty=1 SHUTDOWN=1
l2pw: W4 l2cap_start ret=50 lc_txq_len=63 lc_pending=2 state=5   <- compounding
l2pw: WEDGE ROUND PROVEN (assertion failures: 0)
l2pw: CONTROL ROUND OK (assertion failures: 0)                    <- healthy accounting works

hw.l2pw_wedge_proven = 1, hw.l2pw_ctl_ok = 1, no panic. The CONTROL round (link OPEN + production hci_acl_complete(link,1)) shows lc_pending 1→0 round-trip works and the SHUTDOWN disconnect fires at 0 — proving the wedge is caused precisely by the failed-send increment, not by rig artifacts.

Fix validation

fix.diff applied to the guest's /usr/src/sys/netbt/l2cap_lower.c (increment only on success), module rebuilt from the re-copied verbatim source, exact same PoC re-run (fix_run.log):

fix_status: fixed.

Why not higher severity

• No memory corruption: the counter is a uint8_t bookkeeping field; nothing dereferences through it.
• Stuck mbufs are bounded: l2cap_ssend() (l2cap_socket.c:450-451) appends the original mbuf to so_snd (flow-controlled by sbspace) and only the copy goes down; the wedged copies sit in lc_txq (freed at detach, l2cap_upper.c:275 IF_DRAIN).
• Trigger requires an established (OPEN) channel plus one hci_acl_send() failure: ENOMEM under memory pressure, or ENETDOWN in the link-teardown window (co-fires with DF-5737's race — on a racing-teardown box the wedge is one of the outcomes of the same window).
• Recovery exists: close(2) → detach → force-close reclaims everything.

Scope note: the ENETDOWN-via-teardown-race window itself is DF-5737's (owned there). This finding is the error-path accounting defect in l2cap_lower.c that makes any failure permanent for the channel — filed narrowly on the ENOMEM/all-failures root cause at l2cap_lower.c:203-204.

What was checked and found clean in this file (pass-2 negatives)

• l2cap_recv_frame 4-byte m_copydata (l2cap_lower.c:115): the sole caller hci_acl_recv guarantees ≥ 4 payload bytes (START short-frame drop, hci_link.c:476-481; fragments only append). DF m_copydata (sys/kern/uipc_mbuf.c:1671-1696) is bounds-checked with always-on KASSERTs anyway; no OOB on this path.
• l2cap_recv_frame length check (:124): dead but harmless — want == 0 exactness (hci_link.c:509-517) means only exact frames are delivered; the overshoot case stalls in reassembly (owned by DF-0566).
• Dispatch ordering (:127-142): SIGNAL_CID handoff guarded by l2cap_recv_signal's own loop guards (l2cap_signal.c:73-83) and internal left arithmetic in the CONFIG handlers (l2cap_signal.c:424-431, 632-641); data-CID dispatch requires lc_link == link && lc_state == L2CAP_OPEN with globally-unique lcids (l2cap_cid_alloc, l2cap_misc.c:207-236). Sound.
• l2cap_close ordering (:96-98): setting lc_state = L2CAP_CLOSED BEFORE hci_acl_close() makes any re-entrant hci_link_free() channel walk (hci_link.c:944-951) a no-op for this channel — single-threaded safe; no non-race path reaches :78/:86 with lc_link == NULL (all lc_state != CLOSED transitions assign lc_link first: l2cap_upper.c:171/178/190, l2cap_signal.c:289/302).
• No single-threaded re-entrant hci_link_free via l2cap_close: every hci_link_free entry with hl_refcnt > 0 (discon_compl hci_event.c:631, con_compl failure hci_event.c:559, RESET completion hci_event.c:1068) runs with link state OPEN/WAIT_*, so the inner hci_acl_close arms the expiry callout instead of recursing. The concurrent-callout variant is DF-5739's.
• lc_pending uint8_t overflow: in-flight PDUs per channel ≤ 2-3 by construction (streaming prefetch only); unreachable.
• The racy :69 state read and the unlocked lc_link lifetime are owned by DF-5749 / DF-5737 respectively (not re-reported).

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.