CVE-2024-34727 AI-generated analysis
platform/packages/modules/Bluetooth, Bluetooth stack SDP (system/stack/sdp)
Adds discovery-attribute length checks to sdpu_compare_uuid_with_attr (system/stack/sdp/sdp_utils.cc). A UUID is now compared with a tSDP_DISC_ATTR only when SDP_DISC_ATTR_LEN matches the UUID size (2, 4 or 16 bytes). Otherwise the function logs an error and returns false.
Root cause
sdpu_compare_uuid_with_attr chose the comparison width only from the local Uuid's shortest representation size (GetShortestRepresentationSize). It never checked the discovery attribute's encoded length (SDP_DISC_ATTR_LEN(p_attr->attr_len_type)). On the 128-bit path it ran memcmp over Uuid::kNumBytes128 (16) bytes of p_attr->attr_value.v.array whatever the attribute's actual size. The commit message says a fuzzer found a heap-buffer overflow (an out-of-bounds comparison) and that it comes from comparing a 128-bit UUID with a discovery attribute of some other, invalid size. The 16-bit and 32-bit paths also read attr_value.v.u16 and v.u32 without checking that the attribute held a 2-byte or 4-byte value.
How the fix works
- system/stack/sdp/sdp_utils.cc:sdpu_compare_uuid_with_attr, len == 2 case: compares uuid.As16Bit() with p_attr->attr_value.v.u16 only when SDP_DISC_ATTR_LEN(p_attr->attr_len_type) == Uuid::kNumBytes16. Otherwise it logs 'invalid length for discovery attribute' and returns false.
- Same function, len == 4 case: compares uuid.As32Bit() with p_attr->attr_value.v.u32 only when SDP_DISC_ATTR_LEN(p_attr->attr_len_type) == Uuid::kNumBytes32. Otherwise it logs and returns false.
- Same function, 128-bit fallthrough: before the existing memcmp of Uuid::kNumBytes128 bytes against p_attr->attr_value.v.array, it now requires SDP_DISC_ATTR_LEN(p_attr->attr_len_type) == Uuid::kNumBytes128. Otherwise it logs and returns false.
- Single-commit fix that touches only this function (22 insertions, 2 deletions). It makes no header or data-structure changes.
Completeness
- Covers all three comparison widths (2, 4 and 16 bytes) inside sdpu_compare_uuid_with_attr by gating each one on the attribute's encoded length.
- The fix adds length checks only. The material does not show whether the attribute's type is checked anywhere else.
- Only this function changes. The neighbouring sdpu_compare_uuid_arrays (named in the context header) is not touched. Its body is not shown, so the material does not show whether it needs similar handling.
- Sizes that do not match are no longer compared: for example, a 16-bit local UUID against an attribute whose length is not 2 now returns false. Before the fix, the code compared it against attr_value.v.u16.
Behavior changes
- sdpu_compare_uuid_with_attr now returns false (no match) whenever the discovery attribute's length differs from the local UUID's shortest representation size. Before the fix it compared anyway.
- Each mismatch now emits the LOG(ERROR) message 'invalid length for discovery attribute'.
- No API, data-structure or wire-format changes.
Per major
- Android 14: Same fix: commit 6afad4b377b5 landed in android-security-14.0.0_r11 (cherry-picked from internal commit 7bbdb139bf91, Ignore-AOSP-First). At android-security-14.0.0_r29, 5 of 7 lines of the patched region are present. The material does not show what differs in the other lines.
- Android 15: Not affected per the bulletin. At android-security-15.0.0_r17, 5 of 7 lines of the patched region are present. The material does not show the exact code.
- Android 16: Not affected per the bulletin. At android-security-16.0.0_r8, 4 of 7 lines of the patched region are present. The material does not show the exact code.
- Android 17: Not affected per the bulletin. At android-security-17.0.0_r1, 4 of 7 lines of the patched region are present. The material does not show the exact code.
Unknowns
- Callers of sdpu_compare_uuid_with_attr and the exact path that reaches it (not shown; index search found none).
- Where tSDP_DISC_ATTR data comes from, and the allocation size of attr_value.v.array (how far the pre-fix memcmp could over-read).
- Whether the attribute type (as opposed to length) is checked before this comparison.
- What the partial line matches on 14 r29 and on 15, 16 and 17 mean for the exact code present.
- The Android 13 fix commit and status (listed as affected but not in the material).