1830300 - force-enabled VAAPI/X11/Nvidia driver: libva-drm.so crash in [@ __socket]

Status: RESOLVED WORKSFORME

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

Description

[Darkspirit]

Seen on crash-stats. This user has likely force-enabled VAAPI.

Crash report: https://crash-stats.mozilla.org/report/index/683346c3-d1e3-4e00-b8e3-772760230427

Reason: SIGSYS / SYS_SECCOMP

Top 10 frames of crashing thread:

0  libc.so.6  __socket  /usr/src/debug/glibc/glibc/sysdeps/unix/syscall-template.S:120
1  libxcb.so.1  _xcb_socket  /usr/src/debug/libxcb/libxcb-1.15/src/xcb_util.c:317
2  libxcb.so.1  _xcb_open_abstract  /usr/src/debug/libxcb/libxcb-1.15/src/xcb_util.c:480
2  libxcb.so.1  _xcb_open  /usr/src/debug/libxcb/libxcb-1.15/src/xcb_util.c:291
2  libxcb.so.1  xcb_connect_to_display_with_auth_info  /usr/src/debug/libxcb/libxcb-1.15/src/xcb_util.c:519
3  libX11.so.6  _XConnectXCB  /usr/src/debug/libx11/libX11-1.8.4/src/xcb_disp.c:78
4  libX11.so.6  XOpenDisplay  /usr/src/debug/libx11/libX11-1.8.4/src/OpenDis.c:129
5  libva-drm.so.2  <.text ELF section in libva-drm.so.2.1800.0>  
6  libva.so.2  vaInitialize  
7  libxul.so  libxul.so@0x78591cb  

It might be coming from here:
https://github.com/intel/libva/blob/0fc018aff4cca3fb75543ed5e84b90d0f379e462/va/drm/va_drm.c#L57-L65

    /* Authentication is only needed for a legacy DRM device */
    if (ctx->display_type != VA_DISPLAY_DRM_RENDERNODES) {
        ret = drmGetMagic(drm_state->fd, &magic);
        if (ret < 0)
            return VA_STATUS_ERROR_OPERATION_FAILED;

        if (!va_drm_authenticate(drm_state->fd, magic))
            return VA_STATUS_ERROR_OPERATION_FAILED;
    }

va_drm_authenticate calls va_drm_authenticate_x11 which calls drm_auth_x11_init which calls XOpenDisplay.

---

Edit:
(Jed Davis [:jld] from bug 1748460 comment 1)

[...] I really don't want to allow sockets if there's any way to avoid it [...]

IMHO: Force-enabling hardware decoding could be blocked for deprecated X11 on proprietary Nvidia drivers.
bug 1748460 could focus on Wayland. Or it could be wontfixed and we wait for Vulkan video decode APIs (vp8+vp9+av1 are still missing).
At the moment, those few users run into crashes until they set MOZ_DISABLE_RDD_SANDBOX=1 which is not recommended.

Comment 1

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

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 2

[Gabriele Svelto [:gsvelto]]

Two new signatures. We're missing some symbols on OpenSUSE but the debuginfo is not present on their servers, so not our fault.

Comment 3

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

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

For more information, please visit BugBot documentation.

Comment 4

[Gian-Carlo Pascutto [:gcp]]

Bad bot.

Comment 5

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

It looks like some of the reports are from systems with only Intel GPUs?

Also I'm not really following what's going on in this code to get a GL display: in bp-46c8f705-e725-41c2-8942-7f1270231203 we end up on the third line calling GetAndInitDisplay, which means that the earlier calls to GetAndInit{Device,Surfaceless}Display both failed. Not sure what's going on there.

We could change this crash into a simple failure, which is already what would happen on non-Nightly, but if there's a missed opportunity for hardware acceleration here it would be good to understand it.

Comment 6

[Gabriele Svelto [:gsvelto]]

One more crash signature.

Comment 7

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

Closing because no crashes reported for 12 weeks.