[pkg-db-devel] Bug#662917: libdb5.1: uninitialized memory read: __log_put + __ham_add_el

Wed Mar 7 09:28:34 UTC 2012

Package: libdb5.1
Version: 5.1.29-1
Severity: normal
Tags: upstream

   * What led up to the situation?

I'm running Evolution Data Server's address book daemon under valgrind
while executing the SyncEvolution nightly testing.

   * What was the outcome of this action?

valgrind reports the following error in libdb:

==23596== Conditional jump or move depends on uninitialised value(s)
==23596==    at 0x9A404E7: ??? (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==23596==    by 0x9A41CB1: __log_put (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==23596==    by 0x9A42F2D: ??? (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==23596==    by 0x9A43D9F: __log_put_record (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==23596==    by 0x9986B1B: __ham_add_el (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==23596==    by 0x997E1FD: ??? (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==23596==    by 0x99F5548: __dbc_iput (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==23596==    by 0x99F314F: __db_put (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==23596==    by 0x9A04EBA: __db_put_pp (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==23596==    by 0x103CC953: do_create (e-book-backend-file.c:915)
==23596==    by 0x103CCBFC: e_book_backend_file_create_contacts (e-book-backend-file.c:988)
==23596==    by 0x4E4AC31: e_book_backend_sync_create_contacts (e-book-backend-sync.c:85)
==23596==    by 0x4E4D3D7: book_backend_create_contacts (e-book-backend-sync.c:493)
==23596==    by 0x4E4ED2A: e_book_backend_create_contacts (e-book-backend.c:465)
==23596==    by 0x4E513D3: operation_thread (e-data-book.c:157)
==23596==    by 0x83E9D07: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.2)
==23596==    by 0x83E77E5: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.2)
==23596==    by 0x8678B4F: start_thread (pthread_create.c:304)
==23596==    by 0x896690C: clone (clone.S:112)
==23596==  Uninitialised value was created by a stack allocation
==23596==    at 0x994DB80: ??? (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)

After compiling the upstream libdb 5.1.29 from source with -g, the output is a bit more readable:

==2780== Conditional jump or move depends on uninitialised value(s)
==2780==    at 0x9A9F507: __log_putr (log_put.c:783)
==2780==    by 0x9A9EA8A: __log_put_next (log_put.c:468)
==2780==    by 0x9A9E1C3: __log_put (log_put.c:172)
==2780==    by 0x9AA2EBB: __log_put_record_int (log_put.c:1967)
==2780==    by 0x9AA1DB4: __log_put_record (log_put.c:1708)
==2780==    by 0x9996D16: __ham_insdel_log (hash_auto.h:29)
==2780==    by 0x999F371: __ham_add_el (hash_page.c:2636)
==2780==    by 0x998C690: __hamc_put (hash.c:1121)
==2780==    by 0x9A392B4: __dbc_iput (db_cam.c:2121)
==2780==    by 0x9A39102: __dbc_put (db_cam.c:2034)
==2780==    by 0x9A33F1B: __db_put (db_am.c:520)
==2780==    by 0x9A4BC20: __db_put_pp (db_iface.c:1594)
==2780==    by 0x1043B962: do_create (e-book-backend-file.c:916)
==2780==    by 0x1043BC0B: e_book_backend_file_create_contacts (e-book-backend-file.c:989)
==2780==    by 0x4E4AC31: e_book_backend_sync_create_contacts (e-book-backend-sync.c:85)
==2780==    by 0x4E4D3D7: book_backend_create_contacts (e-book-backend-sync.c:493)
==2780==    by 0x4E4ED2A: e_book_backend_create_contacts (e-book-backend.c:465)
==2780==    by 0x4E513D3: operation_thread (e-data-book.c:157)
==2780==    by 0x83E9D07: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.2)
==2780==    by 0x83E77E5: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.2)
==2780==    by 0x8678B4F: start_thread (pthread_create.c:304)
==2780==    by 0x896690C: clone (clone.S:112)
==2780==  Uninitialised value was created by a stack allocation
==2780==    at 0x999EB3B: __ham_add_el (hash_page.c:2460)
==2780== 

   * What outcome did you expect instead?

No valgrind warnings in libdb unless the code above it does something wrong.

I've tracked the root cause in __ham_add_el() in src/hash/hash_page.c:

        if (is_databig) {
                doff.type = H_OFFPAGE;
===>            UMRW_SET(doff.unused[0]);
===>            UMRW_SET(doff.unused[1]);
===>            UMRW_SET(doff.unused[2]);

UMRW_SET is a NOP unless --enable-umrw is used during
configure. Compiling with --enable-umrw avoids the valgrind warning.

The unitialized value is used in a comparison of a checksum with 0.
I can convince myself that this is probably okay, because it doesn't
matter whether some of the data the checksum was calculated over
was uninitialized as long as it doesn't change later on.

But nevertheless, having to deal with such random valgrind errors
while debugging other code isn't nice. Please consider using
--enable-umrw when compiling libdb.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf-8, LC_CTYPE=de_DE.utf-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libdb5.1 depends on:
ii  libc6              2.13-26
ii  multiarch-support  2.13-26

libdb5.1 recommends no packages.

libdb5.1 suggests no packages.

-- no debconf information

-- 
Bye, Patrick Ohly
--  
Patrick.Ohly at gmx.de
http://www.estamos.de/