1700601 - Unlike Firefox 84, Firefox 85 and 86 are segfaulting at startup, if /sys/devices/** is not accessible

Status: NEW

(Core :: Graphics, defect)

Description

[theDeadDuck]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

• The Apparmor profile usr.bin.firefox is enforced

• Hardware-acceleration is disabled

• Unlike Firefox 84, Firefox 85 and 86 are segfaulting at startup unless /sys/devices/** is accessible

• Despite hardware-acceleration is disabled, starting firefox from terminal throws:
  [GFX1-]: No GPUs detected via PCI
  [GFX1-]: glxtest: process failed (received signal 11)

Actual results:

segfault at 0 ip 00007feb99e49cd4 sp 00007fffbe995730 error 6 in libxul.so[7feb96664000+5145000]

Process 51232 (firefox) of user 1000 dumped core.

Stack trace of thread 51232:
#0 0x00007f381add9d44 n/a (libxul.so + 0x4109d44)
#1 0x00007f3821aa0a27 __run_exit_handlers (libc.so.6 + 0x49a27)
#2 0x00007f3821aa0be0 __GI_exit (libc.so.6 + 0x49be0)
#3 0x00007f38169f1c45 n/a (libpci.so.3 + 0x3c45)
#4 0x00007f38169f7308 n/a (libpci.so.3 + 0x9308)
#5 0x00007f381ade27a9 n/a (libxul.so + 0x41127a9)
#6 0x00007f381ade302b n/a (libxul.so + 0x411302b)
#7 0x00007f381add91df n/a (libxul.so + 0x41091df)
#8 0x00007f381addf436 n/a (libxul.so + 0x410f436)
#9 0x00007f381addf835 n/a (libxul.so + 0x410f835)
#10 0x000055afb85b4123 n/a (firefox + 0xc123)
#11 0x00007f3821a7e0b3 __libc_start_main (libc.so.6 + 0x270b3)
#12 0x000055afb85b3b7e _start (firefox + 0xbb7e)

Expected results:

Throw an error without segfaulting.
May be to stop probing the GPU, if hardware-acceleration is disabled?

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: WebRender' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Ryan VanderMeulen [:RyanVM]]

Do we need to whitelist something in the sandbox maybe?

Comment 3

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

This looks like it's from this code that calls libpci, which is run in a forked child process specifically so we can handle drivers that crash when they're used; note the glxtest: process failed line. Also, this is forked from the parent process, so our sandboxing isn't in use.

As for the crash, libpci is apparently trying to call exit for some reason, and then we crash in an atexit handler which might be UnexpectedExit.

Comment 4

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

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Comment 5

[Julien Cristau [:jcristau] (back April 22)]

Where does "the Apparmor profile usr.bin.firefox" come from, and what does it contain?

Comment 6

[Gian-Carlo Pascutto [:gcp]]

Ubuntu/Debian seem to have one, (but it's not used by default I assume!), and that has

  /sys/devices/pci[0-9]*/**/uevent r,
  /sys/devices/platform/**/uevent r,
  /sys/devices/pci*/**/{busnum,idVendor,idProduct} r,
  /sys/devices/pci*/**/{,subsystem_}device r,
  /sys/devices/pci*/**/{,subsystem_}vendor r,
  /sys/devices/system/node/node[0-9]*/meminfo r,
  /sys/devices/system/cpu/ r,
  /sys/devices/system/cpu/** r,

Comment 7

[theDeadDuck]

As stated above, the access to /sys/devices/** is denied
That means my AppArmor profile contains:

     deny /sys/devices/** r, 

This worked in Firefox versions 84 and older.
The question is why are Firefox versions 85 and later segfaulting?

Comment 8

[Gian-Carlo Pascutto [:gcp]]

The question is why are Firefox versions 85 and later segfaulting?

I'm guessing it's fallout from something like: https://bugzilla.mozilla.org/show_bug.cgi?id=1678917
Where we try to probe more information to understand why graphics acceleration fails to work.

This sounds like it'd be bisectable, but it's clear that blocking access to the devices causes libpci to break.

From comment 3 perhaps the problem is that glxtest failing shouldn't trigger UnexpectedExit, and we should just let libpci crash/exit without issue?

As stated above, the access to /sys/devices/** is denied
That means my AppArmor profile contains:

That's not a distro default or anything, correct?

Comment 9

[theDeadDuck]

Yes that's not in the default profile. Almost all distro default profiles for Firefox are useless.

But why is firefox probing the GPU, if hardware-acceleration is disabled? I don't see any reason for it.
Even then one can check if a resource is accessible before calling libpci or any libXXX methods.

Comment 10

[Gian-Carlo Pascutto [:gcp]]

I don't see any reason for it.

As explained above, it's trying to figure out what the hardware is to help us debug why it fails. That shouldn't failure-cascade as it's doing here, but obviously your particular case - a custom sandboxing/AppArmor profile - wasn't tested and the current code can't handle it. We're interested in fixing this - eventually.

Comment 12

[Paul Wise]

I'm seeing what looks like this bug in Tor Browser since version 11.0 (based on Firefox ESR 91.3.0esr) when launched by torbrowser-launcher, which includes an apparmor profile that by default blocks access to the /sys/bus/pci/devices/ directory.

Comment 13

[Paul Wise]

FTR, here are the torbrowser-launcher and Tor Browser bugs about this:

https://github.com/micahflee/torbrowser-launcher/issues/595
https://bugs.torproject.org/tpo/applications/tor-browser/40708

Comment 14

[theDeadDuck]

I'm sure Whonix OS and Tails OS will be the next to be affected by this bug.

Whatever changes you made in Firefox 86, it only opens a pretty big attack surface for no reason.

• there is no reason probing the GPU, if hardware-acceleration is disabled
• there is no reason calling libpci methods, if resources are not accessible

Security-focused operating systems like Whonix and Tails allow a very limited access to hardware resources.

Comment 15

[Paul Wise]

Tor Browser Launcher developers fixed the crash in this commit by allowing Firefox to access GPUs:

https://github.com/micahflee/torbrowser-launcher/commit/7af35f4475d1dab28f84f76146a5f743b60402ac

This probably opens up a new privacy issue for Tor Browser though.

Comment 16

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

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.