RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 821440 - nss-softokn initialization memory leak
Summary: nss-softokn initialization memory leak
Keywords:
Status: CLOSED DUPLICATE of bug 919172
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: nss-softokn
Version: 6.3
Hardware: All
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Elio Maldonado Batiz
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-05-14 13:42 UTC by Aleš Mareček
Modified: 2013-08-07 18:53 UTC (History)
3 users (show)

Fixed In Version: nss-softokn-3.14.3-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-08-07 18:53:20 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Aleš Mareček 2012-05-14 13:42:25 UTC 
Description of problem:
There is a 20B leak, it seems in the initialization.

Version-Release number of selected component (if applicable):
nss-softokn-3.12.9-11.el6.i686
nss-3.13.3-6.el6.i686
nspr-4.9-1.el6.i686
curl-7.19.7-26.el6_2.4.i686

How reproducible:
Always

Steps to Reproduce:
1. debuginfo-install nss nspr nss-softokn curl
2. export LD_PRELOAD=libsoftokn3.so
3. valgrind --leak-check=full curl -o/dev/null --cacert FedoraProjectCA.pem https://koji.fedoraproject.org/koji/
  
Actual results:
==15485== Memcheck, a memory error detector
==15485== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==15485== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==15485== Command: curl -o/dev/null --cacert FedoraProjectCA.pem https://koji.fedoraproject.org/koji/
==15485== 
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:--  0:00:08 --:--:--     0
  0     0    0     0    0     0      0      0 --:--:--  0:00:09 --:--:--     0
100 11596    0 11596    0     0   1255      0 --:--:--  0:00:09 --:--:-- 22648
==15485== 
==15485== HEAP SUMMARY:
==15485==     in use at exit: 31,113 bytes in 108 blocks
==15485==   total heap usage: 9,607 allocs, 9,499 frees, 2,326,723 bytes allocated
==15485== 
==15485== 20 bytes in 1 blocks are definitely lost in loss record 34 of 93
==15485==    at 0x400682F: malloc (vg_replace_malloc.c:236)
==15485==    by 0x113198: PR_Malloc (prmem.c:467)
==15485==    by 0xD8BD17: PORT_Alloc_Util (secport.c:112)
==15485==    by 0x4046B5B: sftkdb_passwordToKey (sftkpwd.c:95)
==15485==    by 0x4047F0F: sftkdb_CheckPassword (sftkpwd.c:746)
==15485==    by 0x402962F: sftk_hasNullPassword (pkcs11.c:614)
==15485==    by 0x402BAF1: SFTK_SlotReInit (pkcs11.c:2337)
==15485==    by 0x402BD65: SFTK_SlotInit (pkcs11.c:2430)
==15485==    by 0x402C163: nsc_CommonInitialize (pkcs11.c:2818)
==15485==    by 0x402C24D: NSC_Initialize (pkcs11.c:2880)
==15485==    by 0x40F7934: secmod_ModuleInit (pk11load.c:252)
==15485==    by 0x40F822C: secmod_LoadPKCS11Module (pk11load.c:488)
==15485== 
==15485== 24 bytes in 1 blocks are possibly lost in loss record 39 of 93
==15485==    at 0x400682F: malloc (vg_replace_malloc.c:236)
==15485==    by 0x113198: PR_Malloc (prmem.c:467)
==15485==    by 0x109EB3: _PR_Getfd (prfdcach.c:141)
==15485==    by 0x123F64: pt_SetMethods (ptio.c:3333)
==15485==    by 0x125450: PR_Socket (ptio.c:3535)
==15485==    by 0x12560E: PR_NewTCPSocket (ptio.c:4399)
==15485==    by 0x87C83D: Curl_nss_connect (nss.c:1204)
==15485==    by 0x872D10: Curl_ssl_connect (sslgen.c:185)
==15485==    by 0x850119: Curl_http_connect (http.c:1796)
==15485==    by 0x857A15: Curl_protocol_connect (url.c:3077)
==15485==    by 0x85CDF6: Curl_connect (url.c:4743)
==15485==    by 0x8659B4: Curl_perform (transfer.c:2488)
==15485== 
==15485== 24 bytes in 1 blocks are possibly lost in loss record 40 of 93
==15485==    at 0x400682F: malloc (vg_replace_malloc.c:236)
==15485==    by 0x113198: PR_Malloc (prmem.c:467)
==15485==    by 0x109EB3: _PR_Getfd (prfdcach.c:141)
==15485==    by 0x123F64: pt_SetMethods (ptio.c:3333)
==15485==    by 0x1243C1: PR_OpenFile (ptio.c:3611)
==15485==    by 0x12441B: PR_Open (ptio.c:3619)
==15485==    by 0x4827E0F: ???
==15485==    by 0x48250DB: ???
==15485==    by 0x4826F3E: ???
==15485==    by 0x482B0E5: ???
==15485==    by 0x48321F8: ???
==15485==    by 0x48226BC: ???
==15485== 
==15485== 28 bytes in 1 blocks are possibly lost in loss record 44 of 93
==15485==    at 0x400682F: malloc (vg_replace_malloc.c:236)
==15485==    by 0x113198: PR_Malloc (prmem.c:467)
==15485==    by 0x109EC5: _PR_Getfd (prfdcach.c:144)
==15485==    by 0x123F64: pt_SetMethods (ptio.c:3333)
==15485==    by 0x125450: PR_Socket (ptio.c:3535)
==15485==    by 0x12560E: PR_NewTCPSocket (ptio.c:4399)
==15485==    by 0x87C83D: Curl_nss_connect (nss.c:1204)
==15485==    by 0x872D10: Curl_ssl_connect (sslgen.c:185)
==15485==    by 0x850119: Curl_http_connect (http.c:1796)
==15485==    by 0x857A15: Curl_protocol_connect (url.c:3077)
==15485==    by 0x85CDF6: Curl_connect (url.c:4743)
==15485==    by 0x8659B4: Curl_perform (transfer.c:2488)
==15485== 
==15485== 28 bytes in 1 blocks are possibly lost in loss record 45 of 93
==15485==    at 0x400682F: malloc (vg_replace_malloc.c:236)
==15485==    by 0x113198: PR_Malloc (prmem.c:467)
==15485==    by 0x109EC5: _PR_Getfd (prfdcach.c:144)
==15485==    by 0x123F64: pt_SetMethods (ptio.c:3333)
==15485==    by 0x1243C1: PR_OpenFile (ptio.c:3611)
==15485==    by 0x12441B: PR_Open (ptio.c:3619)
==15485==    by 0x4827E0F: ???
==15485==    by 0x48250DB: ???
==15485==    by 0x4826F3E: ???
==15485==    by 0x482B0E5: ???
==15485==    by 0x48321F8: ???
==15485==    by 0x48226BC: ???
==15485== 
==15485== LEAK SUMMARY:
==15485==    definitely lost: 20 bytes in 1 blocks
==15485==    indirectly lost: 0 bytes in 0 blocks
==15485==      possibly lost: 104 bytes in 4 blocks
==15485==    still reachable: 30,989 bytes in 103 blocks
==15485==         suppressed: 0 bytes in 0 blocks
==15485== Reachable blocks (those to which a pointer was found) are not shown.
==15485== To see them, rerun with: --leak-check=full --show-reachable=yes
==15485== 
==15485== For counts of detected and suppressed errors, rerun with: -v
==15485== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 55 from 10)

Expected results:
No leaks.

Additional info:
Leak also happens when there is no cacert given or non-existent file.
1. curl --cacert existing_ca.pem https://...
2. curl --cacert non-existent-file https://...
3. curl https://...
Comment 2 RHEL Program Management 2012-07-10 06:51:28 UTC 
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 3 RHEL Program Management 2012-07-11 01:43:21 UTC 
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
Comment 4 RHEL Program Management 2012-09-07 05:21:51 UTC 
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.
Comment 5 Kai Engert (:kaie) (inactive account) 2013-04-26 22:19:14 UTC 
Hi Kamil, I wonder if you have some time to look into this issue? We are wondering if the bug could potentially be in the curl module.

