Closed
Bug 403795
Opened 17 years ago
Closed 16 years ago
Verify lifetime of PKIX_PL_OcspRequest vs PKIX_PL_OcspResponse
Categories
(NSS :: Libraries, defect, P1)
NSS
Libraries
Tracking
(Not tracked)
RESOLVED
INVALID
3.12
People
(Reporter: KaiE, Assigned: alvolkov.bgs)
References
Details
(Whiteboard: PKIX NSS312B2)
Function pkix_pl_OcspResponse_Create uses pkix_pl_OcspRequest_GetCertID to obtain a pointer to a CERTOCSPCertID and stores it as a member of the new response object. Is the request object guaranteed to life at least as long as the response object? If the request object could get freed earlier, the response object might carry a dangling pointer. If that's possible to happen, it shouldn't reference the simple pointer, but make a deep copy.
Reporter | ||
Comment 1•17 years ago
|
||
Thoughts welcome, although I might fix this when working on bug 375019.
Blocks: 375019
Assignee | ||
Comment 2•17 years ago
|
||
pkix_OcspChecker_Check is the function to look at. OCSP request object get freed (with associated responds object) after all operation are finished and ocsp revocation status is know. IMO, it is save to use CERTOCSPCertID in this case.
Updated•17 years ago
|
Whiteboard: PKIX
Target Milestone: --- → 3.12
Assignee | ||
Updated•17 years ago
|
Assignee: nobody → alexei.volkov.bugs
Whiteboard: PKIX → PKIX NSS312B2
Assignee | ||
Updated•17 years ago
|
Priority: -- → P1
Assignee | ||
Comment 3•16 years ago
|
||
Reference count to request data get incremented before saving the pointer in to request member of response data structure. The pointer will be decremented at the response destruction time. It is safe to use. Closing bug as invalid.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•