Crash when application ignores error code and calls again

NEW
Unassigned

Status

P2
normal
19 years ago
8 years ago

People

(Reporter: nelson, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

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
(Reporter)

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 2

19 years ago
*spam*

adding crash keyword...
Keywords: crash
Changing target to 3.3.
Target Milestone: 3.2 → 3.3
future
Target Milestone: 3.3 → Future

Comment 5

16 years ago
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.  

Comment 7

16 years ago
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

Updated

16 years ago
QA Contact: wtc → bishakhabanerjee
(Reporter)

Updated

14 years ago
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
(Reporter)

Updated

13 years ago
QA Contact: jason.m.reid → libraries
Unsetting target milestone in unresolved bugs whose targets have passed.
Target Milestone: 3.12 → ---
Assignee: nelson → nobody
You need to log in before you can comment on or make changes to this bug.