Bob was wondering:
"is curl calling NSS_Shutdown and not leaking any NSS references?"

If you have time to check, that would be awesome :)
Thanks in advance
Comment 6 Kamil Dudka 2013-04-28 12:06:25 UTC 
(In reply to comment #5)
> We are wondering if the bug could potentially be in the curl module.

No.

> Bob was wondering:
> "is curl calling NSS_Shutdown and not leaking any NSS references?"

Yes.

> If you have time to check, that would be awesome :)

You need this fix from upstream:

$ cvs diff -r 1.28 -r 1.29 lib/softoken/sftkdb.c
Index: lib/softoken/sftkdb.c
===================================================================
RCS file: /cvsroot/mozilla/security/nss/lib/softoken/sftkdb.c,v
retrieving revision 1.28
retrieving revision 1.29
diff -r1.28 -r1.29
1497a1498,1500
>     if (handle->passwordKey.data) {
>       PORT_ZFree(handle->passwordKey.data, handle->passwordKey.len);
>     }
Comment 7 Elio Maldonado Batiz 2013-04-28 17:22:09 UTC 
(In reply to comment #6)
> (In reply to comment #5)
> You need this fix from upstream:
> 
> $ cvs diff -r 1.28 -r 1.29 lib/softoken/sftkdb.c
> Index: lib/softoken/sftkdb.c
> ===================================================================
> RCS file: /cvsroot/mozilla/security/nss/lib/softoken/sftkdb.c,v
> retrieving revision 1.28
> retrieving revision 1.29
> diff -r1.28 -r1.29
> 1497a1498,1500
> >     if (handle->passwordKey.data) {
> >       PORT_ZFree(handle->passwordKey.data, handle->passwordKey.len);
> >     }

Thank you Kamil. To add to this, the cvs log shows:

$ cvs diff -up -r 1.28 -r 1.29 sftkdb.c
Index: sftkdb.c
===================================================================
RCS file: /cvsroot/mozilla/security/nss/lib/softoken/sftkdb.c,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -p -r1.28 -r1.29
--- sftkdb.c	13 Apr 2011 00:10:26 -0000	1.28
+++ sftkdb.c	1 Sep 2011 20:04:54 -0000	1.29
@@ -1495,6 +1495,9 @@ sftkdb_CloseDB(SFTKDBHandle *handle)
         }
 	(*handle->db->sdb_Close)(handle->db);
     }
+    if (handle->passwordKey.data) {
+	PORT_ZFree(handle->passwordKey.data, handle->passwordKey.len);
+    }
     if (handle->passwordLock) {
 	SKIP_AFTER_FORK(PZ_DestroyLock(handle->passwordLock));
     }
[emaldona@dhcp-32-223 softoken]$ cvs log sftkdb.c | less
[emaldona@dhcp-32-223 softoken]$ cvs log sftkdb.c | grep "1.29"
	NSS_3_13_6_WITH_CKBI_1_93_RTM: 1.29
.... skipped .....
	NSS_3_13_RTM: 1.29
	NSS_3_13_RC0: 1.29
	NSS_3_13_BETA2: 1.29

that it was fixed with the NSS_13_RTM upstream release.  This bug was originally reported against nss-softokn-3.12.9 and the fix came on 3.13 to which we are were not at liberty to rebase the crypto module until now. Due to the Lucky 13 issue we are now free to rebase softoken to 3.14.3 for both rhel-6.5 and rhel-6.4.z so we are picking up the fix. Retesting with valgrind should confirm we have the fix.
Comment 8 Elio Maldonado Batiz 2013-04-28 17:37:35 UTC 
Marking it as fixed in nss-softokn-3.14.3-1.el6, not the latest build but the first were we rebased so I'm quoting that as the build.
Comment 9 Eric Paris 2013-08-07 18:53:20 UTC 
I am going to close this bug as a dup of 919172

919172 was a major rebase with a fix for this problem.

*** This bug has been marked as a duplicate of bug 919172 ***
Note You need to log in before you can comment on or make changes to this bug.