-
Notifications
You must be signed in to change notification settings - Fork 1.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
Out of bounds multicast group ID can cause memory corruption #1275
Comments
I have met a similar problem here - #1277 |
Thanks for reporting this issue. |
@gregbreen and @MarekNovakACRIOS Would it be possible for your to test the below attached patch. I think it should fix the observed issue. However I did not had the time yet to verify it. Your feedback are welcome. Thanks in advance. |
Thanks @mluis1 . Since I'm using the STM32CubeWL firmware, this patch doesn't easily apply for me. I think the changes you made look right. |
Thanks for the feedback. We will push the patch as soon as possible. |
…ds access - Refactored the way the debug messages are handled
In handling several of the multicast package commands, the code uses the group ID directly from the incoming payload, and indexes into
McSessionData
array without range checking the ID value. For example:This is fine if
LORAMAC_MAX_MC_CTX
is 4. (Although in the above example,id
could be as much as 255.) However ifLORAMAC_MAX_MC_CTX
is changed to a lower value (such as 1 in the STM32CubeWL firmware), this can be more problematic. The out of bounds array write occurs before an IDerror is determined.If you agree, then REMOTE_MCAST_SETUP_MC_GROUP_CLASS_C_SESSION_REQ and REMOTE_MCAST_SETUP_MC_GROUP_CLASS_B_SESSION_REQ have a similar vulnerability. They are both ANDed with 0x03, but that has the assumption that LORAMAC_MAX_MC_CTX is 4.
The text was updated successfully, but these errors were encountered: