Crash when application ignores error code and calls again

NEW
Unassigned

Status

NSS
Libraries
P2
normal
18 years ago
8 years ago

People

(Reporter: Nelson Bolyard (seldom reads bugmail), 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.
(Reporter)

Comment 1

18 years ago
Marking P2.
Priority: P3 → P2
Target Milestone: --- → 3.2
(Reporter)

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 2

18 years ago
*spam*

adding crash keyword...
Keywords: crash
(Reporter)

Comment 3

18 years ago
Changing target to 3.3.
Target Milestone: 3.2 → 3.3
(Reporter)

Comment 4

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

Comment 6

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

15 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

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

Updated

13 years ago
QA Contact: bishakhabanerjee → jason.m.reid
(Reporter)

Comment 8

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

12 years ago
QA Contact: jason.m.reid → libraries
Unsetting target milestone in unresolved bugs whose targets have passed.
Target Milestone: 3.12 → ---
(Reporter)

Updated

9 years ago
Assignee: nelson → nobody
You need to log in before you can comment on or make changes to this bug.