Last Comment Bug 339173 - mem leak whenever SECMOD_HANDLE_STRING_ARG called in loop
: mem leak whenever SECMOD_HANDLE_STRING_ARG called in loop
Status: RESOLVED FIXED
FIPS
: coverity
Product: NSS
Classification: Components
Component: Libraries (show other bugs)
: 3.11
: All All
: P2 normal (vote)
: 3.12
Assigned To: Nelson Bolyard (seldom reads bugmail)
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-24 19:06 PDT by Nelson Bolyard (seldom reads bugmail)
Modified: 2006-10-25 11:47 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
patch v1 (630 bytes, patch)
2006-05-24 19:12 PDT, Nelson Bolyard (seldom reads bugmail)
rrelyea: review+
Details | Diff | Splinter Review
patch v1, part 2 (3.54 KB, patch)
2006-05-26 16:04 PDT, Nelson Bolyard (seldom reads bugmail)
rrelyea: review+
alvolkov.bgs: review+
Details | Diff | Splinter Review

Description Nelson Bolyard (seldom reads bugmail) 2006-05-24 19:06:34 PDT
Coverity CIDs 578 and 579
In source file lib/softoken/pk11db.c, there are numerous places where we 
find loops containing one or more invocations of the SECMOD_HANDLE_STRING_ARG
macro.  That macro checks for a string match, then allocates memory for a copy
of a string, and stores the allocated memory address in a target pointer. 
If the same macro invocation should occur twice in the loop, e.g. because the
sought string occurred more than once in the source string, all but the last
allocation of the corresponding value string would be leaked.  

Coverity reports 11 occurrences of this in all, one for each macro invocation.

The most straightforward solution is to have that macro free the contents of
the target pointer, if it is not already NULL.  patch forthcoming.
Comment 1 Nelson Bolyard (seldom reads bugmail) 2006-05-24 19:12:10 PDT
Created attachment 223256 [details] [diff] [review]
patch v1

Bob, please review.
Comment 2 Robert Relyea 2006-05-25 08:51:03 PDT
Comment on attachment 223256 [details] [diff] [review]
patch v1

r= rrelya
Comment 3 Nelson Bolyard (seldom reads bugmail) 2006-05-26 16:04:01 PDT
Created attachment 223507 [details] [diff] [review]
patch v1, part 2

OOps, that patch had two parts, and I previously only attached one of them.
So please review this part, also, as if the two parts are being reviewed 
together.
Comment 4 Alexei Volkov 2006-05-31 16:14:44 PDT
Comment on attachment 223507 [details] [diff] [review]
patch v1, part 2

r=alexei
Comment 5 Nelson Bolyard (seldom reads bugmail) 2006-06-01 22:27:34 PDT
So, Wan-Teh, is it too late for softoken fixes like this one now?
Comment 6 Nelson Bolyard (seldom reads bugmail) 2006-06-08 18:29:08 PDT
Retargetting this bug to NSS 3.12 because it is a softoken change, and we
don't want to trigger more FIPS work.
Comment 7 Robert Relyea 2006-06-16 09:38:28 PDT
Comment on attachment 223507 [details] [diff] [review]
patch v1, part 2

r=rrelyea
Comment 8 Wan-Teh Chang 2006-08-23 18:45:15 PDT
Nelson, if you want, you can check in this patch on
the NSS_3_11_BRANCH before this Friday.
Comment 9 Nelson Bolyard (seldom reads bugmail) 2006-10-25 11:47:47 PDT
Committed on trunk.

Checking in pk11db.c;   new revision: 1.37; previous revision: 1.36
Checking in pk11pars.h; new revision: 1.21; previous revision: 1.20

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