1696370 - Crash in [@ __GI_getenv]

Status: RESOLVED WORKSFORME

(Core :: Graphics: WebRender, defect, P3)

Description

[Gabriele Svelto [:gsvelto]]

Crash report: https://crash-stats.mozilla.org/report/index/e3255a63-cf2d-41bb-95ec-141230210228

Reason: SIGSEGV /0x00000080

Top 10 frames of crashing thread:

0 libc.so.6 __GI_getenv 
1 libc.so.6 __dcigettext 
2 libdl.so.2 libdl.so.2@0x2a7b 
3 libnspr4.so pr_FindSymbolInLib nsprpub/pr/src/linking/prlink.c:793
4 libnspr4.so PR_FindFunctionSymbol nsprpub/pr/src/linking/prlink.c:845
5 libxul.so mozilla::gl::SymbolLoader::GetProcAddress const gfx/gl/GLLibraryLoader.cpp:65
6 libxul.so get_proc_address_from_glcontext gfx/layers/wr/WebRenderBridgeParent.cpp:145
7 libxul.so webrender_bindings::bindings::get_proc_address gfx/webrender_bindings/src/bindings.rs:506
8 libxul.so gleam::ffi_gl::Gl::load_with::do_metaloadfn x86_64-unknown-linux-gnu/release/build/gleam-31df811bc4bf24c1/out/gl_bindings.rs:2677
9 libxul.so gleam::ffi_gl::Gl::load_with x86_64-unknown-linux-gnu/release/build/gleam-31df811bc4bf24c1/out/gl_bindings.rs:2770

This is an use-after-free crash that seems to mostly affect users on Arch Linux (Arch Firefox' mainter is CC'd). If you look at the raw data you'll notice that r12 always contains the poison pattern.

There are crash reports with this same stack for other distros too but they're a very small number compared to Arch so I suspect something specific is making it more common on that distro.

Comment 1

[Jan Alexander Steffens [:heftig]]

I suspect something corrupted the environment earlier and we're just tripping over it here.

(Most of the crashes with that signature seem to be for Thunderbird 78 on Ubuntu.)

Comment 2

[Daniel Veditz [:dveditz]]

Most of the Thunderbird crashes look like they're related to loading an external smartcard crypto library. Won't be related to the Firefox web Render crash

Comment 3

[Jan Alexander Steffens [:heftig]]

Firefox uses symbol interposition to replace realloc and make it poison the old allocation?

Comment 4

[Jan Alexander Steffens [:heftig]]

AFAICT reading the assembly for getenv, we're indeed trying to dereference r12, and it contains an element from the environ array, i.e. it is the array itself that got poisoned, not a string.

Comment 5

[Jan Alexander Steffens [:heftig]]

Might coincide with Arch's upgrade to GLibC 2.33 (testing started Feb 4).

Never mind, I confused Feb and Mar.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

I don't think this is a security bug it looks like a startup crash that's happening only happening Arch Linux. I think we can wait until someone experiencing this shows up before doing anything about it.

Can we get this downgraded from sec-high?

Comment 7

[Daniel Veditz [:dveditz]]

The March spike is all Thunderbird; Firefox crash levels are relatively consistent over the past 6 months. This really does look like a pure start-up crash: even the half-a-percent that aren't marked as such have extremely short (often 1 sec) uptimes.

Hiding this isn't protecting any Firefox users from anything.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.

Comment 9

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit auto_nag documentation.