Closed
Bug 1480226
Opened 6 years ago
Closed 6 years ago
AddressSanitizer: heap-use-after-free [@ nsVariant] with READ of size 8 through [@ nsNSSDialogs::ChooseCertificate]
Categories
(Core :: Security, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1480517
People
(Reporter: decoder, Unassigned)
References
Details
(Keywords: crash, csectype-uaf, regression)
Attachments
(1 file)
14.01 KB,
text/plain
|
Details |
The attached crash information was submitted via the ASan Nightly Reporter on mozilla-central-asan-nightly revision 63.0a1-20180731105217-https://hg.mozilla.org/mozilla-central/rev/0d72c7996d60a7c07e35c5f90d78b02a47d17460.
For detailed crash information, see attachment.
Reporter | ||
Comment 1•6 years ago
|
||
Comment 3•6 years ago
|
||
This stack doesn't look right -- doing things inside AnnotateMozCrashReason ? nsNSSDialogs::ChooseCertificate inside a destructor (many frames higher)?
To the extent a lot of dialog code is involved these things would only come up through user interaction so I would guess a sec-moderate perhaps?
Keeler: does any of this make sense to you?
decoder: Not sure why this is marked as a "regression". We have no idea if this is new or old. Especially if cert dialogs are involved that's not used too much and wouldn't be hit by our non-interactive fuzzers.
Comment 4•6 years ago
|
||
Those stacks look trashed. e.g.:
0x6040002778b0 is located 32 bytes inside of 48-byte region [0x604000277890,0x6040002778c0)
freed by thread T0 here:
#0 0x4c1ac2 in __interceptor_free /builds/worker/workspace/moz-toolchain/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:68:3
#1 0x7fe18c256805 in nsNSSDialogs::ConfirmDownloadCACert(nsIInterfaceRequestor*, nsIX509Cert*, unsigned int*, bool*) /builds/worker/workspace/build/src/security/manager/pki/nsNSSDialogs.cpp:129:47
#2 0x7fe18c259d6c in nsNSSDialogs::DisplayProtectedAuth(nsIInterfaceRequestor*, nsIProtectedAuthThread*) /builds/worker/workspace/build/src/security/manager/pki/nsNSSDialogs.cpp:425
DisplayProtectedAuth never calls ConfirmDownloadCACert.
Flags: needinfo?(dkeeler)
Reporter | ||
Comment 5•6 years ago
|
||
The same person also sent a second report that I filed as bug 1480517.
Both have in common that dbus is on the stack. Maybe dbus is trashing something?
Flags: needinfo?(choller)
See Also: → 1480517
Fedora 28, GNOME 3.28.2, dbus-1.12.8-1.fc28.src.rpm
If you need any other information, feel free to ask. I just don't know what could have caused it this Wednesday(?) (I guess reports are opened automatically?) or why Firefox crashed. Sorry, can't remember for three days ago…
Maybe also just my whole system froze, although I guess that in such a case Firefox cannot create a crash report…
Reporter | ||
Comment 7•6 years ago
|
||
Thanks for providing the info and no worries :) I assume this is the same bug as bug 1480517 because dbus is on both stacks and it is plausible that one of the stacks got trashed by this.
Marking as a duplicate for now.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Updated•5 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•