Repository navigation
Avoid leaking --app-fd, etc. down to wrapped command - #6589
Conversation
Helps: flatpak#6582 Signed-off-by: Simon McVittie <[email protected]>
On entry to `flatpak run`, these fds have been inheritable (not FD_CLOEXEC), otherwise they would not have been inherited; but we don't want the "payload" command to inherit them, so set them as non-close-on-exec as soon as we receive them. In the cases where we pass them down to the underlying bwrap command, we'll either dup them, or set them to be inheritable again (in practice we dup them). In particular, Chromium-derived web browsers get very upset when their subsandbox processes inherit unexpected fds, which has been causing crashes with no useful diagnostic information since CVE-2026-34078 was fixed. Fixes: 1b5e886 "run: Add --usr-fd and --app-fd options" Fixes: b5ae89e "run: Add --(ro-)bind-fd options" Resolves: flatpak#6582 Signed-off-by: Simon McVittie <[email protected]>
|
Also works for org.chromium.Chromium and com.brave.Browser. com.vivaldi.Vivaldi was briefly crashing with |
|
Or maybe |
... but that does seem out-of-scope for its name, and we also definitely don't want to be making stdin, stdout or stderr be CLOEXEC. |
| if (fd < 3) | ||
| return glnx_throw (error, "File descriptors 0, 1, 2 are reserved"); |
There was a problem hiding this comment.
bit unrelated, but I noticed that the autofd will close fd 0, 1, 2 here which isn't the intent; maybe worth fixing in this PR as well
There was a problem hiding this comment.
Can I do that as a followup? I'd like to keep the regression fix relatively minimal/simple, and I'm less concerned about misbehaviour when invoking Flatpak in ways that don't make sense anyway.
Yeah, this PR is good for now. As a follow up we could create another function which does the check for <=3 and sets cloexec. |
|
This took way too long to figure out. I really think we should try to test for this. |
Yeah, I have some ideas. I'd like to get the actual regression fix merged so we can stop the bleeding, but I can work on a test (and the other followups mentioned above) today. |
exec 3< custom-app/files
exec 4< custom-runtime/files
exec 5< "${path}"
exec 6< "${path}"
run --app-fd=3 --usr-fd=4 --bind-fd=5 --ro-bind-fd=6 \
--command=sh org.test.Hello \
-c 'for fd in $(ls /proc/self/fd); do readlink -f /proc/self/fd/$fd; done' > hello_out
exec 6>&-
exec 5>&-
exec 4>&-
exec 3>&-
wd="$(readlink -f .)"
while read fdpath; do
if [[ "$fdpath" == "$wd"* && "$fdpath" != "$wd/hello_out" ]]; then
assert_not_reached "A fd for '$fdpath' unexpectedly made it to the app"
fi
done < hello_out
ok "check no fd leak"Came up with this, but every now and then it seems to succeed when it should not (but never the other way around at least). |
Backport upstream github PR #6589 (commits 79d3e09, e0cd581) which fixes file descriptor leakage to sandboxed child processes. The CVE-2026-34078 fix in 1.16.4 inadvertently caused --app-fd, --usr-fd, --bind-fd, and --ro-bind-fd to lose their FD_CLOEXEC flag, resulting in unexpected fd inheritance by subsandbox processes. Chromium-based browsers crash on every launch after the first run due to this. The fix sets close-on-exec on these fds immediately upon receipt. Upstream: flatpak/flatpak#6589 Fixes: flatpak/flatpak#6582
2 participants
utils: Add flatpak_set_cloexec()
Helps: [Bug]: Chromium-based browsers (including Brave) crash with 1.16.5 #6582
run, context: Mark fd arguments as close-on-exec
On entry to
flatpak run, these fds have been inheritable (notFD_CLOEXEC), otherwise they would not have been inherited; but we don't
want the "payload" command to inherit them, so set them as
non-close-on-exec as soon as we receive them. In the cases where we pass
them down to the underlying bwrap command, we'll either dup them, or
set them to be inheritable again (in practice we dup them).
In particular, Chromium-derived web browsers get very upset when their
subsandbox processes inherit unexpected fds, which has been causing crashes
with no useful diagnostic information since CVE-2026-34078 was fixed.
Fixes: 1b5e886 "run: Add --usr-fd and --app-fd options"
Fixes: b5ae89e "run: Add --(ro-)bind-fd options"
Resolves: [Bug]: Chromium-based browsers (including Brave) crash with 1.16.5 #6582
This works for me with at least Ungoogled Chromium. Tests with other Chromium-derived browsers welcome. Ideally we'd have an automated test for this, but I thought it would be better to get a potential solution available first.
With many thanks to @swick for figuring out why Chromium subprocesses were crashing!