Closed Bug 1177430 Opened 10 years ago Closed 10 years ago

Remove assertion !ss->xtnData.sniNameArr in ssl_DestroySocketContents

Categories

(NSS :: Test, defect)

3.19.1
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: KaiE, Assigned: KaiE)

References

Details

Attachments

(1 file)

Function ssl_DestroySocketContents has code to cleanup ss->xtnData.sniNameArr, but in debug mode, it doesn't allow that array to be non-null. That's a problem with our SSL protocol tests (ssl_gtests). Because some tests send a bad sequence of messages, the array may be non-null on destruction. We should handle bad peers gracefully, even in debug mode. I suggest to remove the assertion.
Attached patch 1177430.patchSplinter Review
Assignee: nobody → kaie
Blocks: 1168425
Comment on attachment 8626189 [details] [diff] [review] 1177430.patch I wouldn't worry about the comment.
Attachment #8626189 - Flags: review+
Comment on attachment 8626189 [details] [diff] [review] 1177430.patch Review of attachment 8626189 [details] [diff] [review]: ----------------------------------------------------------------- r=wtc. I agree that the comment can be omitted because it is clear that ssl_DestroySocketContents must be able to destroy the contents of a socket in a partially inconsistent state.
Attachment #8626189 - Flags: review+
Kai, Martin: I studied the code related to ss->xtnData.sniNameArr. That assertion in ssl_DestroySocketContents seems to be intended to ensure that ssl3_HandleClientHello frees ss->xtnData.sniNameArr as soon as it is finished with ss->xtnData.sniNameArr. If we want to preserve the spirit of that assertion, we can move the assertion to the beginning of ssl3_SendServerHello. Here are the code snippets that support my proposal: 8217 /* Clean up sni name array */ 8218 if (ssl3_ExtensionNegotiated(ss, ssl_server_name_xtn) && 8219 ss->xtnData.sniNameArr) { 8220 PORT_Free(ss->xtnData.sniNameArr); 8221 ss->xtnData.sniNameArr = NULL; 8222 ss->xtnData.sniNameArrSize = 0; 8223 } 8224 8225 ssl_GetXmitBufLock(ss); haveXmitBufLock = PR_TRUE; 8226 8227 rv = ssl3_SendServerHello(ss); 8228 if (rv != SECSuccess) { 8229 errCode = PORT_GetError(); 8230 goto loser; 8231 } and 8387 /* Free sniNameArr. The data that each SECItem in the array 8388 * points into is the data from the input buffer "b". It will 8389 * not be available outside the scope of this or it's child 8390 * functions.*/ 8391 if (ss->xtnData.sniNameArr) { 8392 PORT_Free(ss->xtnData.sniNameArr); 8393 ss->xtnData.sniNameArr = NULL; 8394 ss->xtnData.sniNameArrSize = 0; 8395 } 8396 if (ret <= SSL_SNI_SEND_ALERT) { 8397 /* desc and errCode should be set. */ 8398 goto alert_loser; 8399 } 8400 } 8401 #ifndef SSL_SNI_ALLOW_NAME_CHANGE_2HS 8402 else if (ss->firstHsDone) { 8403 /* Check that we don't have the name is current spec 8404 * if this extension was not negotiated on the 2d hs. */ 8405 PRBool passed = PR_TRUE; 8406 ssl_GetSpecReadLock(ss); /*******************************/ 8407 if (ss->ssl3.cwSpec->srvVirtName.data) { 8408 passed = PR_FALSE; 8409 } 8410 ssl_ReleaseSpecReadLock(ss); /***************************/ 8411 if (!passed) { 8412 errCode = SSL_ERROR_UNRECOGNIZED_NAME_ALERT; 8413 desc = handshake_failure; 8414 goto alert_loser; 8415 } 8416 } 8417 #endif 8418 8419 sid = ssl3_NewSessionID(ss, PR_TRUE); 8420 if (sid == NULL) { 8421 errCode = PORT_GetError(); 8422 goto loser; /* memory error is set. */ 8423 } 8424 ss->sec.ci.sid = sid; 8425 8426 ss->ssl3.hs.isResuming = PR_FALSE; 8427 ssl_GetXmitBufLock(ss); 8428 rv = ssl3_SendServerHelloSequence(ss); 8429 ssl_ReleaseXmitBufLock(ss); 8430 if (rv != SECSuccess) { 8431 errCode = PORT_GetError(); 8432 goto loser; 8433 } are the only two places (both in ssl3_HandleClientHello) besides ssl_DestroySocketContents where we free ss->xtnData.sniNameArr: http://mxr.mozilla.org/nss/search?string=sniNameArr%2B%3D%2BNULL
Kai, Can we land this patch, either with or without Wan-Teh's suggestion? I am running into this in some other code.
Flags: needinfo?(kaie)
Checked in without comment. https://hg.mozilla.org/projects/nss/rev/0b8056579bd9 If you'd like to restore the assertion at a different place, we'd need to test that the new assertion indeed works and doesn't break, and I didn't have time to do that right now. Please suggest a follow-up patch if you want to add a new assertion, and we can test it when someone has time.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(kaie)
Resolution: --- → FIXED
Target Milestone: --- → 3.20
Thanks for fixing this. This will be fine for my purposes.
Target Milestone: 3.20 → 3.21
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: