-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Unbounded stack in src/setup_payload #3663
Comments
Issue Label Bot is not confident enough to auto-label this issue. See dashboard for more details. |
#### Problem RAM on small devices is limited, so excesssive stack should not be used without good reason. Stack allocation is also not easily checked at run time so overflow is likely to cause crashes. #### Summary of Changes - Add a `-Wstack-usage` compiler flag on embedded builds. (For this purpose, an ‘embedded build’ is any that is not using a whitelisted non-embedded OS, so new platforms will have this enabled by default.) In this PR, the stack limit is set high enough that _only_ dynamically unbounded stack usage triggers it. The intent is to lower the limit in the future so that any unusually large stack requires whitelisting with justification in review. - Replace most uses of dynamically unbounded stack. - Filed separate issues for two remaining uses of dynamic stack: - project-chip#3662 emberAfPrintBuffer() - project-chip#3663 payloadBase41RepresentationWithTLV() fixes project-chip#3505 Use "-Wstack-usage" for device builds
decimalStringWithPadding() in src/setup_payload/ManualSetupPayloadGenerator.cpp added to this issue. Per https://github.com/project-chip/connectedhomeip/pull/3683/files#r518644463 these uses are probably OK, and just need to be recorded as such. |
* Enable -Wstack-usage on device builds #### Problem RAM on small devices is limited, so excesssive stack should not be used without good reason. Stack allocation is also not easily checked at run time so overflow is likely to cause crashes. #### Summary of Changes - Add a `-Wstack-usage` compiler flag on embedded builds. (For this purpose, an ‘embedded build’ is any that is not using a whitelisted non-embedded OS, so new platforms will have this enabled by default.) In this PR, the stack limit is set high enough that _only_ dynamically unbounded stack usage triggers it. The intent is to lower the limit in the future so that any unusually large stack requires whitelisting with justification in review. - Replace most uses of dynamically unbounded stack. - Filed separate issues for two remaining uses of dynamic stack: - #3662 emberAfPrintBuffer() - #3663 payloadBase41RepresentationWithTLV() fixes #3505 Use "-Wstack-usage" for device builds * Fix dynamic-sized stack array in CHIPDeviceController.cpp * Additional dynamic-stack-size fixes. * Revert ManualSetupPayloadGenerator.cpp
Not sure how to change assignee, but I am looking into this since embedded targets may not support std::string. |
* Change QR code payload setup to use C strings Devices that need to display a QR code may not support std::string. Split base 38 encode and decode functions into separate files, and change the encoding function to use char buffers. * Fix unbounded stack in src/setup_payload (#3663) * Apply suggestions from code review Co-authored-by: Tennessee Carmel-Veilleux <[email protected]> Co-authored-by: Tennessee Carmel-Veilleux <[email protected]>
PR has merged, this can be closed. thanks! |
* Change QR code payload setup to use C strings Devices that need to display a QR code may not support std::string. Split base 38 encode and decode functions into separate files, and change the encoding function to use char buffers. * Fix unbounded stack in src/setup_payload (project-chip#3663) * Apply suggestions from code review Co-authored-by: Tennessee Carmel-Veilleux <[email protected]> Co-authored-by: Tennessee Carmel-Veilleux <[email protected]>
Problem
payloadBase41RepresentationWithTLV() allocates stack space based on an argument, with no upper bound. This could lead to stack exhaustion on small devices.
Proposed Solution
TBD. The caller's callers pass in a destination buffer, which might be usable as temporary space.
Code in this path also uses heap-allocated std::strings, which should ultimately be removed for issue #2748 (All Embedded Device-side Code Needs to Be Scrubbed of Direct Heap Usage).
The text was updated successfully, but these errors were encountered: