Public bug reported: Ubuntu release: 12.04 Package version: 0.1.33
When parsing fields in a crash report file, whoopsie will reallocate the value buffer when appending continuation lines. The current length of the buffer is computed by pointer arithmetic and the result stored in a signed integer. If the field value length reaches 2GB, then this value will overflow, and become negative. This will then cause whoopsie itself to abort, as it tries to allocate a huge amount of memory. I would expect whoopsie to cope with such large input (which may be generated as the result of a memory-hungry process crashing and creating a very large compressed+base64-encoded CoreDump). By inspection, I see that this issue is still present in current development versions: http://bazaar.launchpad.net/~ubuntu- branches/ubuntu/vivid/whoopsie/vivid/view/head:/src/whoopsie.c#L402 I've attached a patch (created against the 0.1.33 sources, but should apply with minimal issues against later versions), that resolves the immediate issue. There's a more general question about the sanity of loading the entire crash file into memory, too (particularly as the CoreDump is never used unless the server requests it). ** Affects: whoopsie (Ubuntu) Importance: Undecided Status: New ** Patch added: "whoopsie.patch" https://bugs.launchpad.net/bugs/1397340/+attachment/4270149/+files/whoopsie.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to whoopsie in Ubuntu. https://bugs.launchpad.net/bugs/1397340 Title: Integer overflow when processing giant field values Status in whoopsie package in Ubuntu: New Bug description: Ubuntu release: 12.04 Package version: 0.1.33 When parsing fields in a crash report file, whoopsie will reallocate the value buffer when appending continuation lines. The current length of the buffer is computed by pointer arithmetic and the result stored in a signed integer. If the field value length reaches 2GB, then this value will overflow, and become negative. This will then cause whoopsie itself to abort, as it tries to allocate a huge amount of memory. I would expect whoopsie to cope with such large input (which may be generated as the result of a memory-hungry process crashing and creating a very large compressed+base64-encoded CoreDump). By inspection, I see that this issue is still present in current development versions: http://bazaar.launchpad.net/~ubuntu- branches/ubuntu/vivid/whoopsie/vivid/view/head:/src/whoopsie.c#L402 I've attached a patch (created against the 0.1.33 sources, but should apply with minimal issues against later versions), that resolves the immediate issue. There's a more general question about the sanity of loading the entire crash file into memory, too (particularly as the CoreDump is never used unless the server requests it). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1397340/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
