Bluetooth Classic SDP parser truncation bug in bt_sdp_parse_attribute() leads to reachable assertion and possible out-of-bounds read

An attacker sends a malformed Bluetooth Classic SDP attribute containing only 3 bytes (e.g., `09 00 09`) to a Zephyr device. The SDP parser in `bt_sdp_parse_attribute()` accepts the buffer after verifying the first 3 bytes (attribute type and id) but then unconditionally pulls a fourth byte for the value type without checking remaining length [ref_id=1]. This triggers a reachable assertion in `net_buf_simple_pull()`, causing a kernel panic (denial of service). In non-assert builds, the same path may continue past the buffer end, leading to an out-of-bounds read and undefined behavior [ref_id=1].

The bug resides in `subsys/bluetooth/host/classic/sdp.c` in the function `bt_sdp_parse_attribute()`. The parser accepts a buffer once it contains the 1-byte attribute type and 2-byte attribute id, but then unconditionally pulls an additional byte for the value type without verifying that byte is present. This reaches `net_buf_simple_pull()` in `lib/net_buf/buf_simple.c`, which triggers `__ASSERT_NO_MSG(buf->len >= len)` and a kernel panic in assert-enabled builds [ref_id=1].

The advisory recommends that `bt_sdp_parse_attribute()` reject truncated attributes before consuming any mandatory initial fields. The parser should validate that the buffer contains all fields required by the initial parse step before pulling type, attribute id, and value-type bytes, and later parsing steps should use explicit remaining-length checks before each pull instead of relying on `net_buf` assertions [ref_id=1]. The patch series (merged on main, v4.4-branch, and v4.3-branch) implements these length checks to prevent the reachable assertion and out-of-bounds read.