1142263 - Bug 1137007 makes ASAN on Fedora 21 (clang 3.5.0) confused and angry

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, defect)

Description

[Byron Campen [:bwc]]

This changeset is causing ASAN to report spurious stack-overflows and SIGSEGV, which strangely enough doesn't seem to result in program termination. Occasionally I'm seeing unit-tests hang in addition to the spurious errors, but I am not 100% sure this is related (will investigate further). The initial output always seems to be the same:

ASAN:SIGSEGV
=================================================================
==17888==ERROR: AddressSanitizer: stack-overflow on address 0x000000000002 (pc 0x0037120fae91 bp 0x7fff0752a560 sp 0x000000000002 T0)
 

I've observed this in sdp_unittest, jsep_session_unittest, signaling_unittests, and running the browser.

Comment 1

[Byron Campen [:bwc]]

Just observed the test-case hanging on this changeset (actually, it looks like it is trying to crash, given that I see an instance of abrt-hook-ccpp pointing at it, but it seems to just spin indefinitely).

Comment 2

[Byron Campen [:bwc]]

Huh. Killing the abrt-hook-ccpp seems to unstick the unit-test. Bizarre.

Comment 3

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

I'm going to guess that ASAN doesn't like me calling clone(2) directly like that.  Does it work with MOZ_ASSUME_USER_NS=1 (or 0; it doesn't actually matter yet, but any value will make it skip the check) set in the environment?

Comment 4

[Byron Campen [:bwc]]

That seems to prevent the problem, at least with the unit-tests. When I get in the office tomorrow, I'll try the same with mochitest.

Comment 5

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

(In reply to Jed Davis [:jld] from comment #3)
> I'm going to guess that ASAN doesn't like me calling clone(2) directly like
> that.

Worse than that: it looks like ASAN's stack-overflow error is correct.  I forgot to explicitly pass the clone(2) argument that sets the child stack pointer if non-null, and taking care of that seems to fix it.  (I'm running into other errors as well, but they seem to be unrelated.)

Comment 6

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

(In reply to Jed Davis [:jld] from comment #5)
> Worse than that: it looks like ASAN's stack-overflow error is correct.  I
> forgot to explicitly pass the clone(2) argument that sets the child stack
> pointer if non-null, and taking care of that seems to fix it.

…and this also explains the “doesn't seem to result in program termination” from comment #0 — it's in a cloned child process, and its parent just wants to know if it was created successfully, so whether it successfully evaluates _exit(0) or crashes on a bad stack pointer doesn't actually matter.  (The fun times would start if the garbage that winds up in rSP is a valid pointer to a word holding a pointer to executable memory; so, really, let's not do that.)

Comment 7

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Attachment: bug1142263-userns-detection-oops-hg0.diff

Does this patch fix the mystery crashes on your end?

Comment 8

[Byron Campen [:bwc]]

Comment on attachment 8576368 [details] [diff] [review]
bug1142263-userns-detection-oops-hg0.diff

Review of attachment 8576368 [details] [diff] [review]:
-----------------------------------------------------------------

This seems to have done the trick!

Comment 9

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e8b0913ccdf1 (build-only try run because automation's Linux is too old to reach this case, but I've tested locally, and see comment #8).

Comment 10

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/46472d25b238

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/46472d25b238