Skip to content
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

mosquitto_topic_matches_sub2 doesn't work; ignores lengths #2364

Closed
snej opened this issue Nov 4, 2021 · 1 comment
Closed

mosquitto_topic_matches_sub2 doesn't work; ignores lengths #2364

snej opened this issue Nov 4, 2021 · 1 comment
Milestone

Comments

@snej
Copy link

snej commented Nov 4, 2021

mosquitto_topic_matches_sub2 is an alternate version of mosquitto_topic_matches_sub that doesn't require C strings, instead taking both strings as pointer/length pairs. (I appreciate this, since my code does not use null-terminated strings!)

Unfortunately it does not behave that way. Instead, it ignores the sublen and topiclen parameters and uses NUL bytes to find the ends of the strings. (In fact it and mosquitto_topic_matches_sub share the same implementation code -- the latter is just a stub that calls it with 0 for the length parameters.)

The effect is that, if you pass it strings that don't end in a NUL byte, it will run off the ends of the strings and typically either produce incorrect results, or perhaps crash if it falls off the end of mapped memory. In my case it promptly triggered a visit from the Clang address sanitizer the first time I tried calling it.

Workaround is to copy both strings into heap buffers, zero-terminate them, call mosquitto_topic_matches_sub, and free the buffers.

I'm using commit 9afeeb1, from Sept 2.

@ralight
Copy link
Contributor

ralight commented Nov 16, 2021

The original intent of the second function was to remove the need to call strlen on a string you already knew the length of. The expectation was very much that you'd be using strings generated by the library. In the end I found that the current implementation was quicker so used it. I completely agree that it shouldn't be working like this though. I'll add the correct version back in.

@ralight ralight added this to the 2.0.14 milestone Nov 16, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 11, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants