DF-0625 — VERDICT

Verdict: NOT REPRODUCED at runtime (no BT hardware). Bug CONFIRMED in source.

Mechanism (the bug IS real in source)

ng_l2cap_l2ca_ping_req (sys/netgraph7/bluetooth/l2cap/ng_l2cap_ulpi.c:1298) validates only:

1306:   if (msg->header.arglen < sizeof(*ip)) {     /* 8-byte header fits */
1316:   if (ip->echo_size > NG_L2CAP_MAX_ECHO_SIZE) { /* echo_size <= 65531 */

and then, without checking that arglen actually contains sizeof(*ip) + echo_size bytes, passes them downstream:

1357:   _ng_l2cap_echo_req(cmd->aux, cmd->ident,
1358:       msg->data + sizeof(*ip), ip->echo_size);

The macro (ng_l2cap_cmds.h:338-340) calls m_copyback((_m), sizeof(*c), (_size), (_data)) with _size = ip->echo_size and _data = msg->data + 8. The ng_mesg was allocated as sizeof(struct ng_mesg) + arglen (ng_message.h:81), so when arglen = 8 (just the header) and echo_size = 200, the read at msg->data + 8 runs ~192 bytes past the allocation into adjacent kernel heap (bcopy in _m_copyback2, uipc_mbuf.c:2361-2386). The resulting mbuf is then queued via ng_l2cap_link_cmd + ng_l2cap_lp_deliver (ulpi.c:1366-1367) and ultimately transmitted as L2CAP Echo Request payload on the air.

The sibling ng_l2cap_l2ca_get_info_req (ulpi.c:1428+) does do an exact-match check:

1439:   if (msg->header.arglen != sizeof(*ip)) {

so the fix is to mirror that pattern in the ping handler.

Why it CANNOT be triggered on this guest

The bug path at ulpi.c:1357 requires a valid BT connection (con != NULL) at :1325 or a successful ng_l2cap_lp_con_req at :1328. The latter fails fast without an HCI lower layer:

llpi.c:87:  if (l2cap->hci == NULL || NG_HOOK_NOT_VALID(l2cap->hci)) {
llpi.c:92:      return (ENOTCONN);

On the audit guest: - No Bluetooth hardware (no USB BT dongle, no virtual BT adapter). - ng_hci / ng_ubt not loaded; no HCI hook to connect to an l2cap node. - Therefore l2cap->hci == NULL, ng_l2cap_lp_con_req returns ENOTCONN, ng_l2cap_l2ca_ping_req takes the early goto out at :1333, and the buggy _ng_l2cap_echo_req call at :1357 is never reached.

Additionally, the pre-installed /boot/kernel/netgraph.ko in the audit snapshot is ABI-incompatible with a freshly-built ng_l2cap.ko (NG_ABI_VERSION mismatch surfaced as KLD ng_l2cap.ko: depends on netgraph - not available or version mismatch), so even loading the module to confirm the path requires rebuilding netgraph.ko too. The bug path is still code-confirmed.

Classification: bug CONFIRMED in source, runtime trigger requires Bluetooth hardware/HCI emulation not present on this guest. Valid hard blocker: no harness can exercise the bug path without BT hardware or an HCI lower-layer emulation, neither of which is available on this kernel.

Realistic impact ceiling

If the bug WERE reachable (any deployment that actually uses DragonFly's Bluetooth L2CAP stack — typically embedded systems or routers with USB BT dongles):

• A local user with netgraph control access (root, or in a bluetooth group if configured) sends a crafted NGM_L2CAP_L2CA_PING with arglen=8, echo_size up to 65531, and bdaddr pointing at a Bluetooth peer the attacker controls.
• The kernel reads up to echo_size bytes of adjacent kernel heap and transmits them as the Echo Request payload.
• The attacker captures the packet at their BT peer and recovers kernel heap contents — freed ng_mesg objects, slab metadata, possibly credential structures recycled from prior allocations.

Severity Medium with C:H/S:C is appropriate IF BT hardware is present; on this guest, no demonstrated runtime impact.

Recommended fix

fix.diff adds the missing exact-match arglen validation in ng_l2cap_l2ca_ping_req, mirroring the pattern already used by the sibling ng_l2cap_l2ca_get_info_req:

if (msg->header.arglen != sizeof(*ip) + ip->echo_size) {
    NG_L2CAP_ALERT(...);
    error = EMSGSIZE;
    goto out;
}

Placed immediately after the existing echo_size cap check, so the function returns EMSGSIZE for any PING whose claimed echo data does not match the actual trailing bytes.

This matches the finding markdown's proposal (same check, same placement, same error code).

Caveats

The "no BT hardware" hard blocker applies to runtime demonstration. The fix is small, surgical, and mirrors a proven pattern in a sibling function — low regression risk. Recommended for merge regardless of the runtime reproducibility status.