wireless/bluetooth: Validate the L2CAP header on the first ACL fragment.

[acassis]

Summary

bt_conn_receive() read the 4-octet L2CAP header out of the first fragment of a PDU without checking that 4 octets had been received, and then computed the outstanding length by subtracting the fragment length from the declared PDU length.

Two problems follow. A fragment shorter than the header was parsed from whatever happened to follow it in the buffer. And a fragment carrying more data than the PDU it declares made the subtraction wrap, because conn->rx_len is 16 bits: the connection was then left expecting up to 65535 further octets, holding the partial PDU and accumulating later fragments against an expectation that could never be satisfied.

Check that the fragment is long enough to hold a header before reading it, and that it does not exceed the PDU it declares before computing what remains. Drop the fragment and reset the reassembly state otherwise.

Impact

Improvement

Testing

Before this change, a fragment of 10 octets declaring a 2-octet PDU:

  bt_conn_receive: handle 1 len 10 flags 02
  bt_conn_receive: First, len 10 final 2
  bt_conn_receive: rx_len 65532

4 + 2 - 10 is -4, so the connection is left expecting 65532 further
octets and holding the fragment. A 2-octet fragment sent next, shorter
than the header itself:

  bt_conn_receive: handle 1 len 2 flags 02
  bt_conn_receive: First, len 2 final 2
  bt_conn_receive: ERROR: Unexpected first L2CAP frame
  bt_conn_receive: rx_len 4

The length of 2 was read from beyond the two octets that arrived, and the
connection is parked again; the "Unexpected first L2CAP frame" line is
the earlier underflow surfacing.

After, both fragments are dropped and nothing is parked:

  bt_conn_receive: First, len 10 final 2
  bt_conn_receive: ERROR: First L2CAP frame exceeds its PDU (10 > 6)
  bt_conn_receive: handle 1 len 2 flags 02
  bt_conn_receive: ERROR: First L2CAP frame too short for a header (2)

The second fragment produces no "First, len" line, because the header is
no longer read before its presence is checked.

[acassis]

@xiaoxiang781216 please review again, the CI was reporting bad alignment on original file

[github-actions]

MemBrowse Memory Report

No memory changes detected for:

• arduino-mega2560
• esp32-devkitc
• hifive1-revb
• mirtoo
• qemu-armv8a
• qemu-intel64
• rx65n-rsk2mb
• s698pm-dkit
• stm32-nucleo-f103rb

[acassis]

The issue is caused by a random esptool BUG that was fixed on version 5.3.0, adding it here:
#20235