memory corruption/crash in 64bit version of 3.8.2

Bug #1448758 reported by Espen Jürgensen on 2015-04-26
256
This bug affects 1 person
Affects Status Importance Assigned to Milestone
sqlite3 (Ubuntu)
Undecided
Unassigned
Trusty
Undecided
Unassigned
Utopic
Undecided
Unassigned

Bug Description

From a user of my program I have been submitted a database created by sqlite3 3.8.2-1ubuntu2 64bit in Trusty 14.04 that will also crash sqlite3. The error message varies a bit. Here is a selection of them:

*** Error in `sqlite3': malloc(): memory corruption: 0x00007f913a81fb60 ***
---
sqlite3: malloc.c:2372: sysmalloc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 *(sizeof(size_t))) - 1)) & ~((2 *(sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long) old_end & pagemask) == 0)' failed.
---
*** Error in `sqlite3': free(): invalid pointer: 0x00007f418d724150 ***
---
*** Error in `sqlite3': double free or corruption (out): 0x00007fa10c80e570 ***

The crash is easy to reproduce as it happens straight away when querying a specific table. The database works fine with the 32 bit version of 3.8.2, and it also works if I run it with the 64 bit version in Vivid, so I don't think it is corrupt. I guess that also means that the bug has already been fixed upstream. I can send you the database if you provide an email to send it to.

Here is what Valgrind has to say about it:

sqlite> select count(id) from files;
==4839== Invalid write of size 8
==4839== at 0x4E6FDCF: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==4839== by 0x4E6FE01: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==4839== by 0x4E6FE01: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==4839== by 0x4E6FE01: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==4839== by 0x4E6FE01: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==4839== by 0x4E700D4: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==4839== by 0x4E87264: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==4839== by 0x4E8BB65: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==4839== by 0x4E9E6FC: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==4839== by 0x4EA13EE: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==4839== by 0x4EA1A21: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==4839== by 0x4EA1CD4: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==4839== Address 0x5dd58d8 is 0 bytes after a block of size 1,016 alloc'd
==4839== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4839== by 0x4E6ACF6: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==4839== by 0x4E45559: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==4839== by 0x4E4DC37: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==4839== by 0x4E4DD55: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==4839== by 0x4E4DD8C: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==4839== by 0x4E8681C: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==4839== by 0x4E8BB65: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==4839== by 0x4E9E6FC: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==4839== by 0x4EA13EE: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==4839== by 0x4EA1A21: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==4839== by 0x4EA1CD4: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==4839==

CVE References

description: updated
Marc Deslauriers (mdeslaur) wrote :

This may be related to CVE-2015-3414, CVE-2015-3415 or CVE-2015-3416.

Could you please send the database to <email address hidden>?

Thanks!

Marc Deslauriers (mdeslaur) wrote :
information type: Private Security → Public Security
Changed in sqlite3 (Ubuntu Trusty):
status: New → Confirmed
Changed in sqlite3 (Ubuntu Utopic):
status: New → Fix Released
Changed in sqlite3 (Ubuntu):
status: New → Fix Released
Marc Deslauriers (mdeslaur) wrote :

This is CVE-2013-7443

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package sqlite3 - 3.8.2-1ubuntu2.1

---------------
sqlite3 (3.8.2-1ubuntu2.1) trusty-security; urgency=medium

  * SECURITY UPDATE: array overrun in the skip-scan optimization
    (LP: #1448758)
    - debian/patches/CVE-2013-7443.patch: make sure array is large enough
      in src/where.c, added test to test/skipscan1.test.
    - CVE-2013-7443
  * SECURITY UPDATE: improper dequoting of collation-sequence names
    - debian/patches/CVE-2015-3414.patch: handle dequoting in src/expr.c,
      src/parse.y, src/sqliteInt.h, src/where.c, added tests to
      test/collate1.test.
    - CVE-2015-3414
  * SECURITY UPDATE: improper large integers handling in printf function
    - debian/patches/CVE-2015-3416.patch: handle large integers in
      src/printf.c, added tests to test/printf.test.
    - CVE-2015-3416

 -- Marc Deslauriers <email address hidden> Tue, 14 Jul 2015 13:26:04 -0400

Changed in sqlite3 (Ubuntu Trusty):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers