-
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
asymcute: Compare request message type when matching acknowledgement #18434
Conversation
Currently, asymcute only matches an MQTT-SN request to its acknowledgement using the MsgId header. However, I strongly believe this to be insufficient as asymcute would thus also match a SUBACK to a prior PUBLISH message (for example) as long as the message ID matches. To address this issue, this commit modifies _req_preprocess to also compare the request message type in addition to the message id.
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.
ACK. Code change looks good, reasoning makes sense, and I trust your testing.
FYI: I found this with SymEx-VP so I haven't done any tests with a particular MQTT-SN broker implementation (yet). |
OK, I guess I should test it prior hitting the merge button just to be sure, then. :) |
❗ This may cause a semantic merge conflict with #18433, once that is merged: |
@nmeum can you please provide a backport to the 2022.07 branch, e.g. by using the |
Contribution description
Currently, asymcute matches an MQTT-SN request to its acknowledgement using only the MsgId header. However, I strongly believe this to be insufficient as asymcute would thus also match a SUBACK to a prior PUBLISH request (for example) as long as the message ID matches. If this happens (e.g. because of a malicious MQTT-SN broker) then this can trigger various bugs in asymcute, e.g. due to incorrect casts of the
req->arg
void*
pointer. To address this issue, this commit modifies_req_preprocess
to also compare the request message type in addition to the message id.Testing procedure
I haven't tested my fix extensively yet but existing tests should continue to work. Unfortunately, it also a bit difficult to provide a simple test setup for triggering this edge case.
Issues/PRs references
None.