790445 - Hitting PORT_Assert(!ss->xtnData.sniNameArr); on TLS 1.1 client to TLS 1.1 server

Status: RESOLVED INVALID

(NSS :: Libraries, defect)

Description

[Kai Engert (:KaiE:)]

Trying the new TLS 1.1 code.

Starting the server with
  selfserv -D -p 8443 -d ../server -n localhost.localdomain -B -s -w nss \
    -c ABCDEF:0041:0084cdefgijklmnvyz -i ./serverpid
also happening when I add the new -V SSL3:TLS1.1 option.

Starting client with
  tstclnt -p 8443 -h localhost.localdomain -c f -V TLS1.1:TLS1.1 -f \
    -d ../client -v -w nss \
    < /home/kaie/moz/nss/head/mozilla/security/nss/tests/ssl/sslreq.dat


We hit PORT_Assert(!ss->xtnData.sniNameArr);
at
#0  0x00000039c8e35925 in raise () from /lib64/libc.so.6
#1  0x00000039c8e370d8 in abort () from /lib64/libc.so.6
#2  0x00007ffff6f59dbe in PR_Assert (s=0x7ffff7df0c21 "!ss->xtnData.sniNameArr", file=0x7ffff7df0bb2 "sslsock.c", ln=441) at ../../../../pr/src/io/prlog.c:554
#3  0x00007ffff7ddbc15 in ssl_DestroySocketContents (ss=0x7ffff33a9d10) at sslsock.c:441
#4  0x00007ffff7ddbe53 in ssl_FreeSocket (ss=0x69d3e0) at sslsock.c:478
#5  0x00007ffff7dcd7cc in ssl_DefClose (ss=0x69d3e0) at ssldef.c:206
#6  0x00007ffff7dd5e05 in ssl_SecureClose (ss=0x69d3e0) at sslsecur.c:1063
#7  0x00007ffff7ddf862 in ssl_Close (fd=0x68d3a0) at sslsock.c:2061
#8  0x00007ffff6f55bd4 in PR_Close (fd=0x68d3a0) at ../../../../pr/src/io/priometh.c:104
#9  0x0000000000408104 in handle_connection (tcp_sock=0x68d3a0, model_sock=0x61f3f0, requestCert=0) at selfserv.c:1336
#10 0x0000000000406d20 in jobLoop (a=0x0, b=0x0, c=0) at selfserv.c:575
#11 0x0000000000406bd1 in thread_wrapper (arg=0x677f80) at selfserv.c:544
#12 0x00007ffff6f7c9cd in _pt_root (arg=0x67c120) at ../../../../pr/src/pthreads/ptthread.c:156
#13 0x00000039c9207d14 in start_thread () from /lib64/libpthread.so.0
#14 0x00000039c8ef167d in clone () from /lib64/libc.so.6


Just in case it's interesting, I had a hardware watchpoint set to the place that modifies the string at *xtnData->sniNameArr.data

It got (earlier) reset to zero at
#0  0x00000039c8e88bbe in __memset_sse2 () from /lib64/libc.so.6
#1  0x00007ffff75bc509 in PORT_ZFree_Util (ptr=0x6a4e00, len=18432) at secport.c:127
#2  0x00007ffff7dd2247 in ssl_DestroyGather (gs=0x7ffff33aa0a0) at sslgathr.c:416
#3  0x00007ffff7ddba67 in ssl_DestroySocketContents (ss=0x7ffff33a9d10) at sslsock.c:410
#4  0x00007ffff7ddbe53 in ssl_FreeSocket (ss=0x69d3e0) at sslsock.c:478
#5  0x00007ffff7dcd7cc in ssl_DefClose (ss=0x69d3e0) at ssldef.c:206
#6  0x00007ffff7dd5e05 in ssl_SecureClose (ss=0x69d3e0) at sslsecur.c:1063
#7  0x00007ffff7ddf862 in ssl_Close (fd=0x68d3a0) at sslsock.c:2061
#8  0x00007ffff6f55bd4 in PR_Close (fd=0x68d3a0) at ../../../../pr/src/io/priometh.c:104
#9  0x0000000000408104 in handle_connection (tcp_sock=0x68d3a0, model_sock=0x61f3f0, requestCert=0) at selfserv.c:1336
#10 0x0000000000406d20 in jobLoop (a=0x0, b=0x0, c=0) at selfserv.c:575
#11 0x0000000000406bd1 in thread_wrapper (arg=0x677f80) at selfserv.c:544
#12 0x00007ffff6f7c9cd in _pt_root (arg=0x67c120) at ../../../../pr/src/pthreads/ptthread.c:156
#13 0x00000039c9207d14 in start_thread () from /lib64/libpthread.so.0
#14 0x00000039c8ef167d in clone () from /lib64/libc.so.6


The value gets originally assigned in ssl3_HandleServerNameXtn
  xtnData->sniNameArr = names;

In the debugger I set a watchpoint to
  watch -l xtnData->sniNameArr
and it didn't get changed to zero(as the assert seems to expect).

(Only the DEBUG code in ssl_FreeSocket modified it.)


The assert is only triggered, if the client connects in TLS 1.1 mode

(If the client connects with TLS 1.1 disabled, no abort.)

Comment 1

[Kai Engert (:KaiE:)]

I can no longer reproduce this bug.

It was probably caused by an incorrect change to the NSS tools, that I meanwhile fixed with the latest patch for bug 785170.

I'll reopen the bug, should I see it again.