This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nscd/16791] New: valgrind reports uninitialised byte(s) warning in nscd


https://sourceware.org/bugzilla/show_bug.cgi?id=16791

            Bug ID: 16791
           Summary: valgrind reports uninitialised byte(s) warning in nscd
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nscd
          Assignee: siddhesh at redhat dot com
          Reporter: siddhesh at redhat dot com
                CC: drepper.fsp at gmail dot com

valgrind warns of uninitialized bytes in the buffer passed to msync:

==3336== Syscall param msync(start) points to uninitialised byte(s)
==3336==    at 0x4E2FEDD: ??? (syscall-template.S:82)
==3336==    by 0x11B547: prune_cache (cache.c:479)
==3336==    by 0x112FCE: nscd_run_worker (connections.c:1005)
==3336==    by 0x4E289D0: start_thread (pthread_create.c:301)
==3336==    by 0x597FB6C: clone (clone.S:115)
==3336==  Address 0x144d73cb is not stack'd, malloc'd or (recently) free'd
==3336==  Uninitialised value was created by a heap allocation
==3336==    at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==3336==    by 0x11CED5: xmalloc (xmalloc.c:82)
==3336==    by 0x1249AA: addgetnetgrentX (netgroupcache.c:141)
==3336==    by 0x125D8D: addgetnetgrent (netgroupcache.c:629)
==3336==    by 0x112B9D: nscd_run_worker (connections.c:1268)
==3336==    by 0x4E289D0: start_thread (pthread_create.c:301)
==3336==    by 0x597FB6C: clone (clone.S:115)

This is seen only on the first uncached netgroup request that results in a
positive response.  It is because the datahead field of a result dataset has an
unused byte that does not get initialized.  Somehow valgrind only catches this
in a specific case, but the problem exists in all code.

The warning is mostly harmless, but has a potential data leak since the header
contents are synced on to the cache file.  This should not have any security
implications though, since the file is accessible only to the root user. 
Nevertheless, it doesn't really hurt to fix it since the code in which this fix
will go is not a hot path - it is only executed when there is a cache miss.

Patch coming up.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]