Bug 1039062

Summary: Memory leak in SECMOD_LoadModule
Product: Red Hat Enterprise Linux 6 Reporter: Hubert Kario <hkario>
Component: nssAssignee: Bob Relyea <rrelyea>
Status: CLOSED WONTFIX QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: low Docs Contact:
Priority: medium    
Version: 6.5CC: amarecek, emaldona, kengert, nkinder, pvrabec, rrelyea
Target Milestone: pre-dev-freeze   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1087920 (view as bug list) Environment:
Last Closed: 2016-07-27 08:50:00 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:
Bug Depends On:    
Bug Blocks: 1087920    
Attachments:
Description Flags
reproducer none

Description Hubert Kario 2013-12-06 14:06:32 UTC 
Created attachment 833619 [details]
reproducer

Description of problem:
When running reproducer for bug 772628, memory leaks are reported by valgrind

Version-Release number of selected component (if applicable):
nss-3.15.1-15.el6.x86_64

How reproducible:
Always, all architectures

Steps to Reproduce:
1. Compile attached source
2. Run under valgrind

Actual results:
==2044== 48 (8 direct, 40 indirect) bytes in 1 blocks are definitely lost in loss record 48 of 103
==2044==    at 0x4A075BC: operator new(unsigned long) (vg_replace_malloc.c:298)
==2044==    by 0x68F4F79: ???
==2044==    by 0x50C1466: secmod_ModuleInit (pk11load.c:221)
==2044==    by 0x50C1DE6: secmod_LoadPKCS11Module (pk11load.c:457)
==2044==    by 0x50D56E9: SECMOD_LoadModule (pk11pars.c:1010)
==2044==    by 0x50D57DF: SECMOD_LoadModule (pk11pars.c:1045)
==2044==    by 0x50A4A93: nss_Init (nssinit.c:435)
==2044==    by 0x50A5260: NSS_InitContext (nssinit.c:834)
==2044==    by 0x3DA7C4044F: ??? (in /usr/lib64/libcurl.so.4.1.1)
==2044==    by 0x3DA7C40602: Curl_nss_connect (in /usr/lib64/libcurl.so.4.1.1)
==2044==    by 0x3DA7C38481: Curl_ssl_connect (in /usr/lib64/libcurl.so.4.1.1)
==2044==    by 0x3DA7C16ECA: Curl_http_connect (in /usr/lib64/libcurl.so.4.1.1)
==2044== 
==2044== 120 bytes in 1 blocks are definitely lost in loss record 58 of 103
==2044==    at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==2044==    by 0x6B18169: ???
==2044==    by 0x6903D0F: ???
==2044==    by 0x68F4E8C: ???
==2044==    by 0x50C1466: secmod_ModuleInit (pk11load.c:221)
==2044==    by 0x50C1DE6: secmod_LoadPKCS11Module (pk11load.c:457)
==2044==    by 0x50D56E9: SECMOD_LoadModule (pk11pars.c:1010)
==2044==    by 0x50D57DF: SECMOD_LoadModule (pk11pars.c:1045)
==2044==    by 0x50A4A93: nss_Init (nssinit.c:435)
==2044==    by 0x50A5260: NSS_InitContext (nssinit.c:834)
==2044==    by 0x3DA7C4044F: ??? (in /usr/lib64/libcurl.so.4.1.1)
==2044==    by 0x3DA7C40602: Curl_nss_connect (in /usr/lib64/libcurl.so.4.1.1)
==2044== 
==2044== 720 (120 direct, 600 indirect) bytes in 15 blocks are definitely lost in loss record 88 of 103
==2044==    at 0x4A075BC: operator new(unsigned long) (vg_replace_malloc.c:298)
==2044==    by 0x6904F79: ???
==2044==    by 0x50C1466: secmod_ModuleInit (pk11load.c:221)
==2044==    by 0x50C1DE6: secmod_LoadPKCS11Module (pk11load.c:457)
==2044==    by 0x50D56E9: SECMOD_LoadModule (pk11pars.c:1010)
==2044==    by 0x50D57DF: SECMOD_LoadModule (pk11pars.c:1045)
==2044==    by 0x50A4A93: nss_Init (nssinit.c:435)
==2044==    by 0x50A5260: NSS_InitContext (nssinit.c:834)
==2044==    by 0x3DA7C4044F: ??? (in /usr/lib64/libcurl.so.4.1.1)
==2044==    by 0x3DA7C40602: Curl_nss_connect (in /usr/lib64/libcurl.so.4.1.1)
==2044==    by 0x3DA7C38481: Curl_ssl_connect (in /usr/lib64/libcurl.so.4.1.1)
==2044==    by 0x3DA7C16ECA: Curl_http_connect (in /usr/lib64/libcurl.so.4.1.1)
==2044== 
==2044== 1,800 bytes in 15 blocks are definitely lost in loss record 93 of 103
==2044==    at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==2044==    by 0x73CF169: ???
==2044==    by 0x6913D0F: ???
==2044==    by 0x6904E8C: ???
==2044==    by 0x50C1466: secmod_ModuleInit (pk11load.c:221)
==2044==    by 0x50C1DE6: secmod_LoadPKCS11Module (pk11load.c:457)
==2044==    by 0x50D56E9: SECMOD_LoadModule (pk11pars.c:1010)
==2044==    by 0x50D57DF: SECMOD_LoadModule (pk11pars.c:1045)
==2044==    by 0x50A4A93: nss_Init (nssinit.c:435)
==2044==    by 0x50A5260: NSS_InitContext (nssinit.c:834)
==2044==    by 0x3DA7C4044F: ??? (in /usr/lib64/libcurl.so.4.1.1)
==2044==    by 0x3DA7C40602: Curl_nss_connect (in /usr/lib64/libcurl.so.4.1.1)
==2044== 
==2044== LEAK SUMMARY:
==2044==    definitely lost: 2,048 bytes in 32 blocks
==2044==    indirectly lost: 640 bytes in 16 blocks
==2044==      possibly lost: 176 bytes in 4 blocks
==2044==    still reachable: 38,653 bytes in 119 blocks
==2044==         suppressed: 0 bytes in 0 blocks
==2044== Reachable blocks (those to which a pointer was found) are not shown.
==2044== To see them, rerun with: --leak-check=full --show-reachable=yes

Expected results:
No leakedm unreachable memory reported

Additional info:
Comment 1 Hubert Kario 2013-12-06 14:09:05 UTC 
Small correction, the leaks are not present on s390x, they are present on x86_64, ppc64 and i386 architectures.