This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1285144 - Invalid memory access of init_transport (rpcbind.c)
Invalid memory access of init_transport (rpcbind.c)
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libtirpc (Show other bugs)
6.7
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Steve Dickson
Yongcheng Yang
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-24 22:09 EST by Yongcheng Yang
Modified: 2017-03-21 05:30 EDT (History)
4 users (show)

See Also:
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 05:30:20 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Yongcheng Yang 2015-11-24 22:09:20 EST
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 15:33:58 EST
Possible upstream commit:

commit 61d4aef25a2bb4a460beb40dbdd30dd3fb883547
Author: Thorsten Kukuk <kukuk@suse.de>
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@suse.de>
    Signed-off-by: Steve Dickson <steved@redhat.com>
Comment 7 Brad Hubbard 2017-01-03 03:41:10 EST
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 04:53:49 EST
(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 05:30:20 EDT
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

Note You need to log in before you can comment on or make changes to this bug.