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

Ubuntu 24.04 - MTR 0.95 #508

Open
bturnbough81 opened this issue Jun 27, 2024 · 14 comments
Open

Ubuntu 24.04 - MTR 0.95 #508

bturnbough81 opened this issue Jun 27, 2024 · 14 comments

Comments

@bturnbough81
Copy link

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

@arthurlutz
Copy link

Same here

@yvs2014
Copy link

yvs2014 commented Jul 7, 2024

As far as I can see it's fixed in current with 5908af4

@rewolff
Copy link
Collaborator

rewolff commented Jul 7, 2024

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".
A buffer[sizeof(buffer)-1] = 0; at the end would help for that. (if you do this with an "if necessary", modern processors are likely slower than just "doing it").

@yvs2014
Copy link

yvs2014 commented Jul 7, 2024

I suppose it depends on optimization level at building, if so, a result will depend on compiler.
For example this part of code below is not triggered overflow with 'gcc -O0',
and triggered glibc overflow detection if compiled with 'gcc -O2' (at least on my PC with current gcc version).
In this case extra space with "BSIZE 200" will be optimized out in the same way as with "BSIZE 100".

#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

@rewolff
Copy link
Collaborator

rewolff commented Jul 7, 2024

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.

@sanderjo
Copy link

N=10:

On Ubuntu 24.04 with the Ubuntu provided mtr: it seems intermittent, as in: not always a core dump.

sander@witje: $ mtr -nrc2 1.1.1.1
Start: 2024-07-14T14:18:45+0200
*** buffer overflow detected ***: terminated
Aborted (core dumped)

sander@witje: $ mtr -nrc2 1.1.1.1
Start: 2024-07-14T14:19:52+0200
*** buffer overflow detected ***: terminated
Aborted (core dumped)

I compiled the github version of mtr, and so far no core dumps.

sander@witje:~/git/mtr$ ./mtr -nrc2 1.1.1.1 
Start: 2024-07-14T14:18:26+0200
HOST: witje                       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.254              0.0%     2    2.2   2.2   2.2   2.2   0.0
  2.|-- 145.90.81.254              0.0%     2    2.6   2.4   2.1   2.6   0.4
  3.|-- 145.97.193.109             0.0%     2    2.8   2.4   2.1   2.8   0.5
  4.|-- 145.145.4.190              0.0%     2    2.4   2.4   2.3   2.4   0.1
  5.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
  6.|-- 145.145.166.48             0.0%     2    4.2   4.2   4.2   4.2   0.0
  7.|-- 145.145.166.49             0.0%     2    4.8   5.5   4.8   6.2   1.0
  8.|-- 141.101.65.97              0.0%     2    5.8   4.8   3.8   5.8   1.4
  9.|-- 1.1.1.1                    0.0%     2    5.7   5.0   4.2   5.7   1.1
sander@witje:~/git/mtr$ ./mtr -nrc2 1.1.1.1
Start: 2024-07-14T14:18:35+0200
HOST: witje                       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.254              0.0%     2    2.2   2.5   2.2   2.7   0.4
  2.|-- 145.90.81.254              0.0%     2    2.8   5.4   2.8   8.0   3.7
  3.|-- 145.97.193.109             0.0%     2    3.0   4.5   3.0   6.0   2.1
  4.|-- 145.145.4.190              0.0%     2    4.5   5.0   4.5   5.6   0.8
  5.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
  6.|-- 145.145.166.48             0.0%     2   27.6  18.6   9.6  27.6  12.7
  7.|-- 145.145.166.49             0.0%     2    4.9   4.4   3.8   4.9   0.8
  8.|-- 141.101.65.97              0.0%     2   30.4  17.0   3.6  30.4  19.0
  9.|-- 1.1.1.1                    0.0%     2    4.1   4.2   4.1   4.2   0.1

icedream added a commit to icedream/customizepkg-config that referenced this issue Jul 19, 2024
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.
icedream added a commit to icedream/customizepkg-config that referenced this issue Jul 19, 2024
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.
@collinanderson
Copy link

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 - len 5908af4 patch?

@rewolff
Copy link
Collaborator

rewolff commented Aug 13, 2024

Yup. that should work. (assuming you're referencing the right patch).

@collinanderson
Copy link

Perfect. Looks like there's already an open Ubuntu bug here. Thanks!

https://bugs.launchpad.net/ubuntu/+source/mtr/+bug/2071890

@mrngm
Copy link

mrngm commented Oct 6, 2024

Cross-referencing this Arch Linux bug report for mtr as well.

@sanderjo
Copy link

@collinanderson
Copy link

collinanderson commented Nov 6, 2024

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.

@sanderjo
Copy link

sanderjo commented Nov 7, 2024

I can confirm:

Setting up mtr (0.95-1.1ubuntu0.1) ...
Processing triggers for man-db (2.12.0-4build2) ...

and then:

sander@zwarte:~$ mtr -nrc2 1.1.1.1
Start: 2024-11-07T12:17:12+0100
HOST: zwarte                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.250              0.0%     2   29.5  16.1   2.7  29.5  18.9
  2.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
  3.|-- 100.64.0.1                50.0%     2   23.0  23.0  23.0  23.0   0.0
  4.|-- 100.64.0.2                 0.0%     2   15.3  10.4   5.4  15.3   7.0
  5.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
  6.|-- 80.249.211.140             0.0%     2   50.8  71.8  50.8  92.8  29.7
  7.|-- 141.101.65.107             0.0%     2    6.5   8.2   6.5   9.8   2.3
  8.|-- 1.1.1.1                    0.0%     2   11.4   9.6   7.9  11.4   2.5

@rkochar
Copy link

rkochar commented Nov 17, 2024

I have the problem on mtr-0.95-5-x86_64.
Kernel: Linux 6.1.111-1-MANJARO

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants