Bug 1285144

Summary:	Invalid memory access of init_transport (rpcbind.c)
Product:	Red Hat Enterprise Linux 6	Reporter:	Yongcheng Yang <yoyang>
Component:	libtirpc	Assignee:	Steve Dickson <steved>
Status:	CLOSED ERRATA	QA Contact:	Yongcheng Yang <yoyang>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.7	CC:	bhubbard, eguan, steved, xzhou
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	libtirpc-0.2.1-13.el6	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-03-21 09:30:20 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Yongcheng Yang 2015-11-25 03:09:20 UTC

Description of problem:
rpcbind leak memory in init_transport()

Version-Release number of selected component (if applicable):
rpcbind-0.2.0-11.el6

How reproducible:
100% easily

Steps to Reproduce:
1. Just run rpcbind within valgrind, e.g.
valgrind --log-file=valgrind.out --trace-children=yes --leak-check=full --track-origins=yes -v --show-reachable=yes rpcbind

Actual results:
[root@hp-dl580g7-03 ~]# rpm -q rpcbind
rpcbind-0.2.0-11.el6.x86_64
[root@hp-dl580g7-03 ~]# 
[root@hp-dl580g7-03 ~]# service nfs stop
Shutting down NFS daemon: [  OK  ]
Shutting down NFS mountd: [  OK  ]
Shutting down NFS quotas: s[  OK  ]
Shutting down NFS services:  [  OK  ]
Shutting down RPC idmapd: [  OK  ]
[root@hp-dl580g7-03 ~]# service rpcbind stop
Stopping rpcbind: [  OK  ]
[root@hp-dl580g7-03 ~]# ps axf | grep [r]pcbind
[root@hp-dl580g7-03 ~]# valgrind --log-file=valgrind.out --trace-children=yes --leak-check=full --track-origins=yes -v --show-reachable=yes  rpcbind
[root@hp-dl580g7-03 ~]# ps axf | grep [r]pcbind
72903 ?        Ss     0:01 valgrind --log-file=valgrind.out --trace-children=yes --leak-check=full --track-origins=yes -v --show-reachable=yes rpcbind
[root@hp-dl580g7-03 ~]# cat valgrind.out | grep -A25 "LEAK SUMMARY"
==72902== LEAK SUMMARY:
==72902==    definitely lost: 527 bytes in 10 blocks
==72902==    indirectly lost: 1,000 bytes in 1 blocks
==72902==      possibly lost: 0 bytes in 0 blocks
==72902==    still reachable: 56,801 bytes in 146 blocks
==72902==         suppressed: 0 bytes in 0 blocks
==72902== 
==72902== ERROR SUMMARY: 10 errors from 9 contexts (suppressed: 6 from 6)
==72902== 
==72902== 2 errors in context 1 of 9:
==72902== Invalid read of size 1
==72902==    at 0x4A07F48: strnlen (mc_replace_strmem.c:375)
==72902==    by 0x58D725D: vfprintf (in /lib64/libc-2.12.so)
==72902==    by 0x5993EFB: __vasprintf_chk (in /lib64/libc-2.12.so)
==72902==    by 0x5993E22: __asprintf_chk (in /lib64/libc-2.12.so)
==72902==    by 0x4E37517: __rpc_taddr2uaddr_af (in /lib64/libtirpc.so.1.0.10)
==72902==    by 0x4E37732: taddr2uaddr (in /lib64/libtirpc.so.1.0.10)
==72902==    by 0x10B7D4: rbllist_add.clone.0 (rpcbind.c:709)
==72902==    by 0x10BF34: init_transport (rpcbind.c:637)
==72902==    by 0x10C7D2: main (rpcbind.c:181)
==72902==  Address 0x5c28b77 is 0 bytes after a block of size 23 alloc'd
==72902==    at 0x4A06A2E: malloc (vg_replace_malloc.c:270)
==72902==    by 0x10BA1B: init_transport (rpcbind.c:519)
==72902==    by 0x10C7D2: main (rpcbind.c:181)
==72902== 
--72902-- 
[root@hp-dl580g7-03 ~]# 

Expected results:
No leaks

Additional info:
This issue is found when dealing with bug 1186933, please find the related comments:
https://bugzilla.redhat.com/show_bug.cgi?id=1186933#c5
https://bugzilla.redhat.com/show_bug.cgi?id=1186933#c47

Comment 2 Steve Dickson 2015-12-14 20:33:58 UTC

Possible upstream commit:

commit 61d4aef25a2bb4a460beb40dbdd30dd3fb883547
Author: Thorsten Kukuk <kukuk>
Date:   Tue Dec 16 14:00:12 2014 -0500

    tirpc: fix taddr2uaddr for AF_LOCAL
    
    taddr2uaddr would return trailing garbage for AF_LOCAL addresses
    
    taddr2uaddr assumed that the sun_path field of an AF_LOCAL address
    was always NULL terminated, but that is not necessarily the case,
    especially if the buffer was allocated using the correct SUN_LEN().
    
    Signed-off-by: Olaf Kirch <okir>
    Signed-off-by: Steve Dickson <steved>

Comment 7 Brad Hubbard 2017-01-03 08:41:10 UTC

definitely lost: 527 bytes in 10 blocks

That means it is leaking memory somewhere unless it is a false positive (possible but unlikely). Do a search for "definitely lost" and look at the stacks involved. The memory leaks may be a different bug but likely still a bug. "Definitely lost" is a leak, "invalid read" is invalid memory access... different things but both bugs (unless false positives). Hope this helps.

Comment 8 Yongcheng Yang 2017-01-03 09:53:49 UTC

(In reply to Brad Hubbard from comment #7)
> definitely lost: 527 bytes in 10 blocks
> 
> That means it is leaking memory somewhere unless it is a false positive
> (possible but unlikely). Do a search for "definitely lost" and look at the
> stacks involved. The memory leaks may be a different bug but likely still a
> bug. "Definitely lost" is a leak, "invalid read" is invalid memory access...
> different things but both bugs (unless false positives). Hope this helps.

Thanks for the prompt reply, it do help me a lot.

As the "invalid read" issue has been fixed (Comment #5), just move to VERIFIED.

And will file another bug to track the "Definitely lost" issue if necessary.

Comment 10 errata-xmlrpc 2017-03-21 09:30:20 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2017-0606.html