1691407 - Crash in [@ syscall | std::sys::unix::fs::try_statx]

Status: RESOLVED WORKSFORME

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

Description

[Gabriele Svelto [:gsvelto] (PTO)]

Crash report: https://crash-stats.mozilla.org/report/index/4ff52628-5f10-4d4e-a030-61d630210204

Reason: SIGSYS

Top 10 frames of crashing thread:

0 libc.so.6 syscall 
1 libxul.so std::sys::unix::fs::try_statx library/std/src/sys/unix/fs.rs:123
2 libxul.so std::fs::File::metadata library/std/src/fs.rs:501
3 libxul.so memmap::MmapOptions::get_len third_party/rust/memmap/src/lib.rs:121
4 libxul.so memmap::MmapOptions::map_mut third_party/rust/memmap/src/lib.rs:231
5 libxul.so audioipc::shm::SharedMemMutSlice::from media/audioipc/audioipc/src/shm.rs:227
6 libxul.so <audioipc_client::context::ClientContext as cubeb_backend::traits::ContextOps>::stream_init media/audioipc/client/src/context.rs:370
7 libxul.so cubeb_backend::capi::capi_stream_init third_party/rust/cubeb-backend/src/capi.rs:157
8 libxul.so cubeb_stream_init media/libcubeb/src/cubeb.c:355
9 libxul.so mozilla::AsyncCubebTask::Run dom/media/GraphDriver.cpp:309

Coming only from one user on nightly so I can't be sure it's a valid issue yet. The failing syscall is obviously statx() (332) and for once this seems to be happening from within rust code.

Comment 1

[Gian-Carlo Pascutto [:gcp]]

We should report ENOSYS when a process tries to use statx: bug 1591117.

Not sure how this could happen.

Comment 2

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

The call has weird arguments because it's expected to fail (statx(STDIN_FILENO, nullptr, 0, STATX_ALL, nullptr) in C++ terms), but that shouldn't matter, because we allow it with any arguments if there's a broker.

However, from the telemetry environment: effectiveContentProcessLevel: 1.

This is fixable, but (not for the first time) I wonder if there's any actual value in keeping that mode around for troubleshooting given that it's untested and keeps bit-rotting.

Comment 3

[Gian-Carlo Pascutto [:gcp]]

Non-standard config that we don't expect to be required, not urgent.

Comment 4

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

Closing because no crashes reported for 12 weeks.

Comment 5

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

(In reply to Jed Davis [:jld] ⟨⏰|UTC-6⟩ ⟦he/him⟧ from comment #2)

because we allow it with any arguments if there's a broker.

This is… probably not what I meant to say. If there's a broker then statx fails with ENOSYS; if not, then it takes the “invalid syscall” path, which crashes on Nightly and is ENOSYS otherwise.

Content processes at sandbox level 2 and up use a broker, but at level 1 they instead allow most filesystem syscalls (this is not meaningfully secure, but it was once useful for testing), except that statx was never added to that list, and thus we have this bug. Level 0 is no sandbox, so obviously not affected.

Currently we have no test coverage to make sure the lower sandbox levels aren't completely broken, but it occurs to me that we could do something with SpecialPowers.pushPrefEnv and BrowserTestUtils.openNewForegroundTab (with forceNewProcess: true) to fix that. In this case, it looks like we'd have needed the test page to play sound (rather than just load a trivial test page with some text) to catch this problem, and maybe that's more work than it's worth, but it can be done.

Comment 6

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

Closing because no crashes reported for 12 weeks.