Closed Bug 1320085 Opened 3 years ago Closed 3 years ago

Firefox no longer runs using e10s under fedora 26 rawhide


(Core :: Security: Process Sandboxing, defect, critical)

Not set



Tracking Status
firefox53 --- fixed


(Reporter: wgianopoulos, Assigned: jld)



(3 files)

Attempting to run Firefox with e10s enabled under current rawhide results in all tabs crashing.  The following error was found on stdout:

Sandbox: seccomp sandbox violation: pid 2717, syscall 302, args 0 3 0 140735237946416 3 140735237946416.  Killing process.
And here is a crash report bp-2a834924-c973-4b58-bab0-b2e562161124
I should make it clear.  This worked fine yesterday using the same Firefox version.  This could be just a fedora26 bug.  But it could also be some new feature implemented int eh code with today;s updates that requires us to permit something in the sandbox that we used to deny,
According to the crash reports and your log message, this is the system call: sys_prlimit64

New code may be using it, the ideal way would be to see what changed and introduced the new system call usage and rewrite/remove it (depending on what it is doing)
Let me see first of all if permitting that actually prevents the crash.
The stacks suggest that Firefox is hanging due to a new bug unrelated to sandboxing and it's the HangMonitor trying to get a stack that runs into seccomp.
Attached patch workaroundSplinter Review
This patch seems to avoid the tab crashes.
So does disabling the sandbox, I assume, but that doesn't mean it's a good idea.
Bill, are you able to bisect the change that started causing this to fail?
Well it is not a Mozilla change that triggered this it is something in the fedora patches that I applied yesterday.  I generally do them once a day, but there were quite a few yesterday.  I have no idea how to figure out which changes specifically made the difference.  I tried backing out only the glibc changes, but there seemed to be way too many inter-dependencies to make that a practical thing to do.  I will post a complete list of the changes form the DNF log once i get them extracted.
Attached file fedora26-updates.txt
This is the list of updates applied the day the issue began.
It still looks to me like the glibc updates are the most likely cause here.
And this fails with the stable version of glibc.  so Is there a security issue with making this available in the sandbox or not?
Allowing prlimit{64,} if the first argument is 0 (indicating the current process, which is the case that's happening here) should be fine.
Assignee: nobody → jld
For reference, it looks like the relevant glibc commit is 045c13d18554ae626dfc62f392afb33856c6321d — before that, it wouldn't use prlimit64 to implement getrlimit/setrlimit unless the glibc build was configured to require a minimum kernel version >= 2.6.36, and even then it would dynamically fall back to the old syscalls in case of ENOSYS.  After that commit, it now uses prlimit64 unconditionally (with dynamic fallback).  So this affects development snapshots of glibc from the past 5 weeks and will affect the future glibc 2.25 release.;a=commit;h=045c13d18554ae626dfc62f392afb33856c6321d
Comment on attachment 8815019 [details]
Bug 1320085 - Allow the getrlimit-equivalent subset of prlimit64.

Looks good to me. Thanks :jld for the further research into glibc changes.
Attachment #8815019 - Flags: review?(julian.r.hector) → review+

Does this all mean we need to do the same for prlimit for 32-bit OS?
Pushed by
Allow the getrlimit-equivalent subset of prlimit64. r=tedd
(In reply to Bill Gianopoulos [:WG9s] from comment #18)
> Does this all mean we need to do the same for prlimit for 32-bit OS?

No; for some reason the syscall is always "prlimit64", and there's no "prlimit32" or "prlimit".
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
You need to log in before you can comment on or make changes to this bug.