-
Notifications
You must be signed in to change notification settings - Fork 38
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
libkmod: Fix overflow in kmod_module_hex_to_str #236
Conversation
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.
I have a slight inclination towards the overflow check approach, since it consolidates the fallout into single place - aka check once and carry on, vs check every so often.
Although the strbuf approach is also fine IMHO.
Aside: github supports highlighting for code blocks - add "diff" or "c" or ... on the opening triple-backtick line.
-before
+after
libkmod/libkmod-module.c
Outdated
const size_t line_limit = 20; | ||
size_t str_len; | ||
size_t i; |
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.
Nit: we can move the index declaration in the for loop.
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.
Adjusted
If an overly long signature is found in a module file, it is possible to trigger an out of boundary write in kmod_module_hex_to_str due to integer and subsequent heap buffer overflow. This approach replaces malloc + sprintf with a simple hex-lookup and a strbuf approach, being slightly faster in real life scenarios while adding around 100 bytes to library size. A much faster approach could be done without strbuf and using our overflow check functions, but readability should win here. Signed-off-by: Tobias Stoeckmann <[email protected]>
4a47777
to
59305a6
Compare
Codecov ReportAttention: Patch coverage is
|
To simplify the alternative, we could also change the function signature to take a Mentioned it here if either it's decided to go with this alternative instead or, alternatively, that we might perform these adjustments as "performance improvements" later on. |
If an overly long signature is found in a module file, it is possible to trigger an out of boundary write in kmod_module_hex_to_str due to integer and subsequent heap buffer overflow. This approach replaces malloc + sprintf with a simple hex-lookup and a strbuf approach, being slightly faster in real life scenarios while adding around 100 bytes to library size. A much faster approach could be done without strbuf and using our overflow check functions, but readability should win here. Signed-off-by: Tobias Stoeckmann <[email protected]> Link: #236 Signed-off-by: Lucas De Marchi <[email protected]>
Applied, thanks |
If an overly long signature is found in a module file, it is possible to trigger an out of boundary write in
kmod_module_hex_to_str
due to integer and subsequent heap buffer overflow.This approach replaces malloc + sprintf with a simple hex-lookup and a strbuf approach, being slightly faster in real life scenarios while adding around 100 bytes to library size. Even though it calls
realloc
due tostrbuf_steal
,sprintf
for such simple format specifiers has still a larger overhead. A much faster approach could be done without strbuf and using our overflow check functions, but readability should win here.Proof of Concept:
If you do not run out of memory, you will see a segmentation fault.
This saves a few instructions and cycles in
depmod
, but the best thing about this diff is, that it removes the lastsprintf
call found in libkmod, replacing it with our safer and easier to handle strbuf implementation.The previously mentioned alternative would be:
With huge signatures, it's 10 times faster, but when calling depmod, the difference is, of course, much smaller. It reduces the size of library by a few bytes, but in total I think it's not worth it to have a piece of code which is harder to read in this scenario. Still wanted to offer at least a tested alternative.