51477 - Crash when application ignores error code and calls again

Status: RESOLVED WORKSFORME

(NSS :: Libraries, defect, P2)

Description

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Marking P2.

Comment 2

[Blake Ross]

*spam*

adding crash keyword...

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Changing target to 3.3.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

future

Comment 5

[Brant Gurganus]

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.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

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

[Jamie Nicolson]

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.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Unsetting target milestone in unresolved bugs whose targets have passed.