It seems that the order of the arguments in the clone() syscall depends on the architecture (you can see that in the clone(2) manpage). We use that in WebKit's seccomp filter (glib/BubblewrapLauncher.cpp), and this is broken in s390x at least. Flatpak is also affected, and we are using the same code. Here's the fix for Flatpak: https://github.com/flatpak/flatpak/pull/3777/commits/6d70aabc03f0389e548911b14446d702a07b016c
(note: this **seems to be broken** in WebKit based on the fact that it is broken in Flatpak and we took that code, but it should be double checked)
(In reply to Alberto Garcia from comment #0) > It seems that the order of the arguments in the clone() syscall depends on > the architecture (you can see that in the clone(2) manpage). > > We use that in WebKit's seccomp filter (glib/BubblewrapLauncher.cpp), and > this is broken in s390x at least. > > Flatpak is also affected, and we are using the same code. Here's the fix for > Flatpak: > https://github.com/flatpak/flatpak/pull/3777/commits/ > 6d70aabc03f0389e548911b14446d702a07b016c (CC'ing Patrick, as he's our resident sandboxing expert.) Yes, we also need a similar fix in the WebKit sandboxing code. One would imagine that libseccomp takes care of this kind of busy-work… but it turns out that it's a pretty dumb wrapper around the kernel interface 🤷️
Created attachment 406081 [details] Patch
Comment on attachment 406081 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=406081&action=review > Source/WebKit/ChangeLog:3 > + [GLIB] Wrong argument order for clone syscall seccomp filter on s390x [WPE][GTK]
Created attachment 406083 [details] Patch for landing
Committed r265326: <https://trac.webkit.org/changeset/265326> All reviewed patches have been landed. Closing bug and clearing flags on attachment 406083 [details].