1970531 - Crash in [@ libc.so.6 | libzfh.so]

Status: NEW

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

Description

[BugBot [:suhaib / :marco]]

Crash report: https://crash-stats.mozilla.org/report/index/96f649b4-f207-46c3-bb0b-a858e0250529

Reason: SIGSYS / SYS_SECCOMP

Top 10 frames of crashing thread:

0  libc.so.6  libc.so.6@0xfb88a  
1  libzfh.so  libzfh.so@0x1e395  
2  libzfh.so  libzfh.so@0x174ab  
3  libzfh.so  libzfh.so@0xfda5  
4  libnspr4.so  pt_Bind  nsprpub/pr/src/pthreads/ptio.c:1733
5  libxul.so  mozilla::NrSocket::create  dom/media/webrtc/transport/nr_socket_prsock.cpp:632
6  libxul.so  mozilla::NrSocketBase::CreateSocket  dom/media/webrtc/transport/nr_socket_prsock.cpp:1599
7  libxul.so  nr_socket_local_create  dom/media/webrtc/transport/nricectx.cpp:1133
8  libxul.so  nr_socket_factory_create_socket  dom/media/webrtc/transport/third_party/nICEr/src/net/nr_socket.c:185
8  libxul.so  nr_ice_get_default_address  dom/media/webrtc/transport/third_party/nICEr/src/ice/ice_ctx.c:638

By querying Nightly crashes reported within the last 2 months, here are some insights about the signature:

• First crash report: 2025-03-28
• Process type: Multiple distinct types
• Is startup crash: No
• Has user comments: No
• Is null crash: Yes - all crashes happened on null or near null memory address

Comment 1

[Gian-Carlo Pascutto [:gcp]]

Given that we can't even find what this library is, hard to argue it's any kind of priority...

Comment 2

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

For future reference: If this does become a problem, one option is to add it to kLibsThatWillCrash, which turns off gSandboxCrashOnError (enabled by default on Nightly only) if the library is detected. The syscalls in question will still be blocked, but will simply fail with ENOSYS as they would on beta or release.