fix off-by-one length check in BluedroidGetChipDeviceInfo#72652
Merged
mergify[bot] merged 1 commit intoJun 22, 2026
Merged
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request updates the BluedroidGetChipDeviceInfo function in ChipDeviceScanner.cpp to increase the minimum required advertisement data length check (adv_data_len) from 13 to 14 bytes before parsing the CHIP Service UUID. There are no review comments, and I have no feedback to provide.
|
PR #72652: Size comparison from 24e0342 to f809d40 Full report (35 builds for bl602, bl616, bl702, bl702l, cc13x4_26x4, cc32xx, efr32, esp32, nrfconnect, psoc6, qpg, realtek, stm32, telink)
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #72652 +/- ##
=======================================
Coverage 56.19% 56.19%
=======================================
Files 1644 1644
Lines 113050 113050
Branches 13361 13361
=======================================
Hits 63529 63529
Misses 49521 49521 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Contributor
|
Tick the box to add this pull request to the merge queue (same as
|
andy31415
approved these changes
Jun 22, 2026
andy31415
added
the
sdk-maintainer-approved
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
BluedroidGetChipDeviceInforeadsscan_rst.ble_adv[5]throughscan_rst.ble_adv[14]after gating onadv_data_len > 13. The highest index it touches isble_adv[14](theAdditionalDataFlagbyte of the 8-byteChipBLEDeviceIdentificationInfopayload at offsets 7..14), which requiresadv_data_len >= 15. With> 13an advertisement carrying the Matter service UUID (0xf6 0xffat offset 5/6) and exactly 14 bytes passes the guard, so the parser reads one byte past the advertised data intoAdditionalDataFlag. The advertising payload comes straight off the air, so the length is attacker controlled. This tightens the guard to> 14so every indexed byte is within the advertised range.Related issues
None.
Testing
Traced the indexed reads against the guard: the last byte accessed is
ble_adv[14], so the minimum safeadv_data_lenis 15. A conformant Matter advertisement (flags AD + 11-byte service-data AD = 15 bytes) is unaffected; only truncated/crafted 14-byte advertisements that previously slipped through are now rejected, matching the strict length checks used by the Linux and Darwin scanners.