Closed Bug 1272750 Opened 7 years ago Closed 7 years ago

Crash in ssl3_SetupPendingCipherSpec | ssl3_HandleServerHelloPart2 | ssl3_HandleServerHello | ssl3_HandleHandshakeMessage | ssl3_HandleHandshake | ssl3_HandleRecord | ssl3_GatherCompleteHandshake | ssl_GatherRecord1stHandshake | ssl_Do1stHandshake | ss...


(NSS :: Libraries, defect)

Windows 7
Not set


(firefox49 affected)

Tracking Status
firefox49 --- affected


(Reporter: mccr8, Unassigned)


(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-aee086f2-8176-44f3-be9f-d0f512160513.

Number 8 Windows Nightly crash on 5-11, though it appears to be a single user, judging by install time. No URLs besides about:blank, and no addon, so I'm not sure what is going on. I'm also not sure why the signature is so long.
Assignee: nobody → nobody
Component: Security: PSM → Libraries
Product: Core → NSS
Version: Trunk → trunk
ttaubert, any chance you could take a look
Flags: needinfo?(ttaubert)
Hard to tell what's going on here without more data or a way to reproduce. It looks like indeed all the crash reports come from a single user. It's crashing at line 1565:

> 1563  mac = suite_def->mac_alg;
> 1564  if (mac <= ssl_mac_sha && mac != ssl_mac_null && isTLS)
> 1565      mac += 2;

I think it shouldn't be possible to crash here. Is it likely that the affected user has faulty HW? Not sure though if that could crash Firefox twelve times with the same signature.
Flags: needinfo?(ttaubert)
khuey and I looked at this.  In particular, minidump bp-aee086f2-8176-44f3-be9f-d0f512160513

There's a single bit flip in the binary.  Given that it's happening repeatedly, it's presumably a bit flip on disk rather than a bit flip in RAM.

The disassembly of:

    if (mac <= ssl_mac_sha && mac != ssl_mac_null && isTLS)
        mac += 2;

(plus one instruction following it) is supposed to be (if I download the binary and objdump -Cd nss3.dll):

   180110252:   41 83 f8 02             cmp    $0x2,%r8d
   180110256:   7f 0d                   jg     0x180110265
   180110258:   45 85 c0                test   %r8d,%r8d
   18011025b:   74 08                   je     0x180110265
   18011025d:   85 f6                   test   %esi,%esi
   18011025f:   74 04                   je     0x180110265
   180110261:   41 83 c0 02             add    $0x2,%r8d
   180110265:   48 89 83 80 04 00 00    mov    %rax,0x480(%rbx)

however, in the second to last instruction, the user has the 83 bit-flipped to 8b, which transforms the last 2 instructions (well, not all of the second of those instructions) into:

   180110261:   41 8b c0                mov    %r8d,%eax
   180110264:   02 48 89                add    -0x77(%rax),%cl

so we crash with EIP at 0x180110264.
Closed: 7 years ago
Resolution: --- → INVALID
(In reply to David Baron [:dbaron] ⌚️UTC-7 (review requests must explain patch) from comment #3)
> There's a single bit flip in the binary.  Given that it's happening
> repeatedly, it's presumably a bit flip on disk rather than a bit flip in RAM.

(Although if they're close together in time I guess that's not necessarily true.)
Great investigation, thank you David and Kyle!
You need to log in before you can comment on or make changes to this bug.