wget crash when printing download rate

The attachment "0001-Fix-crash-when-printing-download-rate.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

AFAICT from the patch, this only affects users who experience download speeds measured in terabytes per second.

The code also says:

if (secs == 0)
  /* If elapsed time is exactly zero, it means we're under the
     resolution of the timer. This can easily happen on systems
     that use time() for the timer. Since the interval lies between
     0 and the timer's resolution, assume half the resolution. */
  secs = ptimer_resolution () / 2.0;

secs is a double. If because of timer issues it's tiny, you can get very large numbers. In me trying to reproduce it, I saw GB/s speeds all the time that were theoretically impossible.

I started getting crashes on various Ubuntu 22.04 servers. There may have been a change somewhere that exposes it, but the problem was always there.

Upstream will not be assigning this issue a CVE [0] and the Ubuntu Security Team does not consider this bug security relevant.

This bug is caused when calculating the download speed, but hitting an out-of-bounds on the table that contains the printable strings. It is hitting GB/s because it is, presumably, not handling the system timer resolution correctly. This is no more security relevant than any other bug that crashes wget.

@wiebe-halfgaar, thank you for raising awareness about this issue and getting it fixed upstream.

[0] https://lists.gnu.org/archive/html/bug-wget/2023-08/msg00008.html

Is there any progress in getting it fixed in 'updates'?

I'm still getting a bunch of wget crashes from cron jobs I have. Is there any progress on this?

@halfgaar, I've requested that the Foundation's team review the priority of this bug