Closed Bug 1272750 Opened 4 years ago Closed 4 years ago
Crash in ssl3
_Setup Pending Cipher Spec | ssl3 _Handle Server Hello Part2 | ssl3 _Handle Server Hello | ssl3 _Handle Handshake Message | ssl3 _Handle Handshake | ssl3 _Handle Record | ssl3 _Gather Complete Handshake | ssl _Gather Record1st Handshake | ssl _Do1st Handshake | ss ...
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
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; https://hg.mozilla.org/mozilla-central/annotate/674a55274378/security/nss/lib/ssl/ssl3con.c#l1565 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.
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.
Status: NEW → RESOLVED
Closed: 4 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.