Debian Patches

Status for flatpak/1.14.10-1~deb12u2

Patch Description Author Forwarded Bugs Origin Last update
portal-Use-G_LOCK_DEFINE_STATIC.patch portal: Use G_LOCK_DEFINE_STATIC
The `update_monitors` lock lives in the global namespace and is not
used by other compile units, so make it static.		 Georges Basile Stavracas Neto <georges.stavracas@gmail.com> no upstream, flatpak-1.14.x branch, commit:1e43d5dc9ec1c73efe13420f1eff36c65b7ee870 2025-03-11
portal-Don-t-run-method-invocations-in-a-thread.patch portal: Don't run method invocations in a thread
Most access to the `client_pid_data_hash` hash table are unsafe due to
threading.

One approach to solve this would be to protect the hash table with a
mutex, but as per a deeper analysis, nothing in these callbacks is
slow or heavy enough to justify the need for separate threads.

Make method invocations run in the main thread.		 Georges Basile Stavracas Neto <georges.stavracas@gmail.com> yes upstream upstream, flatpak-1.14.x branch, commit:c11cbbfce1b8c469e7802ea81a1ccfa1337562fa 2025-03-11
CVE-2026-34078-prep/backports-Add-g_clear_fd.patch backports: Add g_clear_fd Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream libglnx, commit:cdce8957b2b53065b9936e6f6ed7a973234f1692 2026-01-24
CVE-2026-34078-prep/glnx-errors.h-add-glnx_fd_throw-_-variants.patch glnx-errors.h: add glnx_fd_throw[_*] variants
Similar to the glnx_null_throw variants, this one returns -1 instead of
FALSE or NULL. This is helpful when dealing with functions which return
a fd.		 Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream libglnx, commit:c33f0ed05e15f15bbf68cd2989b08903d9d00044 2026-01-24
CVE-2026-34078-prep/fdio-Add-glnx_fd_reopen.patch fdio: Add glnx_fd_reopen
Reopens the specified fd with new flags. This is useful for convert an
O_PATH fd into a regular one, or to turn O_RDWR fds into O_RDONLY fds.		 Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream libglnx, commit:1ec49dfc9b7a1b54cbcc5f6b6c816c1f49c0d84e 2026-02-17
CVE-2026-34078-prep/missing-Add-syscall-and-structs-for-statx.patch missing: Add syscall and structs for statx()
They are taken from an older revision of systemd with minimal changes.		 Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream libglnx, commit:14578d856e5ede9ca82ea46cf481b1e950e7855d 2026-02-25
CVE-2026-34078-prep/fdio-Add-glnx_statx.patch fdio: Add glnx_statx Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream libglnx, commit:01508367b486f0ac37b196994760200464c0116d 2026-02-25
CVE-2026-34078-prep/missing-Add-syscall-number-for-openat2-and-open_tree.patch missing: Add syscall number for openat2() and open_tree()
They are taken from an older revision of systemd with minimal changes.		 Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream libglnx, commit:2a75ac86e95f01a429f10ab4084b7f7e7217b986 2026-01-25
CVE-2026-34078-prep/chase-Add-glnx_chaseat-which-functions-similar-to-openat2.patch chase: Add glnx_chaseat which functions similar to openat2
The selling features are:

* Support for RESOLVE_BENEATH, RESOLVE_IN_ROOT and RESOLVE_NO_SYMLINKS
* Fallback from openat2 to open_tree to openat for compatibility
* Triggering of automounts		 Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream libglnx, commit:a973baad083aeee61d57245b0b3dd208ce42d930 2026-02-17
CVE-2026-34078-prep/chase-Add-glnx_chase_and_statxat.patch chase: Add glnx_chase_and_statxat
This combines glnx_chaseat with a call to glnx_statx for convenience.		 Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream libglnx, commit:b4b9951901ddb8d15374fcc24bd78d2dcce98fc9 2026-02-07
CVE-2026-34078-prep/chase-Don-t-left-shift-signed-integer-1-by-31-places.patch chase: Don't left-shift signed integer 1 by 31 places
This overflows, which is undefined behaviour (in practice it will usually
wrap around into unsigned space, but this can't be guaranteed).		 Simon McVittie <smcv@collabora.com> yes debian upstream libglnx, commit:916b70619c44cd7736b2d4f9d2e8ae0ee5ddab28 2026-03-24
CVE-2026-34078-prep/chase-Don-t-leak-struct-glnx_statx-when-we-go-up-a-level.patch chase: Don't leak struct glnx_statx when we go up a level Simon McVittie <smcv@collabora.com> yes debian upstream libglnx, commit:46205a62d2c6f96ecdb9eba6f2217a5745def134 2026-03-24
CVE-2026-34078-prep/chase-Factor-out-a-function-to-append-to-the-queue.patch chase: Factor out a function to append to the queue Simon McVittie <smcv@collabora.com> yes debian upstream libglnx, commit:6dbe18bcda03228f377f088a3a4f374b64d06865 2026-03-24
CVE-2026-34078-prep/build-Add-glnx-chase.-ch-to-subprojects.patch build: Add glnx-chase.[ch] to subprojects
This was unnecessary in Flatpak 1.16.x, which use Meson, but is
necessary in the 1.14.x backport. Similar to
https://gitlab.gnome.org/GNOME/libglnx/-/commit/e3006ead94a7d2c89701f011de651bce9fe6539d
upstream.		 Simon McVittie <smcv@debian.org> not-needed debian upstream 2026-04-06
CVE-2026-34078-prep/build-Link-libglnx-into-libflatpak-common-not-just-into-l.patch build: Link libglnx into libflatpak-common, not just into libflatpak
We'll need this for glnx_chaseat().		 Simon McVittie <smcv@collabora.com> not-needed debian upstream 2026-04-06
CVE-2026-34078/flatpak-bwrap-Add-dup-ing-variant-flatpak_bwrap_add_args_.patch flatpak-bwrap: Add dup-ing variant flatpak_bwrap_add_args_data_fd_dup Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream upstream, 1.16.4, commit:36bd977772ea0df7159ff207f89564bfccd3b0ca 2026-02-06
CVE-2026-34078/utils-Add-flatpak_parse_fd.patch utils: Add flatpak_parse_fd
This is meant to parse file descriptor strings passed via the command
line. It is not a security mechanism and will happily accept fds 0-3 as
well.

[smcv: Resolve conflicts with 1.14.x]		 Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream backport, 1.16.4, commit:fbe5a2faa776e0f5bdd6160c1dd69b0b97c2d8eb 2026-02-06
CVE-2026-34078/flatpak-bwrap-Use-glnx_close_fd-as-clear-func.patch flatpak-bwrap: Use glnx_close_fd as clear func
We already have a function which clears a fd that a pointer points to,
so let's use it instead of duplicating the code.

Will become useful in a later commit as well.		 Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream upstream, 1.16.4, commit:5a7e677294c92c04ea8c7c09a2b1abd2988f03df 2026-02-06
CVE-2026-34078/run-Use-O_PATH-fds-for-the-runtime-and-app-deploy-directo.patch run: Use O_PATH fds for the runtime and app deploy directories
This also allows us to use glnx_chaseat, and other at-functions to
traverse the filesystem tree in a safe way.

This is important because the app and runtime deploy directories can be
under an attackers control. The flatpak portal for example allows
sandboxed apps to provide them.

In particular, attacks where the deploy dirs get replaced by a symlink
pointing into the host system will be stopped by this.

Note that this change alone is not enough to avoid the attack, and the
portal has to be changed as well.

[smcv: Resolve conflicts with 1.14.x]		 Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream backport, 1.16.4, commit:873ed8b3718bd1a77343091ad7838f120729cdb3 2026-02-06
CVE-2026-34078/run-Add-usr-fd-and-app-fd-options.patch run: Add --usr-fd and --app-fd options
Exposes options to pass in a fd for the runtime and app deploy. The
flatpak portal will make use of this in a following commit.		 Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream upstream, 1.16.4, commit:494c5ea687be884487fa5dc8b943130d9df7bb5f 2026-02-06
CVE-2026-34078/run-Add-ro-bind-fds-to-flatpak_run_app.patch run: Add (ro-)bind fds to flatpak_run_app
The flatpak portal allows apps to expose files and folders from within
the sandbox to a side-sandbox using flatpak-spawn. So far it has used
the --filesystem option to mount those files and folders, but it takes a
path. Paths are inherently racy and they allow the app to swap out any
component of the path with a symlink after handing it off. If they win
the race, flatpak will mount a completely different directory.

This adds a new way to mount files and directories based on O_PATH
file descriptor that needs to provided when execing the flatpak binary.

[smcv: Resolve conflicts with 1.14.x]		 Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream backport, 1.16.4, commit:4f1e7f8d1705488e501925255fbe061ac71405fc 2026-02-06
CVE-2026-34078/run-Add-ro-bind-fd-options.patch run: Add --(ro-)bind-fd options
Exposes the functionality added to flatpak_run_app in the previous
commit with two new options.

[smcv: Resolve conflicts with 1.14.x]		 Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream backport, 1.16.4, commit:a971671f9546a20e2134afde31b317ff140e5bd9 2026-02-06
CVE-2026-34078/portal-Use-bind-fd-app-fd-and-usr-fd-options-to-avoid-rac.patch portal: Use --bind-fd, --app-fd and --usr-fd options to avoid races
Now that flatpak_run_app accepts fds for app and runtime deploy, as well
as bind and ro-bind fds, and flatpak-run exposes the functionality, we
can finally hook this all up to the flatpak portal!

[smcv: Resolve conflicts with 1.14.x]		 Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream backport, 1.16.4, commit:c82a3d7716bd02961d8c68b1d18256dfea19efc5 2026-02-06
CVE-2026-34079/utils-Only-remove-cached-files-in-the-cache-directory.patch utils: Only remove cached files in the cache directory
The function flatpak_switch_symlink_and_remove is used to implement a
cache for ld.so (regenerate_ld_cache). If the active symlink changes to
a new cache file, the old cache file is supposed to get removed.

The symlink still points to the old cache file, so we would remove the
file that it points to and then point at the new file.

Because the symlink is under the app's control, the symlink can point
anywhere, and the removal happens in the host context, which allows an
app to remove arbitrary files on the host.

The filename of the cache files are checksums, which means that we can
ensure that the link is a file in the same directory of the link by
checking that it only contains the chars a-zA-Z0-9.		 Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream upstream, 1.16.4, commit:c97905c8188ddaad01ee146b57bba6c3fa294113 2026-01-09
GHSA-2fxp-43j9-pwvc/utils-Do-not-follow-symlinks-in-local_open_file.patch utils: Do not follow symlinks in local_open_file
We use local_open_file in the context of the system helper to open
files written by a user. This means that we want to prevent DOS and
exposing files which only the system helper has access to.

To prevent DOS and avoid side-effects, the file is opened with
O_NONBLOCK and O_NOCTTY.

To prevent leaking files, the file is supposed to not open symlinks.
This part, we failed at. We check if the opened file is a regular file,
but what we actually checked is, if the file a symlink might point at is
a regular file.

Fix this by also specifying O_NOFOLLOW in openat.		 Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream upstream, 1.16.4, commit:a27ec46e8c0ab0ae162f2aa3142dccb6b79d9211 2026-01-12
GHSA-89xm-3m96-w3jg/system-helper-Only-remove-an-ongoing-pull-if-users-match.patch system-helper: Only remove an ongoing pull if users match
The code would always remove a pull from the hashtable, and then check if the
users match and abort if they don't. Either way, the pull gets dropped.

Fix this by only removing the pull if the dir and the user match.		 Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream upstream, 1.16.4, commit:a27ec46e8c0ab0ae162f2aa3142dccb6b79d9211 2026-02-07
1.16.5/run-Fix-checking-wrong-variable-in-runtime-fd-selection.patch run: Fix checking wrong variable in runtime fd selection
In flatpak_run_app(), the else-if branch that handles
FLATPAK_RUN_APP_DEPLOY_USR_ORIGINAL was checking custom_app_fd instead
of custom_runtime_fd. When custom_app_fd is APP_EMPTY (-3) and
custom_runtime_fd is USR_ORIGINAL (-2), the condition would not match
and fall through to g_assert_not_reached(), aborting the process.

This broke sub-sandbox spawning with --app-path="" (empty app), which
is used by steam-runtime-check-requirements to verify that Flatpak's
sub-sandbox mechanism works.

(cherry picked from commit 066babba75d355d077ea11091e5f65d3b0e0d818)		 Xiangzhe <xiangzhedev@gmail.com> yes debian upstream upstream, 1.16.5, commit:d19f44408000b53b6d61d3e60a3c65104dc5a8c6 2026-04-08
1.16.5/run-Mount-original-app-on-run-parent-app-when-using-app-p.patch run: Mount original app on /run/parent/app when using --app-path=""
Before addressing CVE-2026-34078, we would always mount the original app
*somewhere*, either /app (in the normal case) or /run/parent/app (when
using a custom or empty /app for the subsandbox). The empty-app case
regressed during the fix for CVE-2026-34078; bring back previous behaviour.

(cherry picked from commit fde4716f67b6620da57fd74481694eb58795d589)		 Simon McVittie <smcv@collabora.com> yes debian upstream upstream, 1.16.5, commit:ccd9c8a7fa8bee1b728e683c2d478f4408cd651c 2026-04-08
1.16.5/portal-update-max_fd-after-creating-the-instance-ID-pipe.patch portal: update max_fd after creating the instance ID pipe
fd_map_remap_fd() is called several times after this, and without this
change it can allocate a target fd that collides with instance_id_fd.

Only the write end of the pipe needs to be considered because that's
the one passed to the child.		 Alberto Garcia <berto@igalia.com> yes debian upstream upstream, 1.16.5, commit:2e2f4a430b784163614403b333ab3990c9354db3 2026-04-08
1.16.5/run-Fix-fd-tracking-in-flatpak_run_add_app_info_args.patch run: Fix fd tracking in flatpak_run_add_app_info_args
Calls to flatpak_bwrap_add_args_data_fd take ownership over the fd they
take. Closing them while they are still in the bwrap struct will abort
later when the bwrap struct gets freed and it tries to close the already
closed fd.

Fix this by using glnx_autofd and g_steal_fd.

[smcv: Resolve conflicts in 1.14.x]		 Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream backport, 1.16.5, commit:bd41305b98373d762cc02395d9fe7b9486da20d4 2026-04-08
1.16.5/utils-Improve-error-message-when-passing-an-FD-numer-whic.patch utils: Improve error message when passing an FD numer which is not a FD Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream upstream, 1.16.5, commit:e2ef538e8d70f8ddaf1adf201c3bb1578d0444f1 2026-04-08
1.16.5/run-Do-not-close-bind-ro-bind.patch run: Do not close --bind/--ro-bind Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream upstream, 1.16.5, commit:e654ebade0b9154830563c55c0a5f426b41fd46d 2026-04-08
1.16.5/run-Use-the-same-FD-validation-for-all-FD-options.patch run: Use the same FD validation for all FD options Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream upstream, 1.16.5, commit:c89a0c509ad315ccf5157e9faebb4e243bed165c 2026-04-08
1.16.5/run-Add-bind-fd-and-ro-bind-fd-binds-after-all-other-bind.patch run: Add bind-fd and ro-bind-fd binds after all other binds
This is only moving it a bit down because
flatpak_run_add_environment_args still adds a whole bunch of binds which
then can over-mount the user requested binds (bind-fd, ro-bind-fd).

[smcv: Resolve conflicts for 1.14.x]		 Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream backport, 1.16.5, commit:6118b415e4ed1e35852736c9a28585f4093bf246 2026-04-08
1.16.5/portal-use-g_array_index-to-read-from-expose_fds-expose_f.patch portal: use g_array_index() to read from expose_fds / expose_fds_ro
The data field of a GArray is a gchar* but we're storing integers
here, so use the proper method to ensure that we're getting the
element at the right offset and with the correct type.		 Alberto Garcia <berto@igalia.com> yes debian upstream upstream, 1.16.5, commit:8e71548ab56a97b88c7d34d68a6b04f6d430b2aa 2026-04-08
1.16.5/run-Fix-backport-mistake.patch run: Fix backport mistake
Not even sure how this happened. Whoops. It's time to get some sleep.		 Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream upstream, 1.16.5, commit:ac540672bb6598285fd333e3863335d27236762b 2026-04-09
1.16.5/tests-test-run-custom-Test-usr-path-usr-fd-app-path-app-f.patch tests/test-run-custom: Test --usr-path, --usr-fd, --app-path, --app-fd

[smcv: Add the new test to the old build system]		 Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream backport, 1.16.5, commit:ab8ca4d6a02900974c08694f54903b2616875bf0 2026-04-08
1.16.5/tests-test-run-custom-Test-bind-fd-and-ro-bind-fd.patch tests/test-run-custom: Test --bind-fd and --ro-bind-fd Sebastian Wick <sebastian.wick@redhat.com> yes debian upstream upstream, 1.16.5, commit:8ebffc2ad37fb5f2c03641506e8091aee53defd8 2026-04-08
1.16.6/run-Cope-with-an-empty-runtime.patch run: Cope with an empty runtime
When FlatpakDir runs extra-data helpers in apply_extra_data(),
if the helper is statically linked, it might not need a runtime at all.
For example the helper for openh264 falls into this category.

[smcv: Resolve conflicts with 1.14.x]

(cherry picked from commit aa1a54c9dae25fd13ebc936e06996f8db39f4aa5)		 Simon McVittie <smcv@collabora.com> yes upstream backport, 1.16.6, commit:b942152bde980cde51e933359e4ba3be527ae3ed 2026-04-09
1.16.6/dir-In-apply_extra_data-don-t-assume-there-is-always-a-ru.patch dir: In apply_extra_data(), don't assume there is always a runtime
org.freedesktop.Platform.openh264 is one example of an extension that
runs a statically-linked extra-data helper, with no runtime. Only open
the runtime if there is one.

(cherry picked from commit c14ad3722940706730a76997c6925f9998106f90)		 Simon McVittie <smcv@collabora.com> yes upstream upstream, 1.16.6, commit:a140dd16297df7dee73bfd6c99c278d7a3fa580c 2026-04-09
1.16.6/tests-Add-test-extra-data.sh-to-test-extra-data-installat.patch tests: Add test-extra-data.sh to test extra-data installation
[smcv: Remove OCI test because #3790 was only solved in 1.17.x,
only keep libostree test]

[smcv: Add to the old Autotools build system]

(cherry picked from commit e9e713fa0ddd0d1af4b8cdec6aa9124d471ed33e)		 Sebastian Wick <sebastian.wick@redhat.com> yes upstream backport, 1.16.6, commit:b942152bde980cde51e933359e4ba3be527ae3ed 2025-08-21
1.16.6/utils-Add-flatpak_set_cloexec.patch utils: Add flatpak_set_cloexec()
(cherry picked from commit 8a989c790d9121f53ada88fd001a3997b9e40632)		 Simon McVittie <smcv@collabora.com> yes debian upstream upstream, 1.16.6, commit:90625f0ef612364ded91a67327bdfe5b59e03b27 2026-04-10
1.16.6/run-context-Mark-fd-arguments-as-close-on-exec.patch run, context: Mark fd arguments as close-on-exec
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.

(cherry picked from commit 0902090726c2e51b1c6f22c64d708a4895a196e7)		 Simon McVittie <smcv@collabora.com> yes debian upstream upstream, 1.16.6, commit:a58978e40e7650c9c2cda716dd6d387fd6b5ea8e 2026-04-10
1.16.6/utils-Move-flatpak_get_path_for_fd-to-here.patch utils: Move flatpak_get_path_for_fd to here
This was originally in flatpak-portal, then was duplicated into
flatpak-run in commit ac62ebe3 "run: Use O_PATH fds for the runtime and
app deploy directories", and subsequently removed from the portal in
commit 3c500145 "portal: Use --bind-fd, --app-fd and --usr-fd options to
avoid races". Now we want to use it in the portal again.

(cherry picked from commit 15dc818874514ffbece4c080405353ed396b54a9)		 Simon McVittie <smcv@collabora.com> yes debian upstream upstream, 1.16.6, commit:ccaf86c854aeed47c2b346666b14e52d0f821b7f 2026-04-09
1.16.6/portal-Avoid-crash-if-sandbox-expose-ro-fd-is-out-of-rang.patch portal: Avoid crash if sandbox-expose-[ro-]fd is out of range
If the handle is not in the range `0 <= handle < fds_len`, but no
GError is set, we'd have crashed when we dereferenced error->message.
Instead, log an error and early-return, matching what we do for
app-fd, usr-fd and the array of inheritable fds.

(cherry picked from commit 4ef2421bd22d8fbf8f17cf9bf5da1dd95aedef8d)		 Simon McVittie <smcv@collabora.com> yes debian upstream upstream, 1.16.6, commit:5f73d530a25a119222b42b0680766faba3875777 2026-04-09
1.16.6/portal-Log-and-ignore-unusable-sandbox-expose-fds-instead.patch portal: Log and ignore unusable sandbox-expose fds instead of erroring

For the sandbox expose fds, a historical quirk of this code is that if
the checks in get_path_for_fd() failed, we would merely log at g_info()
level (usually only shown when debugging the portal), and otherwise
silently ignore the request to expose the fd in the sandbox.

With hindsight this was probably not the right thing to do, but apps
could well be relying on it now. For example, there are indications
that Epiphany might send a memfd from the main instance to a subsandbox,
which never actually worked, but will break that subsandbox process
if that's treated as a fatal error.

(cherry picked from commit 75ab6eebb857fd26172613b69e55f04830ad0d82)		 Simon McVittie <smcv@collabora.com> yes debian upstream upstream, 1.16.6, commit:4b6ee5e5c9ca33638b238c15e865864ed1437fb8 2026-04-09
1.16.6/portal-Reinstate-flatpak_get_path_for_fd-checks.patch portal: Reinstate flatpak_get_path_for_fd() checks
As with the previous commit, historically we would debug-log but
otherwise silently ignore attempts to expose a file in a sandboxed
subsandbox that doesn't have a suitable path.

For example, org.gnome.Epiphany (or possibly WebKitGTK) asks to expose
files from /app and /usr in the subsandbox. When we ignored those
requests (because /app and /usr have a different meaning on the host
system), the app worked as intended anyway, because the subsandbox has
access to the app's /app and the runtime's /usr whether they're
explicitly added or not, so it all worked out OK. However, treating
this as a fatal error (as it arguably should have been) broke
Epiphany's subsandboxes.

(cherry picked from commit 28634c7f52e57df7091007973d1bb5e1f87f1e9d)		 Simon McVittie <smcv@collabora.com> yes debian upstream backport, 1.16.6, commit:0ef48d4a4bd7479d35c2526104292e36d9ea1500 2026-04-09
1.16.6/libtest-Allow-adding-a-new-ref-to-an-existing-temporary-o.patch libtest: Allow adding a new ref to an existing temporary ostree repo
When we run `tests/test-run-custom.sh` as a build-time test,
we expect to already have the necessary runtimes, apps, etc. in
`${builddir}/tests/runtime-repo`. However, when running "as-installed"
tests, we're using a fresh temporary ostree repo for each test.
Merely having the repo exist is not enough: for some tests, and in
particular `tests/test-run-custom.sh`, it needs to have more than one
runtime available.

(cherry picked from commit 50dda82eb054695b3d3758d0a88ef68c8dd79dc4)		 Simon McVittie <smcv@collabora.com> yes upstream upstream, 1.16.6, commit:b7806fe7838e6a9114163fbcd20c11e7636d695f 2026-04-10
1.16.6/tests-Check-that-flatpak-run-fd-arguments-do-not-leak-to-.patch tests: Check that flatpak-run fd-arguments do not leak to the command

flatpak-run takes a number of arguments which are file descriptor
numbers. Those file descriptors are supposed to set something up in the
way the instance gets spawned, but should never make it to the wrapper
command.

(cherry picked from commit 136452768368613f3712c2f7cba79a7c3e7bee96)		 Sebastian Wick <sebastian.wick@redhat.com> no upstream, 1.16.6, commit:4491406f509707feb755982fdda24b2fd9234903 2026-04-10
1.16.6/app-context-Never-close-fds-0-1-or-2.patch app, context: Never close fds 0, 1 or 2
These fds are stdin, stdout and stderr respectively, and are expected
to remain open at all times (if they are not needed then they can point
to /dev/null, but they should always be open). If the user gives us
`--env-fd=2` or similar, we don't want to close fd 2 before exiting

(cherry picked from commit c4ab58cd2e66c4bcf193919ef9cbdce1dac042da)		 Simon McVittie <smcv@collabora.com> no upstream, 1.16.6, commit:7f5306876adc6f322f88c01801fd5aab2742c7b4 2026-04-10
1.16.6/app-context-Factor-out-flatpak_accept_fd_argument.patch app, context: Factor out flatpak_accept_fd_argument()
(cherry picked from commit d42037c5267ac7967ce285b9052b25fe7a968368)		 Simon McVittie <smcv@collabora.com> no upstream, 1.16.6, commit:817888730861a21bf930f7fbadc28155c2f3de39 2026-04-10
1.16.7/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-Silence-a-spurious-warning-when-installing-extra-data.patch dir: Silence a spurious warning when installing extra-data
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. Instead of
logging a (non-async-signal-safe!) warning, ignore the failure to seek,
like flatpak_bwrap_child_setup() already did.

Functionally equivalent to commit 333459c8 "dir: Use
flatpak_bwrap_child_setup_inherit_fds_cb() to apply extra-data" upstream,
but that function didn't exist yet in the 1.14.x branch.		 Simon McVittie <smcv@debian.org> not-needed upstream 2026-04-14

All known versions for source package 'flatpak'

Links