CVE-2024-49714 AI-generated analysis
platform/packages/modules/Bluetooth, AVRCP stack (system/stack/avrc/avrc_opt.cc)
Replaces an insufficient CHECK-based size assertion in avrc_vendor_msg (system/stack/avrc/avrc_opt.cc) with a bound that accounts for the BT_HDR, AVCT_MSG_OFFSET, the 3 AVRC header bytes and the 3 company_id bytes before vendor_len. The function now returns nullptr instead of aborting when the composed command would not fit in the AVRC_META_CMD_BUF_SIZE buffer.
Root cause
avrc_vendor_msg allocates a fixed buffer of AVRC_META_CMD_BUF_SIZE bytes with osi_calloc. It then writes starting at (p_cmd + 1) + AVCT_MSG_OFFSET: one byte ctype, one byte subunit, one byte AVRC_OP_VENDOR, three bytes company_id, and finally a memcpy of p_msg->vendor_len bytes from p_msg->p_vendor_data. The pre-fix guard was CHECK(AVRC_META_CMD_BUF_SIZE > (AVRC_MIN_CMD_LEN + p_msg->vendor_len)). It used AVRC_MIN_CMD_LEN rather than the fixed overhead the fix introduces, sizeof(BT_HDR) + AVCT_MSG_OFFSET + 6. Per the commit title (OOB write), a vendor_len that passed the old check could make the write go past the end of the allocated buffer. The guard was also a CHECK (process abort) rather than an error return.
How the fix works
- system/stack/avrc/avrc_opt.cc:avrc_vendor_msg: defines AVRC_MIN_VENDOR_CMD_LEN as sizeof(BT_HDR) + AVCT_MSG_OFFSET + 3 + 3. This is the number of bytes in the buffer before the vendor payload, and it matches the writes that follow (offset set to AVCT_MSG_OFFSET, three header bytes, AVRC_CO_ID_TO_BE_STREAM for company_id).
- system/stack/avrc/avrc_opt.cc:avrc_vendor_msg: replaces CHECK(p_msg != NULL) and CHECK(AVRC_META_CMD_BUF_SIZE > (AVRC_MIN_CMD_LEN + p_msg->vendor_len)) with one early return of nullptr when p_msg == nullptr or AVRC_META_CMD_BUF_SIZE < AVRC_MIN_VENDOR_CMD_LEN + p_msg->vendor_len. The memcpy of vendor_len bytes can therefore no longer exceed the osi_calloc(AVRC_META_CMD_BUF_SIZE) allocation. Equality (an exact fit) is allowed.
- The writes that follow and the p_cmd->len computation are unchanged. Only the precondition in front of them is corrected.
Completeness
- The new bound covers every byte written into p_cmd in avrc_vendor_msg: BT_HDR, AVCT_MSG_OFFSET, 3 header bytes, 3 company_id bytes and vendor_len payload bytes. The memcpy is therefore fully bounded against the AVRC_META_CMD_BUF_SIZE allocation.
- The function is static and the material does not show its callers. Whether callers handle the new nullptr return cannot be judged from the material; before the fix, the function either returned a valid buffer or aborted.
- The commit changes only avrc_vendor_msg. It touches no other buffer-composing paths in avrc_opt.cc, and the material does not show those paths.
Behavior changes
- An oversized vendor_len (or a null p_msg) now makes avrc_vendor_msg return nullptr instead of triggering a CHECK abort of the Bluetooth process.
- The size check now uses AVRC_MIN_VENDOR_CMD_LEN instead of AVRC_MIN_CMD_LEN, so the maximum accepted vendor_len may differ from before. An exact fit (sum equal to AVRC_META_CMD_BUF_SIZE) is accepted.
Per major
- Android 14: same fix: commit 6b669f231d0f (cherry-pick of d5de235b461ec83e43a7db513e286d3204c4cedf) in android-security-14.0.0_r22, linked by bug_id. At android-security-14.0.0_r29 the patched region is present (4/5 lines matched, and the code context shows the new check).
- Android 15: not affected per the bulletin. At android-security-15.0.0_r17, 3/5 lines of the patched region are present. The material does not show whether the fix or an equivalent check is present.
- Android 16: not affected per the bulletin, although bulletin/OSV list 16-next as affected. At android-security-16.0.0_r8, 3/5 lines of the patched region are present. The material does not show whether the fix is present.
- Android 17: not affected per the bulletin. At android-security-17.0.0_r1, 3/5 lines of the patched region are present. The material does not show whether the fix is present.
Unknowns
- The numeric values of AVRC_MIN_CMD_LEN, AVRC_META_CMD_BUF_SIZE and AVCT_MSG_OFFSET, and therefore the exact range of vendor_len that got past the old check.
- Which callers invoke avrc_vendor_msg, how they handle the new nullptr return, and whether a remote peer can influence vendor_len or only local clients can.
- The exact state of the patched region in the Android 15/16/17 tags (only a partial 3/5 line match is reported).
- How the fix is delivered beyond the listed security tags.