-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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.