1652404 - Crash in [@ __openat64_nocancel] (actually fcntl F_SETFL with FMODE_NONOTIFY)

Status: RESOLVED DUPLICATE of bug 1650751

(Core :: Security: Process Sandboxing, defect)

Description

[Gabriele Svelto [:gsvelto]]

This bug is for crash report bp-deef8377-1463-4ed1-9216-f4a350200710.

Top 10 frames of crashing thread:

0 libc.so.6 __openat64_nocancel /usr/src/debug/glibc-2.31/io/../sysdeps/unix/sysv/linux/openat64_nocancel.c:40
1 libc.so.6 lockf /usr/src/debug/glibc-2.31/io/lockf.c:58
2 libglib-2.0.so.0 <name omitted> ../glib/glib-unix.c:177
3 libgio-2.0.so.0 g_socket_constructed ../gio/gsocket.c:709
4 libgobject-2.0.so.0 g_object_new_internal ../gobject/gobject.c:1977
5 libgobject-2.0.so.0 <name omitted> ../gobject/gobject.c:2262
6 libgio-2.0.so.0 g_initable_new_valist ../gio/ginitable.c:244
7 libgio-2.0.so.0 <name omitted> ../gio/ginitable.c:162
8 libgio-2.0.so.0 <name omitted> ../gio/gsocket.c:1290
9 libgio-2.0.so.0 create_socket ../gio/gsocketclient.c:136

This is suspiciously similar to bug 1650751 but with openat() instead of fcntl(). Jed, does this require a separate fix? If not just duplicate it against bug 1650751.

Comment 1

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

This looks like a dup of bug 1650751, but it's weird: the syscall number is 0x48, which is fcntl (and in particular , and the line numbers in the stack match the path to the F_SETFL problem in bug 1650751 in a recent version of the glib source that I looked at, except for those last two which are in libc. Is the debug info incorrect?

Also, the stack trace indicates that:

1. this was an attempt to connect to DBus, which isn't allowed and can't be allowed for security reasons; whatever is going on here will fail eventually
2. that in turn was caused by initializing GTK and loading its styles, which will eventually be removed from content processes; see also bug 1640345 and bug 1470983

Note that bug 1650751 causes problems in other cases; e.g., bp-20f2b7da-5e0e-4741-a8b5-0dcf50200711 and bp-da4e61c4-8b6f-4375-934f-0448f0200707 are both from WebRTC.

Comment 2

[Gabriele Svelto [:gsvelto]]

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

This looks like a dup of bug 1650751, but it's weird: the syscall number is 0x48, which is fcntl (and in particular , and the line numbers in the stack match the path to the F_SETFL problem in bug 1650751 in a recent version of the glib source that I looked at, except for those last two which are in libc. Is the debug info incorrect?

I know what's going on: it's possible that code for both functions has been merged and thus there's multiple symbols in the debuginfo corresponding to the same address. In that case the stack walker will just pick the first one which often leads to these weird results where we're obviously calling a different function.