1622728 - Crash in [@ __fcntl64_nocancel_adjusted] (F_ADD_SEALS)

Status: RESOLVED FIXED

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

Description

[Gabriele Svelto [:gsvelto]]

This bug is for crash report bp-2fa97d8f-54e5-4b0e-9649-fa2900200314.

Top 10 frames of crashing thread:

0 libc-2.31.so __fcntl64_nocancel_adjusted 
1 libc-2.31.so __GI___fcntl 
2 libwayland-cursor.so.0.0.0 wl_cursor_frame 
3 libwayland-cursor.so.0.0.0 wl_cursor_theme_load 
4 libgdk-3.so.0.2407.7 gdk_wayland_display_set_cursor_theme 
5 libgtk-3.so.0.2407.7 gtk_settings_reset_property 
6 libgtk-3.so.0.2407.7 gtk_rc_property_parse_color 
7 libgobject-2.0.so.0.6400.1 g_closure_invoke 
8 libgobject-2.0.so.0.6400.1 g_signal_accumulator_first_wins 
9 libgobject-2.0.so.0.6400.1 g_signal_emit_valist 

This looks like a sandboxing issue with fcntl64(). It seems to be happening only on Arch with kernels 5.5.5+ and Wayland. Since it seems Arch-specific I'm CC'ing the maintainer.

This seems to be happening only on nightly and started with buildid 20200214155124.

Comment 1

[Jan Alexander Steffens [:heftig]]

Unfortunately, the backtrace doesn't make much sense. I don't see how wl_cursor_frame (or its leaf, wl_cursor_frame_and_duration) could call fcntl.

Comment 2

[Gabriele Svelto [:gsvelto]]

Right, we don't have debug symbols for that library so the stack walker is taking a guess and it's the wrong one. I'll try to get a better stack by picking a different frame manually.

Comment 3

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

Arguments:

"rdi": "0x000000000000002d",
"rsi": "0x0000000000000409",
"rdx": "0x0000000000000003",

Some relevant definitions:

#define F_LINUX_SPECIFIC_BASE       1024
#define F_ADD_SEALS     (F_LINUX_SPECIFIC_BASE + 9)

So that's fcntl(fd, F_ADD_SEALS, F_SEAL_SEAL|F_SEAL_SHRINK), if I'm reading that right? Giving the Wayland server a shared memory area that can be written and grown but not shrunk, to retrieve possibly large data of unknown size, maybe?

There's nothing obviously dangerous about allowing sealing in content processes if we need to.

Comment 4

[Jan Alexander Steffens [:heftig]]

Wayland added such a call call in 1.18: https://gitlab.freedesktop.org/wayland/wayland/-/commit/6908c8c85a2e33e5654f64a55cd4f847bf385cae

We released wayland 1.18.0 on 2020-02-12, so this fits.

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

Giving the Wayland server a shared memory area that can be written and grown but not shrunk, to retrieve possibly large data of unknown size, maybe?

This way the process receiving the memory can be sure the sender can't provoke a SIGBUS in the receiver.

Comment 5

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

Attachment: Bug 1622728 - Allow file seals in content process sandbox policy, for Wayland.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/28b465d8b9c5
Allow file seals in content process sandbox policy, for Wayland. r=gcp

Comment 7

[Cristina Coroiu [:ccoroiu]]

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