Closed Bug 51477 Opened 25 years ago Closed 21 days ago

Crash when application ignores error code and calls again

Categories

(NSS :: Libraries, defect, P2)

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: nelson, Unassigned)

Details

This bug was formerly bugsplat bug 351893. Today, if SSL detects a problem with a received SSL record/message and returns an error the the application, but the application ignores the error and calls PR_Read or PR_Write again, SSL often crashes. This is because the error return left things in an internally inconsistent state. This needs to be fixed.
Marking P2.
Priority: P3 → P2
Target Milestone: --- → 3.2
Status: NEW → ASSIGNED
*spam* adding crash keyword...
Keywords: crash
Changing target to 3.3.
Target Milestone: 3.2 → 3.3
future
Target Milestone: 3.3 → Future
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and <http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss bugs are of critical or possibly higher severity. Only changing open bugs to minimize unnecessary spam. Keywords to trigger this would be crash, topcrash, topcrash+, zt4newcrash, dataloss.
Severity: normal → critical
There are no known mozilla crashes due to this issue. This is because PSM does not ignore SSL error codes. Further, mozilla policies do not universally apply to NSS.
This bug can also cause a hang if SSL fails in the middle of a handshake (for example, if a hardware device fails while performing client auth). If this error code is ignored, the next call on the socket might try to wait for the server hello message that was already received, and hang until the connection times out.
Keywords: hang
QA Contact: wtc → bishakhabanerjee
QA Contact: bishakhabanerjee → jason.m.reid
I suggest the addition of a "previous fatal error" flag to the ssl socket. After returning a fatal error to an NSS/NSPR call on an ssl socket, the socket should then fail all future operations (except close) without attempting them first. That would fix this bug, and is a lot simpler than trying to ensure that EVERY error path in libSSL leaves the entire SSL socket in a clean state.
Severity: critical → normal
Status: ASSIGNED → NEW
Keywords: crash, hang
Target Milestone: Future → 3.12
QA Contact: jason.m.reid → libraries
Unsetting target milestone in unresolved bugs whose targets have passed.
Target Milestone: 3.12 → ---
Assignee: nelson → nobody
Severity: normal → S3
Status: NEW → RESOLVED
Closed: 21 days ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.