CVE-2025-26441 AI-generated analysis
platform/packages/modules/Bluetooth, system/stack/sdp (SDP discovery, libbluetooth)
Adds a one-byte bounds check at the top of add_attr in system/stack/sdp/sdp_discovery.cc so the attribute type byte is not read when no bytes remain before p_end.
Root cause
add_attr(p, p_end, ...) in system/stack/sdp/sdp_discovery.cc ran `type = *p++;` without first checking that at least one byte remained before p_end. The commit message says that in exceptional cases add_attr can be passed a p pointer 'one byte short of its p_end pointer', which leads to an out-of-bounds read of the next attribute's type byte. The added check rejects p >= p_end. The existing checks (the NULL return from sdpu_get_len_from_type, `(p + attr_len) > p_end`, and `p_attr_end > p_end`) all run after that first dereference.
How the fix works
- system/stack/sdp/sdp_discovery.cc:add_attr: a new check `if (p + sizeof(uint8_t) > p_end)` is placed after SDP_ADDITIONAL_LIST_MASK is cleared from nest_level and before `type = *p++;`. When it fails, the function logs a warning (SDP_TRACE_WARNING on the 14 and 16 commits, log::warn on 15) and returns NULL.
- Returning NULL matches how add_attr already handles failure in its later length checks.
- Single commit: 5 inserted lines, no other files touched.
Completeness
- Guards the initial type-byte read, which was the read left unguarded before the existing length checks in the add_attr code shown (through line 886). The rest of add_attr is not shown in the material.
- The check is defensive and sits in the callee. It does not change the callers that can pass add_attr an exhausted p. Those call sites are not in the material.
- The log call passes __func__ as an extra argument to a format string with no %s placeholder ("bad arguments to add_addr"). This is cosmetic only.
Behavior changes
- When called with no remaining bytes, add_attr now logs a warning and returns NULL instead of reading past the buffer.
- Well-formed input that has at least one byte remaining is not affected by the new check.
Per major
- Android 14: same fix: commit d0377d694a83 in android-security-14.0.0_r20 (SDP_TRACE_WARNING logging); 3/3 lines present at android-security-14.0.0_r29.
- Android 15: adapted fix: commit 5e3953251ab5 in android-security-15.0.0_r8. The check is identical but the warning uses log::warn("bad arguments to add_addr"), and the hunk is at line 304. 3/3 lines present at android-security-15.0.0_r17.
- Android 16: same fix: commit 3e234b3e3c0a in android-16.0.0_r2 (base), SDP_TRACE_WARNING form; 3/3 lines present at android-security-16.0.0_r8.
- Android 17: not affected (not listed by the bulletin); the patched region is present (3/3 lines) at android-security-17.0.0_r1.
Unknowns
- Which caller or path in sdp_discovery.cc passes add_attr an exhausted p. The commit says only 'exceptional cases', and the index search returned no caller chunks.
- How callers handle the NULL return.
- Whether the rest of add_attr (beyond line 886) has other unguarded reads.
- Whether Android 13, which the bulletin lists as affected, received a corresponding commit. The material has no data for 13.