Repository navigation
Conversation
|
Review requested:
|
49fa1be to
9da6f80
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #62742 +/- ##
==========================================
- Coverage 92.99% 90.69% -2.31%
==========================================
Files 428 797 +369
Lines 195633 278898 +83265
Branches 30281 53628 +23347
==========================================
+ Hits 181937 252951 +71014
- Misses 13369 16312 +2943
- Partials 327 9635 +9308
🚀 New features to boost your workflow:
|
|
Gentle ping - this PR has been open for ~3 weeks without review. This fixes the Coverity 367349 use-after-free risk in CI is green and the fix is ready for review. Would anyone from the crypto @targos (as the issue author) @tniessen @panva would appreciate your |
|
This pull request has been marked as stale due to 90 days of inactivity. |
|
Keep this open |
Fixes Coverity issue 367349 where different smart pointers were seemingly managing the same raw pointer. ManagedX509 is non-copyable and copy assignment is deleted to avoid sharing raw OpenSSL pointers across independent instances. Fixes: nodejs#56926 Assisted-by: Antigravity Signed-off-by: om-ghante <mr.omghante1@gmail.com>
9da6f80 to
105a338
Compare
Description
This PR resolves a potential double-free/use-after-free vulnerability identified by Coverity (Issue 367349) within
ManagedX509::operator=.Previously,
cert_.reset(that.get())was destructing the underlying X509 structure prior to correctly tracking the reference count out-of-band viaX509_up_ref(cert_.get()). If multiple ManagedX509 instances mistakenly managed the same underlying raw pointer, it could cause the OpenSSL backing object's internal reference count to reach zero and prematurely free the memory beforeup_refexecutes.The refactored logic now ensures strict adherence to OpenSSL smart pointer semantics:
X509_up_ref(cert)increments the reference limits first before the object acts on.reset(), strictly guaranteeing the memory boundary.Fixes: #56926