-
Notifications
You must be signed in to change notification settings - Fork 342
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
Ubuntu 24.04 - MTR 0.95 #508
Comments
Same here |
As far as I can see it's fixed in current with 5908af4 |
Thanks for pointing that out, Yves. Looking at the patch... If we DO overrun that buffer, it is too small for what we're using it for. Would it be an idea to increase the buffer size say by a factor of 2? And if we're overflowing, we're still in trouble: snprintf will not terminate the buffer when overflow happens. Thus us using that buffer afterwards is "dangerous". |
I suppose it depends on optimization level at building, if so, a result will depend on compiler. #include <stdio.h>
#include <string.h>
#define BSIZE 100
int main() {
char buf[BSIZE];
snprintf(buf + 33, BSIZE, "few");
printf("%s\n", buf + 33);
return 0;
} upd: space optimization like that (supposing) had effects in report-mode with previous versions, and I think already fixed with 'snprintf(buf +n, buf_size -n, ...)' in 5908af4 , but I can mistake in this discourse |
OK.... I investigated some more. Modern ubuntu is using "string_fortified" by default. Your statement about "optimized out" is not true. The space allocated is as defined: 100 bytes. However, __snprintf_chk@PLT ends up being called and somewhere around there, the "buffer overflow" is triggered. At first I thought that snprintf was behaving IMHO against "tradition" and filling the whole "n" bytes of buffer. But that doesn't happen: snprintf copies 4 bytes as expected, and leaves byte 38...100 alone. But snprintf_chk seems to detect the possible buffer overflow and terminates. OK. So my suspicion that we were overflowing the buffer is incorrect. It is just that snprint detects a POSSIBLE buffer overflow, and terminates being a bit overly cautious. On the other hand, such a hard "stance" of the settings mean that developers get notified about possbile overflows and code gets fixed. |
N=10: On Ubuntu 24.04 with the Ubuntu provided mtr: it seems intermittent, as in: not always a core dump.
I compiled the github version of mtr, and so far no core dumps.
|
I was made aware of this issue by a Discord user who tried to find out why duckduckgo was misbehaving with their routing. They were using Ubuntu and the `-w` flag. I tried to generate a similar report and ended up running into the same issue - I was running Arch Linux however! Turns out the fix also works here. Refs traviscross/mtr#508.
I was made aware of this issue by a Discord user who tried to find out why duckduckgo was misbehaving with their routing. They were using the `-w` flag. I tried to generate a similar report and ended up running into the same issue. I was running Arch Linux however! Turns out traviscross/mtr#508 is related and the there mentioned fix also works here. Refs traviscross/mtr#508.
I'm getting this abort consistently when using -r. What's the next step to get this fixed in Ubuntu? Ubuntu needs to apply the |
Yup. that should work. (assuming you're referencing the right patch). |
Perfect. Looks like there's already an open Ubuntu bug here. Thanks! |
Cross-referencing this Arch Linux bug report for |
Easy workaround on Ubuntu: https://www.reddit.com/r/Ubuntu/comments/1e2ddx4/comment/lpzwpra/ |
Update: Ubuntu 24.04 finally released a fix (0.95-1.1ubuntu0.1) in noble-updates about 24 hours ago. https://bugs.launchpad.net/ubuntu/+source/mtr/+bug/2069401 I think this github issue can now be closed. |
I can confirm:
and then:
|
I have the problem on |
Running an MTR report against a general internet target produces the following output:
mtr -r -n 4.2.2.2
Start: 2024-06-27T11:05:42-0500
*** buffer overflow detected ***: terminated
Aborted (core dumped)
When I run the same command on a Ubuntu 20.04 (mtr version 0.93) the issue does not occur
The text was updated successfully, but these errors were encountered: