Debian Patches

Status for flatpak/1.16.6-1~deb13u2

Patch Description Author Forwarded Bugs Origin Last update
debian/system-helper-Set-Debian-s-canonical-home-directory-for-s.patch system-helper: Set Debian's canonical home directory for system users Simon McVittie <smcv@debian.org> not-needed 2025-03-10
subprojects-Ignore-.wraplock-file-generated-by-recent-Mes.patch subprojects: Ignore .wraplock file generated by recent Meson
(cherry picked from commit 0337cfde00886d7377da1ded7d2c8520f1d61415)		 Simon McVittie <smcv@collabora.com> no upstream, 1.16.7, commit:a554bae3b2474c1ae8c086a953a1d65be03a380b 2026-04-11
bwrap-Clarify-a-comment.patch bwrap: Clarify a comment
Now that we're passing the app's /app and /usr down to bwrap as O_PATH
file descriptors, it will be even more common to have non-seekable fds
in the array.

(cherry picked from commit dc9173b2d330f3ac411b135f261e81551db05f3f)		 Simon McVittie <smcv@collabora.com> no upstream, 1.16.7, commit:57a5f51199ea8f35e1236857d962e4ac6cbe2a57 2026-04-11
dir-Use-flatpak_bwrap_child_setup_inherit_fds_cb-to-apply.patch dir: Use flatpak_bwrap_child_setup_inherit_fds_cb() to apply extra-data

This is functionally equivalent to the local child_setup() deleted by
this commit, except that it ignores lseek() errors, which can
legitimately happen when inheriting a non-seekable file descriptor.
Since commit ac62ebe "run: Use O_PATH fds for the runtime and app
deploy directories", any extra-data helper that runs inside a runtime
will receive a non-seekable O_PATH fd as its /usr.

(cherry picked from commit 333459c8835ff95b245d97ee98cffec1c9f781d9)		 Simon McVittie <smcv@collabora.com> no upstream, 1.16.7, commit:fb1ed94d3c37c072f5e501e5b02c34073081d464 2026-04-11
subprojects-Update-dbus-proxy.wrap-to-v0.1.7.patch subprojects: Update dbus-proxy.wrap to v0.1.7
Versions up to 0.1.6 contain a security vulnerability, so let's bump it
to a version which does not.

(cherry picked from commit 2b942431d28c71b4046c34010525f400a6cf4ac7):		 Sebastian Wick <sebastian.wick@redhat.com> no upstream, 1.16.7, commit:e39581a798987d96ed786854fca75606d13fe5d7 2026-04-13
portal-Actually-use-the-AppInfo-hash-table.patch portal: Actually use the AppInfo hash table
Before this change, the hash table was populated with the keyfile as key
and value, but the lookup and invalidate was done on the sender as the
key.

We never found a previous sender, and never invalidated one.

Fix this by actually using the sender as the key.

(cherry picked from commit 993cc143d84aa08410979bf49358eba47cab1066):		 Sebastian Wick <sebastian.wick@redhat.com> no upstream, 1.16.7, commit:6a98dceb56edff29234a7493ae07d9607661f13b 2026-04-13
tests/tests-Fix-checks-where-we-expect-a-command-to-fail.patch tests: Fix checks where we expect a command to fail
I was convinced that the pattern `! command` with -e aborts when
`command` fails. This is not the case (the result of `false` is the same
as `! true` but somehow this doesn't matter).

Fix the tests and use the newly introduced `assert_fail` function. One
could also use `command && assert_not_reached "message"` but who has
time to write error messages for all the cases.

[We need this for some of the tests for later security fixes -smcv]

(cherry-picked from commit 68343e938f66051462e0ae3003d0acaca9a76a72)		 Sebastian Wick <sebastian.wick@redhat.com> no upstream, 1.17.7, commit:68343e938f66051462e0ae3003d0acaca9a76a72 2026-04-14
libglnx/chase-Add-internal-glnx_chaseat_full-for-a-strategic-call.patch chase: Add internal glnx_chaseat_full for a strategic callback
It takes a callback which gets called every time we try to open the next
segment of the path. This allows implementing more specific and advanced
use cases to be implemented without adding more complexity to the chase
algorithm itself.

[This is required for various later security fixes in Flatpak -smcv]

(cherry-picked from commit 4f8674709dce57e7f5422a475f61556162f930d8)		 Sebastian Wick <sebastian.wick@redhat.com> no upstream, 1.18.1, commit:4f8674709dce57e7f5422a475f61556162f930d8 2026-06-12
libglnx/chase-Add-glnx_chase_and_mkdirat.patch chase: Add glnx_chase_and_mkdirat
We found that there is a common use case where we need to get a
subdirectory (potentially multiple levels) which might not exist yet.
Adding another flag for this to GlnxChaseFlags is what systemd has done,
but creating a directory takes a mode, so the flag creates directories
with a fixed mode. This approach instead takes the mode as argument.

[This is required for various later security fixes in Flatpak -smcv]

(cherry-picked from commit ae7355612a68d39472ff3699104845d2cc5dfb4d)		 Sebastian Wick <sebastian.wick@redhat.com> no upstream, 1.18.1, commit:ae7355612a68d39472ff3699104845d2cc5dfb4d 2026-06-12
GHSA-99wv-m8rp-g58x/common-Fix-return-value-and-typos-in-flatpak_switch_symli.patch common: Fix return value and typos in flatpak_switch_symlink_and_remove

One error path returned -1 instead of FALSE. Since gboolean is gint,
-1 is truthy and the caller would skip error handling.		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream upstream, 1.18.1 2026-06-18
GHSA-99wv-m8rp-g58x/common-Use-fd-based-operations-in-flatpak_switch_symlink_.patch common: Use fd-based operations in flatpak_switch_symlink_and_remove
Replace path-based syscalls with fd-relative equivalents so callers
can pin the directory identity and prevent symlink substitution by a
concurrent process.		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream upstream, 1.18.1 2026-06-18
GHSA-99wv-m8rp-g58x/run-Harden-regenerate_ld_cache-against-symlink-attacks.patch run: Harden regenerate_ld_cache against symlink attacks
A sandboxed app can replace ~/.var/app/$appid/.ld.so with a symlink,
causing regenerate_ld_cache to write files at an arbitrary location.
A concurrent app instance makes this a TOCTOU even after the initial
directory verification.

Replace all path-based operations with fd-based equivalents using
ld_so_dir_fd obtained via glnx_chase_and_mkdirat, and pass the
directory to bwrap via --bind-fd instead of --bind.		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream upstream, 1.18.1 2026-06-18
GHSA-8688-9x26-hhxj/test-run-Check-that-the-way-com.valvesoftware.Steam-behav.patch test-run: Check that the way com.valvesoftware.Steam behaves still works

This use of symlinks to ensure that the canonicalized paths of
`$XDG_CACHE_HOME`, `$XDG_CONFIG_HOME`, `$XDG_DATA_HOME` are
`~/.cache`, `~/.config`, `~/.local/share` is the sort of thing that
could easily regress if not tested.

[backported to 1.18.x: adjust test numbering]		 Simon McVittie <smcv@collabora.com> yes upstream upstream, 1.18.1 2026-08-09
GHSA-8688-9x26-hhxj/run-Harden-ensure_data_dir-and-var-setup-against-symlink-.patch run: Harden ensure_data_dir and /var setup against symlink attacks
Replace path-based flatpak_mkdir_p calls in flatpak_ensure_data_dir
with glnx_chase_and_mkdirat(RESOLVE_NO_SYMLINKS) to prevent an app
from replacing subdirectories of its data dir with symlinks between
runs and having them followed during the next sandbox setup.

In flatpak_run_setup_base_argv, replace path-based --bind args for
the app cache/data/config/tmp directories with --bind-fd using fds
obtained via glnx_chaseat(RESOLVE_NO_SYMLINKS), preventing both
symlink following and TOCTOU races when setting up these bind mounts.		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream upstream, 1.18.1 2026-06-16
GHSA-8688-9x26-hhxj/tests-Add-a-regression-test-for-GHSA-8688-9x26-hhxj.patch tests: Add a regression test for GHSA-8688-9x26-hhxj
The original reporter used various tricks to find a way for the sandboxed
app to overwrite these locations with symlinks, but for the purposes
of this test, I'm doing the setup outside the sandbox instead: probably
not all of these potential exploit routes are actually possible, but we
defend against all of them symmetrically.

[backported to 1.18.x: adjust test numbering]		 Simon McVittie <smcv@collabora.com> yes upstream upstream, 1.18.1 2026-08-09
GHSA-jr92-2v97-wgvc/oci-Use-gsize-for-OCI-delta-sizes.patch oci: Use gsize for OCI delta sizes
The delta varint parser decoded into guint64 values which were then
passed to GLib I/O and allocation functions that take gsize. On 32-bit
systems where gsize is 32 bits this silently truncated the values.

Change the varint output and all delta operation size parameters to
gsize, and clamp the parsed value to G_MAXSIZE.		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream upstream, 1.18.1 2026-06-29
GHSA-jr92-2v97-wgvc/oci-Avoid-overflow-in-delta_read_data.patch oci: Avoid overflow in delta_read_data
delta_read_data computed g_malloc(size + 1) where size came from the
delta stream. If size equals G_MAXSIZE, size + 1 wraps to zero and
g_malloc returns a minimal allocation, then g_input_stream_read_all
writes size bytes into it — a heap buffer overflow.		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream upstream, 1.18.1 2026-07-27
GHSA-jr92-2v97-wgvc/oci-Limit-delta-path-length-to-PATH_MAX.patch oci: Limit delta path length to PATH_MAX
The previous commit ensures that there isn't a heap overflow when
reading a huge delta path, but we should also just reject unreasonably
long paths. So we chose the arbitrary limit of PATH_MAX and assume that
anything beyond that arbitrary limit is probably abusive.		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream upstream, 1.18.1 2026-07-06
GHSA-r7hp-698j-2h6c/run-dbus-Correct-broadcast-rules-for-the-AT-SPI-bus.patch run-dbus: Correct --broadcast rules for the AT-SPI bus
These had the *INTERFACE*.*METHOD* where the bus name should have been,
and a blank interface/method (meaning match any interface/method).
Because there's no bus name of that name on the AT-SPI bus, the only reason
why Flatpak apps were able to receive these broadcasts is that there was
a vulnerability in xdg-dbus-proxy, tracked as GHSA-r7hp-698j-2h6c. To
avoid regressions in Flatpak when the x-d-p vulnerability is fixed,
we need to correct these rules to have the intended bus name.		 Simon McVittie <smcv@collabora.com> yes upstream upstream, 1.18.1 2026-07-26
GHSA-v2gw-v9h5-9q4x/ref-utils-Make-remote-name-validation-public-and-take-an-.patch ref-utils: Make remote name validation public and take an error
We should be consistent with the validation in the session-helper, so
let's make this validation function available to it.		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream upstream, 1.18.1 2026-08-03
GHSA-v2gw-v9h5-9q4x/system-helper-Validate-each-remote-name-and-architecture-.patch system-helper: Validate each remote name and architecture argument
We pass them on to internal functions which assume that they are valid,
and specifically also create paths which contain those strings which can
be used for path traversal attacks.

Let's simply consistently validate all of those arguments.

[backported to 1.18.x: previous incomplete validity checks weren't on this branch]		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream upstream, 1.18.1 2026-08-09
GHSA-v2gw-v9h5-9q4x/tests-Add-some-unit-tests-for-ref-utils-name-component-va.patch tests: Add some unit tests for ref-utils name component validation
In the fix for GHSA-v2gw-v9h5-9q4x these functions are used to avoid
path traversal, so we'd better assert that they do detect and avoid it.		 Simon McVittie <smcv@collabora.com> yes upstream upstream, 1.18.1 2026-08-04
GHSA-qrwq-7qwx-q9rp/revokefs-Avoid-symlink-path-traversal-out-of-basefd-in-si.patch revokefs: Avoid symlink path traversal out of basefd in simple cases
Use glnx_chaseat to ensure that all the attacker-controlled paths end up
inside the basefd directory.

This requires some new helper functions, which will be used in more
complicated syscalls' implementations in subsequent commits.

[smcv: Separated from a larger commit for better reviewability]		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream upstream, 1.18.1 2026-07-29
GHSA-qrwq-7qwx-q9rp/revokefs-Avoid-symlink-path-traversal-in-link-rename.patch revokefs: Avoid symlink path traversal in link(), rename()
Again, use glnx_chaseat to ensure that all the attacker-controlled paths
end up inside the basefd directory. These two syscalls are a bit more
complicated, and take two paths.

[smcv: Separated from a larger commit for better reviewability]		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream upstream, 1.18.1 2026-07-29
GHSA-qrwq-7qwx-q9rp/revokefs-Avoid-symlink-path-traversal-in-symlink.patch revokefs: Avoid symlink path traversal in symlink()
Use glnx_chaseat to ensure that the attacker-controlled symlink name
ends up inside the basefd directory. Note that the symlink *target* is
also attacker-controlled, but it's OK for them to be able to set any
target of their choice: that can't immediately cause traversal outside
the base directory.

[smcv: Separated from a larger commit for better reviewability]		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream upstream, 1.18.1 2026-07-29
GHSA-qrwq-7qwx-q9rp/revokefs-Avoid-symlink-path-traversal-in-chmod.patch revokefs: Avoid symlink path traversal in chmod()
Use glnx_chaseat to ensure that all the attacker-controlled paths end up
inside the basefd directory, and then AT_SYMLINK_NOFOLLOW to make sure
that the last path component won't escape from the basefd.

On kernels >= 6.6 we can now use fchmodat() with AT_SYMLINK_NOFOLLOW,
but on older kernels that didn't work, so if necessary fall back to
opening the file with O_NOFOLLOW and then calling fchmod() on it.

Because this is the last syscall that used the previous (flawed)
validation mechanism, we can now remove the validation helpers and be
sure that everything is using the glnx-chaseat()-based replacements.

[smcv: Separated from a larger commit for better reviewability]		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream upstream, 1.18.1 2026-07-29
GHSA-w69g-9x8j-7p8f/dir-utils-Reject-path-traversal-in-extension-metadata.patch dir-utils: Reject path traversal in extension metadata
Validate extension directory, subdir_suffix, add_ld_path, and
merge_dirs at parse time, rejecting absolute paths and paths with
.. components that escape the intended mount point. This prevents
extension metadata from mounting content at unintended locations
inside the sandbox.		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream upstream, 1.18.1 2026-06-29
GHSA-w69g-9x8j-7p8f/run-Use-RESOLVE_BENEATH-for-host-side-extension-file-acce.patch run: Use RESOLVE_BENEATH for host-side extension file access
Extension content is controlled by the extension developer. When setting
up the sandbox, Flatpak accesses the .ref file and iterates merge_dirs
within the extension's files directory on the host using path-based
operations that follow symlinks. A malicious extension can place symlinks
that escape the extension directory, causing Flatpak's host process to
access arbitrary host paths. This discloses host directory listings to
the sandboxed application via the resulting merge symlinks.

Use glnx_chaseat with GLNX_CHASE_RESOLVE_BENEATH to confine path
resolution to the extension's files directory.		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream upstream, 1.18.1 2026-06-29
hardening/dir-Use-fd-based-traversal-for-marker-files-in-deploy-dir.patch dir: Use fd-based traversal for marker files in deploy directories
The paths up to files/ are not attacker-controlled, and
g_file_replace_contents with G_FILE_CREATE_REPLACE_DESTINATION already
replaces symlinks rather than following them, so this is not a security
fix. The only reason why is that the file is in the root of the attacker
controlled directory.

This is a bit subtle, so lets do the right thing and concistently use
fd-relative operations when doing anything inside attacker/app
controlled directories.		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream upstream, 1.18.1 2026-07-03
hardening/dir-Harden-confining-subpath-deploy-to-the-deploy-base.patch dir: Harden confining subpath deploy to the deploy base
Subpaths passed via D-Bus to the system helper are not validated, so
a value containing ".." components is accepted.

The only reason why this isn't exploitable is because we resolve the
path relative to `root` via g_file_resolve_relative_path, where root is
a OstreeRepoFile which will return FALSE when it encounters ".." or
symlinks.

Harden the code by using glnx_chase_and_mkdirat with RESOLVE_BENEATH to
create parent directories, and check out into the resulting fd.		 Sebastian Wick <sebastian.wick@redhat.com> no upstream, 1.18.1 2026-06-29
GHSA-q4gr-vc25-57m5/dir-Fall-back-to-the-deployed-ref-commit-when-up-downgrad.patch dir: Fall back to the deployed ref commit when up/downgrading
Otherwise, if an unprivileged user manages to remove the remote ref, the
downgrading protection is not in effect.		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream upstream, 1.18.1 2026-08-03
GHSA-q4gr-vc25-57m5/system-dir-Prevent-removing-of-deployed-refs-via-the-syst.patch system-dir: Prevent removing of deployed refs via the system-helper
We have two use cases for removing refs: uninstalling, and pruning of
undeployed refs. Pruning undeployed refs is something we want anyone to
be able to do, because they can also pull updates and then not deploy
them. Uninstalling arbitrary refs on the other hand is problematic, and
its possible to remove the AppStream ref, and a deployed ref.

So we split removing a ref into a function which removes any ref, and
use it internally to implement e.g. uninstalling, and a function to
remove refs which are safe to remove. Only the latter one will escalate
through the system helper, making it harder for unprivileged users to
get into a state which can be exploited.

See the previous commit for such a state.		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream upstream, 1.18.1 2026-08-03
GHSA-fqx6-vh4p-42cg-GHSA-8qxj-x646-phcm/utils-Add-flatpak_cp_a_at-a-fd-based-flatpak_cp_a-variant.patch utils: Add flatpak_cp_a_at, a fd-based flatpak_cp_a variant
For all the usual reasons where an attacker might control a symlink.

For simplicity this does not implement the unused FLATPAK_CP_FLAGS_MOVE
flag.

[smcv: Separated from a larger commit]		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream upstream, 1.18.1 2026-06-29
GHSA-fqx6-vh4p-42cg-GHSA-8qxj-x646-phcm/utils-Make-flatpak_cp_a-a-wrapper-around-flatpak_cp_a_at.patch utils: Make flatpak_cp_a a wrapper around flatpak_cp_a_at
[smcv: Separated from a larger commit]		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream upstream, 1.18.1 2026-06-29
GHSA-fqx6-vh4p-42cg-GHSA-8qxj-x646-phcm/build-init-Use-fd-relative-operations-to-prevent-path-tra.patch build-init: Use fd-relative operations to prevent path traversal
ensure_extensions() used g_file_resolve_relative_path() with
ext->directory, which comes from runtime/SDK metadata and can contain
".." components. This allowed a malicious extension to write outside
the build directory.

Replace the GFile-based path resolution with glnx_chase_and_mkdirat()
using GLNX_CHASE_RESOLVE_BENEATH | GLNX_CHASE_RESOLVE_NO_SYMLINKS,
which rejects any path that escapes the directory fd.

Convert the rest of flatpak_builtin_build_init to fd-relative
operations (mkdirat, symlinkat, glnx_opendirat, glnx_shutil_rm_rf_at,
glnx_file_replace_contents_at, flatpak_cp_a_at) anchored to a
base_dfd opened from the build directory.		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream upstream, 1.18.1 2026-06-29
GHSA-fqx6-vh4p-42cg-GHSA-8qxj-x646-phcm/dir-Validate-extra-data-name.patch dir: Validate extra-data name
Reject extra-data names containing ".", "..", or "/" early during the
download phase. The name is used to construct a local cache file path
via flatpak_build_file() which uses g_file_resolve_relative_path(),
so ".." components could traverse outside the cache directory.

In practice this is not exploitable: the local cache path is only
used for a g_file_query_exists() check followed by g_file_load_contents(),
and the loaded content is verified against the expected sha256 from
the commit metadata.

[smcv: Backport to 1.16.x where pull_extra_data_to_bytes() wasn't factored out]		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream backport, 1.18.1 2026-08-07
GHSA-fqx6-vh4p-42cg-GHSA-8qxj-x646-phcm/dir-Use-chaseat-in-extract_extra_data-to-prevent-path-tra.patch dir: Use chaseat in extract_extra_data to prevent path traversal
extract_extra_data() had two vulnerabilities:

1. It resolved "files/extra" using g_file_resolve_relative_path()
which follows symlinks. A crafted OSTree commit with "files" as a
symlink causes extra-data blobs to be written at the symlink target.
On system installs this runs as root via the system helper, which
validates signatures and checksums but not tree structure.

2. It used g_file_get_child(extradir, name) where name comes from
xa.extra-data-sources in the commit metadata. Names containing ".."
escape the extra/ directory. This is exploitable through the normal
build flow: flatpak build-export rejects "/" but not "..".

Replace GFile path operations with fd-relative operations: open
"files" with glnx_chaseat using GLNX_CHASE_RESOLVE_NO_SYMLINKS,
create "extra" with glnx_chase_and_mkdirat using
GLNX_CHASE_RESOLVE_BENEATH, validate extra-data names against ".",
"..", and "/", and write with glnx_file_replace_contents_at anchored
to the extra directory fd.

[smcv: Open checkoutdir_dfd before trying to open its files subdir]		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream upstream, 1.18.1 2026-08-07
GHSA-fqx6-vh4p-42cg-GHSA-8qxj-x646-phcm/dir-Use-chaseat-in-apply_extra_data-to-prevent-path-trave.patch dir: Use chaseat in apply_extra_data to prevent path traversal
apply_extra_data() used GFile path-based operations that follow
directory path, and flatpak_cp_a for the extra/export merge.

These are not independently exploitable: apply_extra_data only runs
after extract_extra_data has already created files/extra as a real
directory, so there is no symlink left to follow. The apply_extra
script itself runs in a restricted sandbox with dropped caps and no
/proc. The extra/export merge only adds to the app's own export
directory, which is already app-controlled and whose desktop file
Exec keys are rewritten to flatpak run.

Replace with fd-relative operations as defense in depth:
glnx_chaseat with GLNX_CHASE_RESOLVE_NO_SYMLINKS and
GLNX_CHASE_RESOLVE_BENEATH for directory traversal,
--ro-bind-fd/--bind-fd for bwrap mounts, fchmod on the directory fd,
and flatpak_cp_a_at for the export merge.

[smcv: Use glnx_fd_reopen() to reopen O_PATH fd as readable]		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream upstream, 1.18.1 2026-08-07
GHSA-fqx6-vh4p-42cg-GHSA-8qxj-x646-phcm/utils-Remove-unused-GFile-based-flatpak_cp_a.patch utils: Remove unused GFile based flatpak_cp_a
We use the fd based flatpak_cp_a_at now everywhere, so we can drop this
one.		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream upstream, 1.18.1 2026-06-29

All known versions for source package 'flatpak'

Links