1995035 - Crash in [@ __fcntl64_nocancel_adjusted] (F_DUPFD_QUERY)

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, defect)

Description

[Dianna Smith [:diannaS]]

Crash report: https://crash-stats.mozilla.org/report/index/0309ad3a-c328-4dc6-88ba-0fd3c0251017

Reason:

SIGSYS / SYS_SECCOMP

Top 10 frames:

0  libc.so.6  __fcntl64_nocancel_adjusted  /usr/src/debug/glibc-2.41-11.fc42.x86_64/sysdeps/unix/sysv/linux/fcntl_nocancel.c:63
1  libc.so.6  __GI___fcntl  /usr/src/debug/glibc-2.41-11.fc42.x86_64/sysdeps/unix/sysv/linux/fcntl64.c:51
2  libgallium-26.0.0-devel.so  libgallium-26.0.0-devel.so@0x650e33
3  libgallium-26.0.0-devel.so  libgallium-26.0.0-devel.so@0xb2a518
4  libgallium-26.0.0-devel.so  libgallium-26.0.0-devel.so@0xa492df
5  libgallium-26.0.0-devel.so  libgallium-26.0.0-devel.so@0x1a140df
6  libgallium-26.0.0-devel.so  libgallium-26.0.0-devel.so@0xa4a6c7
7  libgallium-26.0.0-devel.so  libgallium-26.0.0-devel.so@0x7245
8  libgallium-26.0.0-devel.so  libgallium-26.0.0-devel.so@0xa40ef1
9  libgallium-26.0.0-devel.so  libgallium-26.0.0-devel.so@0xfd0d3d

Comment 1

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

This is F_DUPFD_QUERY, added in kernel 6.10 (2024-07-14). It's harmless and generally useful: fcntl(fd0, F_DUPFD_QUERY, fd1) tests if the two fds refer to the same file description. It's a simpler alternative to kcmp with KCMP_FILE (which we have carefully filtered to allow this use case and not others).

It's used by Mesa as of this commit; that seems to be in 25.3 which hasn't been released yet. Mercifully, only EBADF is treated as a hard error, so the fact that we'll fail with ENOSYS rather than the expected EINVAL on non-Nightly shouldn't be a problem, and unpatched Firefoxes will fall back to kcmp. So this isn't urgent, but it's a simple fix and I'll look into it.

(We do still need to keep the kcmp rule around, because we'll still need to deal with all the existing Mesa versions that use it and not F_DUPFD_QUERY, or newer Mesa on older kernels, etc.)

Comment 2

[BugBot [:suhaib / :marco]]

The bug is linked to a topcrash signature, which matches the following criterion:

• Top 10 desktop browser crashes on nightly

:jld, could you consider increasing the severity of this top-crash bug?

For more information, please visit BugBot documentation.

Comment 3

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

It looks like these reports are coming from a small number of profiles — there are only 18 distinct install times, with the top one having 3k of the crash reports. I suspect the RDD process is getting into a crash loop; I'll file a bug about that.

Comment 5

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

Attachment: Bug 1995035 - Allow `F_DUPFD_QUERY` in the Linux sandboxes. r?gcp,thinker

Comment 6

[openglfreak]

This issue seems to consistently crash video decoding processes for me, and mainly happens when seeking or restarting any sort of video. The reason this only affects a small number of profiles is likely because not that many people run the development version of Mesa.

Comment 7

[Aidan Harris]

The attached patch fixes this for me in my own compiled Nightly builds of Firefox. Thanks!

Comment 8

[Dianna Smith [:diannaS]]

:jld as a reminder we are in soft code freeze in case you still wanted to land this for 146.

Comment 9

[BugBot [:suhaib / :marco]]

Based on the topcrash criteria, the crash signature linked to this bug is not a topcrash signature anymore.

For more information, please visit BugBot documentation.

Comment 10

[Jan Alexander Steffens [:heftig]]

Decoder processes started crashing with the just-released Mesa 25.3.0, so this will hit more users soon.

Comment 11

[Aidan Harris]

Is the patch still waiting for review from somebody?
I know not many people run Nightly with the latest released version of Mesa but for those that do it's a very bad experience without this patch. Without it VAAPI playback (VP9/AV1, H264 forced with the h264ify add-on seems okay for some reason but VP9/AV1 has no software fallback and I'm not sure why) consistently crashes on YouTube when playing back videos.

Comment 12

[Jan Alexander Steffens [:heftig]]

(In reply to Aidan Harris from comment #11)

H264 forced with the h264ify add-on seems okay for some reason

It falls back to the openh264 plugin, but this one usually crashes when seeking.

Comment 13

[Jure Repinc (JLP)]

Nightly started crashing for me, since openSUSE Tumbleweed just got the new Mesa 25.3

Comment 14

[Aidan Harris]

As a workaround you can disable the RDD sandbox with the MOZ_DISABLE_RDD_SANDBOX=1 environment variable but that's not ideal. It's preferable to everything crashing though.

Comment 15

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

Sorry about the delay getting this landed. As a workaround, I suggest the environment variable MOZ_SANDBOX_CRASH_ON_ERROR=0, which will select the non-Nightly behavior of failing with ENOSYS and not crashing. As mentioned in comment #1, that should cause Mesa to fall back to kcmp.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/e378f4456224
https://hg.mozilla.org/integration/autoland/rev/28a9bd3e9c5c
Allow `F_DUPFD_QUERY` in the Linux sandboxes. r=gcp

Comment 17

[amarc]

https://hg.mozilla.org/mozilla-central/rev/28a9bd3e9c5c

Comment 19

[Andrew Osmond [:aosmond] (he/him)]

Please consider uplifting this to beta/esr140.

Comment 20

[Donal Meehan [:dmeehan]]

:jld, there is only one beta build left before RC week so it would need an uplift request by tomorrow

Comment 21

[Donal Meehan [:dmeehan]]

It's too late for Fx146.
If we get an ESR140 uplift request, it could be considered for 140.7esr

Comment 22

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

I meant to comment on this before the holiday, but didn't get to it in time: This isn't essential on non-Nightly, because Mesa should fall back to kcmp and there should be no user-visible effect.

We may want it on ESR anyway, because the risk should be very low, and that way ESR won't be a special case… but, the patch doesn't apply cleanly on 140 (trivial conflicts with bug 1975358), so there's that too.

Comment 23

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

Attachment: Bug 1995035 - Allow `F_DUPFD_QUERY` in the Linux sandboxes.

Comment 24

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined: Mesa should fall back to an older system call and in theory the user shouldn't notice anything. But, there is slight risk (if some other library adds a use of F_DUPFD_QUERY and doesn't handle errors the same way, for example), and the risk of uplift should be very low. If that justification seems too weak, I'm fine with not uplifting.
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: Functional risk: this just allows a system call that was previously blocked, so it shouldn't break anything that previously worked. Security risk: this is a safe operation, and we already allow the same thing via kcmp.
• String changes made/needed: none
• Is Android affected?: no

Comment 25

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/7a784857c2d4