This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nscd/16791] New: valgrind reports uninitialised byte(s) warning in nscd
- From: "siddhesh at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Tue, 01 Apr 2014 16:39:00 +0000
- Subject: [Bug nscd/16791] New: valgrind reports uninitialised byte(s) warning in nscd
- Auto-submitted: auto-generated
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.