aboutsummaryrefslogtreecommitdiff
path: root/ChangeLog
diff options
context:
space:
mode:
authorBrad Hubbard <bhubbard@redhat.com>2015-03-18 14:51:26 +0530
committerSiddhesh Poyarekar <siddhesh@redhat.com>2015-03-18 14:51:26 +0530
commited6b0fe710b631b99ed9fc28cefedfe69a16dc55 (patch)
tree5b682e438c37f4be767bc25daf630e90b455451d /ChangeLog
parentf8aeae347377f3dfa8cbadde057adf1827fb1d44 (diff)
downloadglibc-ed6b0fe710b631b99ed9fc28cefedfe69a16dc55.tar
glibc-ed6b0fe710b631b99ed9fc28cefedfe69a16dc55.tar.gz
glibc-ed6b0fe710b631b99ed9fc28cefedfe69a16dc55.tar.bz2
glibc-ed6b0fe710b631b99ed9fc28cefedfe69a16dc55.zip
Use calloc to allocate xports (BZ #17542)
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)
Diffstat (limited to 'ChangeLog')
-rw-r--r--ChangeLog5
1 files changed, 5 insertions, 0 deletions
diff --git a/ChangeLog b/ChangeLog
index 6bca61bf18..2df497fb29 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2015-03-18 Brad Hubbard <bhubbard@redhat.com>
+
+ [BZ #17542]
+ * sunrpc/svc.c (xprt_register): Use calloc to allocate xports.
+
2015-03-17 Alexandre Oliva <aoliva@redhat.com>
[BZ #17090]