Segfaults trying to send crash report

Thank you for taking the time to report this bug and helping to make Ubuntu better.

This bug report has been modified to private. We would highly appreciate if you could upload your crash report here for analysis.

Attached is compressed tar(1) archive (snapshot) I took of /var/crash shortly after filing
this bug report.

I note that when I try the manual-run test now,
the daisy server seems to be off-line?:

$ sudo /bin/sh -c 'export CRASH_DB_URL=https://daisy.ubuntu.com; exec whoopsie -f'
[11:08:23] Using lock path: /var/lock/whoopsie/lock
[11:08:24] The default IPv4 route is: /org/freedesktop/NetworkManager/ActiveConnection/1
[11:08:24] Not a paid data plan: /org/freedesktop/NetworkManager/ActiveConnection/1
[11:08:24] Found usable connection: /org/freedesktop/NetworkManager/ActiveConnection/1
[11:08:24] Parsing /var/crash/_usr_bin_kdeinit5.1000.crash.
[11:08:24] Uploading /var/crash/_usr_bin_kdeinit5.1000.crash.
[11:08:27] Sent; server replied with: Couldn't connect to server
[11:08:27] Response code: 0
^C
$
$ ping daisy.ubuntu.com
PING daisy.ubuntu.com (162.213.33.132) 56(84) bytes of data.
^C
--- daisy.ubuntu.com ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3060ms
$

The above _suggests_ the problem only(?) happens if `whoopsie' can connect with the server?

With some help from
https://askubuntu.com/questions/434431/how-can-i-read-a-crash-file-from-var-crash
I have generated as full of a stack backtrace as I can
(please note I have ALL(?) relevant -dbg / -dbgsym packages installed)
using apport-retrace(1) on the `_usr_bin_whoopsie.108.crash' file generated about
when all this started (and hence, I _presume_, is a capture of "the" problem).
It is attached (gzip(1) compressed), and shows libc::memcpy() segfaults after
a call from libcurl... see attached file for details.

I have no idea how to check/verify the contents of a `.crash' file, and so have
no idea what might be "wrong" or "odd" about the `kdeinit' file which seems to be
the input data for the `whoopsie' segfault.

Thanks - the crash report can be unpacked via apport-unpack:

$ gunzip _usr_bin_whoopsie.108.crash.gz
$ apport-unpack _usr_bin_whoopsie.108.crash lp1850608

Then the contents can be seen in the lp1850608 directory - looking at StackTrace in particular we see the following:

...
#11 0x0000563d8f963194 in upload_report (message_data=0x7f1dc0b60010 "r\276\003", message_len=140728898666098, s=0x7ffe5de79f00) at src/whoopsie.c:328
        curl = 0x563d9001f8e0
        result_code = CURLE_OK
        response_code = 0
        list = 0x563d90027190
        __func__ = "upload_report"
...

And that message_len looks suspiciously large

This bug was fixed in the package whoopsie - 0.2.66ubuntu0.2

---------------
whoopsie (0.2.66ubuntu0.2) eoan-security; urgency=medium

  * SECURITY REGRESSION: segfault when sending crash report (LP: #1850608)
    - lib/bson/bson.c: properly initialize value.

 -- Marc Deslauriers <email address hidden> Wed, 30 Oct 2019 08:58:38 -0400

This bug was fixed in the package whoopsie - 0.2.52.5ubuntu0.3

---------------
whoopsie (0.2.52.5ubuntu0.3) xenial-security; urgency=medium

  * SECURITY REGRESSION: segfault when sending crash report (LP: #1850608)
    - lib/bson/bson.c: properly initialize value.

 -- Marc Deslauriers <email address hidden> Wed, 30 Oct 2019 09:03:35 -0400

I suspect this is what is happening:

  whoopsie.c::parse_and_upload_report() calls
  whoopsie.c::bonsify() to get some length (a size_t) using
  bson.c::boson_size(), which calls
  platform.h::bson_little_endian32() to convert an unknown
   value (presumably 32-bits) of unknown endianness into an
   size_t (64-bits) with opaque endianness.

A look at bson_little_endian32() shows it transfers only 4-bytes.
However, a size_t is 8-bytes (on my 64-bit system),
and those bytes are being copied into an *uninitialized* size_t
(in bson_size()). End result is 4 of the 8 bytes returned will
be garbage, hence the bizarre length noted previously.

No fix is proposed, nor do I intend to propose one (sorry!).

I have just (briefly) looked at the fix as-of "whoopsie 0.2.62ubuntu0.3",
and concur with with the change (which should correct the problem as per
the previous analysis). Whether or not it actually works I can_not_ say,
as the `daisy.ubuntu.com' server is currently not-responding (for what I
presume is very understandable reasons!).

Thank You for the prompt action on this problem!

On Wed, Oct 30, 2019 at 06:46:30PM -0000, Brian Foster wrote:

> Whether or not it actually works I can_not_ say, as the
> `daisy.ubuntu.com' server is currently not-responding (for what I
> presume is very understandable reasons!).

The daisy.u.c service has been intentionally throttled to avoid
another DoS from crashing clients retrying. It should be restored to
full service shortly after some time for the latest whoopsie changes
to make it's way out.

This morning, almost exactly 24hrs after the problem was noted,
my system, using the fixed whoopsie (0.2.62ubuntu0.3),
successfully sent all the pending crash reports (including,
of course, the previous whoopsie's own crash);
confirmed by checking /var/log/syslog.