| Summary: | [WPE][GTK] Wrong argument order for clone syscall seccomp filter on s390x | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Alberto Garcia <berto> | ||||||
| Component: | WebKitGTK | Assignee: | Adrian Perez <aperez> | ||||||
| Status: | RESOLVED FIXED | ||||||||
| Severity: | Normal | CC: | aperez, bugs-noreply, cgarcia, mcatanzaro, pgriffis | ||||||
| Priority: | P2 | ||||||||
| Version: | Other | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Attachments: |
|
||||||||
|
Description
Alberto Garcia
2020-08-06 04:37:08 PDT
(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]. |