-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix attr read overflows #36003
Fix attr read overflows #36003
Conversation
PR #36003: Size comparison from a7bbd7b to 4436605 Full report (88 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
PR #36003: Size comparison from 6880437 to 4e05b8f Full report (27 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, nrfconnect, nxp, qpg, stm32, tizen)
|
c8380ca
to
0599ec9
Compare
PR #36003: Size comparison from 6880437 to 0599ec9 Full report (83 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
0599ec9
to
b08064e
Compare
068f9e4
to
d636f39
Compare
PR #36003: Size comparison from 579b1b1 to d636f39 Full report (82 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
* Prevent buffer overflows by blocking creation of dynamic endpoints with attributes that would overflow the static attribute buffer * Added additional sanity checks to block reads of attributes that would overflow the attribute reads; return RESOURCE_EXHAUSTED instead
e74b31c
to
30389a7
Compare
PR #36003: Size comparison from 629fea4 to 30389a7 Full report (73 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
size_t bufferSize = Compatibility::Internal::gEmberAttributeIOBufferSpan.size(); | ||
for (uint8_t i = 0; i < ep->clusterCount; i++) | ||
{ | ||
const EmberAfCluster * cluster = &(ep->cluster[i]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could also do:
const EmberAfCluster * cluster = &(ep->cluster[i]); | |
const EmberAfCluster & cluster = ep->cluster[i]; |
but either way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to leave the pointer-style since the structure is ultimately storing pointers -- in hindsight I probably should have done ep->cluster + i to just access the pointer directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For what it's worth, the structure is not in fact storing pointers. It's storing EmberAfCluster objects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
30389a7
to
9d1204e
Compare
9d1204e
to
d263b42
Compare
PR #36003: Size comparison from a579c8d to d263b42 Full report (75 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
Fixes 34937
RESOURCE_EXHAUSTED
insteadTesting
ATTRIBUTE_LARGEST
provided by the ZAP headers results in an error being returned and that endpoint not being published on the node.Manual Tests
Performed A/B testing on my devices and confirmed that the fix worked as expected. Specifically:
The way this bug manifested for me was that the buffer was defaulting to size 8, I'd send a read for some external attributes (these were 32 bytes) from one device running the SDK (local) to another (remote). On the remote, I'd fill the buffer + size provided to me by
emberAfExternalAttributeReadCallback
, this resulted in me unknowingly overflowing said buffer. Back on the local, after reading an external attribute, I'd try to subscribe to the parts list on the remote's EP0 and that would cause the remote's CHIP SDK to crash. After a bunch of painstaking debugging I finally traced it to the buffer overflow. These were my logs:Basically:
0xb23142b8 + 0x20 = 0xb23142d8
, and0xb23142d8 > 0xb23142d4
So by writing the amount of data the CHIP SDK told me was available for writing, I had actually overwritten part of the buffer that was storing the pre-defined attribute access interface for Endpoint 0, thereby resulting in the crash since the memory stored in that buffer was no longer valid.