This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/17542] New: conditional jump depends on uninitialised value in svc_getreq_common
- From: "bhubbard at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Tue, 04 Nov 2014 10:37:03 +0000
- Subject: [Bug libc/17542] New: conditional jump depends on uninitialised value in svc_getreq_common
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=17542
Bug ID: 17542
Summary: conditional jump depends on uninitialised value in
svc_getreq_common
Product: glibc
Version: 2.21
Status: NEW
Severity: normal
Priority: P2
Component: libc
Assignee: unassigned at sourceware dot org
Reporter: bhubbard at redhat dot com
CC: drepper.fsp at gmail dot com
Created attachment 7888
--> https://sourceware.org/bugzilla/attachment.cgi?id=7888&action=edit
Proposed patch to resolve uninitialised xports in xprt_register
If xports is NULL in xprt_register we malloc it but if sock > _rpc_dtablesize()
that memory does not get initialised and may in theory contain any value. Later
we make a conditional jump in svc_getreq_common based on the uninitialised
memory and this caused a general protection fault in rpc.statd on an older
version of glibc but this code has not changed since that version.
Following is the valgrind warning.
==26802== Conditional jump or move depends on uninitialised value(s)
==26802== at 0x5343A25: svc_getreq_common (in /lib64/libc-2.5.so)
==26802== by 0x534357B: svc_getreqset (in /lib64/libc-2.5.so)
==26802== by 0x10DE1F: ??? (in /sbin/rpc.statd)
==26802== by 0x10D0EF: main (in /sbin/rpc.statd)
==26802== Uninitialised value was created by a heap allocation
==26802== at 0x4C2210C: malloc (vg_replace_malloc.c:195)
==26802== by 0x53438BE: xprt_register (in /lib64/libc-2.5.so)
==26802== by 0x53450DF: svcudp_bufcreate (in /lib64/libc-2.5.so)
==26802== by 0x10FE32: ??? (in /sbin/rpc.statd)
==26802== by 0x10D13E: main (in /sbin/rpc.statd)
I believe the solution here is to change the malloc call to a calloc call and
the attached patch does that. the GPF could not be reproduced with the patched
glibc.
--
You are receiving this mail because:
You are on the CC list for the bug.