If both org.gnome.Sdk and org.gnome.Sdk.Docs are manually installed,
they have no dependents, and only org.gnome.Sdk.Docs is left pinned,
`flatpak uninstall --unused` should remove org.gnome.Sdk and all its
unused dependecies while keeping org.gnome.Sdk.Docs installed.
However, Flatpak still removes org.gnome.Sdk.Docs if org.gnome.Sdk's
metadata contains:
[Extension org.gnome.Sdk.Docs]
autodelete = true
This patch ensures that pinned packages will override the autodelete
metadata directive. In this case, org.gnome.Sdk.Docs is spared from
uninstallation.
Thanks to Sebastian Wick (@swick) for reviewing the patch, and
suggesting variable initialization outside the loop that calls
flatpak_dir_ref_is_pinned():
https://github.com/flatpak/flatpak/pull/6859#pullrequestreview-5586932172
The fallback-X11 permission test overwrites res_perms twice. Its autoptr
cleanup only frees the last hash table, leaking the first two results.
Give each test case its own res_perms so cleanup runs before the next
case starts.
LeakSanitizer reported 1049 leaked bytes in 30 allocations on Ubuntu
24.04. The test passes with leak detection enabled after this change.
gtk-doc cross-references to GLib/GIO types have been broken since GLib
migrated to gi-docgen and stopped shipping devhelp index files.
Replace gtk-doc with gi-docgen, which generates docs from GIR data and
resolves cross-references via a URL map. Rename the build option from
'gtkdoc' to 'api_docs' and update CI workflows accordingly.
Fix XML parse error caused by unescaped <path> in
flatpak_transaction_add_sideload_image_collection doc comment.
Add missing public API symbols to flatpak-sections.txt and remove
private flatpak_related_ref_new. Add ignore lists for private headers
and source files to prevent gtkdoc-mkdb from scanning them.
GIO only sets standard::symlink-target on the GFileInfo when the queried
path actually is a symlink. Several helpers blindly queried "active" /
"current" with AT_SYMLINK_NOFOLLOW and then called
g_file_info_get_symlink_target(), which emits
GLib-GIO-CRITICAL: GFileInfo created without standard::symlink-target
whenever the entry exists but is not a symlink. This is reproducible
with `flatpak --system remote-ls --updates`, which probes every
deployed ref.
Check g_file_info_get_is_symlink() before reading the target, keeping
the existing "not deployed" result while avoiding the spurious
criticals.
Fixes: https://github.com/flatpak/flatpak/issues/6766
Fixes: https://github.com/flatpak/flatpak/issues/6413
Curl's partial-file, empty-reply and send/receive errors were mapped to
G_IO_ERROR_FAILED, so the existing transient-error retry policy skipped
connection losses. Map them to partial-input and connection-closed errors
without changing the retry limit or retrying streams already written to.
Test recovery from empty and truncated replies, including compressed
cache output, and verify no partial contents survive the retry.
When ~/.local/share/fonts existed, Flatpak only bind-mounted that
directory into the sandbox and ignored ~/.fonts. Users who still have
fonts under the legacy path (common after desktop environments changed
the default install location) therefore lost those fonts in Flatpak
apps.
Mount both directories when present: keep XDG fonts at
/run/host/user-fonts, and expose ~/.fonts at /run/host/user-fonts-legacy
with a matching fontconfig remap. If only ~/.fonts exists, keep the
historical /run/host/user-fonts destination.
Closes: #6869
In commit 21f413f1, flatpak_instance_new was changed to require the pid
file to be written in order to succeed. This causes problems when
calling Spawn with NOTIFY_START, however, because portal expects to be
able to call flatpak_instance_new once the instance ID is retrieved. As
per the comments in the code that writes said instance ID, the idea was
that the instance would be *usable* at the point where the write takes
place (hence it being positioned *after* saving `bwrapinfo.json`), so it
makes sense to now move the write to *after* after the pid file is
written.
Since the pid file write and the instance ID write now go hand-in-hand,
both actions now take place in a separate function, so the logic can be
in one place. Additionally, the write itself is migrated to
`glnx_loop_write`, to shorten the code.
Assisted-by: DeepSeek-V4.1-Flash
Flatpak's progress percentage is a heuristic that includes metadata
discovery and write phases. Using it as a time base can produce
misleading remaining times or reach 00:00 while downloads are still
active.
Track the computed transfer total in FlatpakProgress. Use the remaining
bytes and measured transfer rate to calculate the CLI ETA.
COSMIC applets use these keys, and they are harmless.
X-CosmicApplet marks them as an applet for the settings app and the
panel.
X-CosmicHoverPopup marks an applet that it wants a popup on hover if a
popup is open already in another applet.
X-CosmicOverflowPriority marks the priority of an applet for overflow
behavior in the panel.
X-CosmicOverflowMinSize marks the min size of the shrinkable applet in
applet size units.
X-CosmicShrinkable marks a window as having padding that can be
shrinkable in the panel so that it takes up less space.
gpgme_ctx_t was not wrapped with g_auto(), so gpgme_new() allocated
contexts were never released by gpgme_release() on any return path.
All other GPGME types in the same function already use g_auto().
flatpak_allocate_tmpdir created child repo directories (repo- and
child-oci-) with mode 0777, allowing any local user to modify their
contents between the client pull and the system helper deploy.
Use 0755 instead, which prevents other users from writing while
still allowing the revokefs-fuse frontend to read the backing store
directly. The frontend runs as the calling user while the writer
backend runs as the flatpak system user, so the frontend needs
read access to directories created by the backend. Mode 0700 would
break this.
Resolves: CVE-2026-97026
Resolves: https://github.com/flatpak/flatpak/security/advisories/GHSA-r9w3-qx54-qvc8
The .token file was written into the child-oci directory so the
system helper could read it back for remote registry verification.
However, the system helper only ever opens the child-oci registry
as a local source (dfd != -1), and every code path that uses
self->token for HTTP requests is gated behind dfd == -1. The token
was never reachable since it was introduced in commit 5d8fd2d1b.
Persisting credentials to a world-traversable directory in /var/tmp
is a security risk on multi-user systems. Remove the file write
from set_token and the file read from ensure_local. The token
remains available in memory for the client process that actually
needs it for remote access.
Resolves: CVE-2026-97025
Resolves: https://github.com/flatpak/flatpak/security/advisories/GHSA-7rvf-rqr3-43j4
The runtime files directory was opened with open() using O_PATH but
without symlink protection, unlike the app files path which used
O_NOFOLLOW. Since "files" is validated as a non-symlink during deploy,
this is not exploitable through normal install flow. However, the open
should still use safe fd-relative operations as defense-in-depth.
Use flatpak_deploy_get_files_fd which validates the path with
glnx_chaseat(GLNX_CHASE_RESOLVE_NO_SYMLINKS), rejecting any symlink
at the directory boundary.
Hardening related to CVE-2026-97023, CVE-2026-97024
Helps: https://github.com/flatpak/flatpak/security/advisories/GHSA-5p67-xh8x-rq54
Helps: https://github.com/flatpak/flatpak/security/advisories/GHSA-8xgq-v545-vgvf
dir_is_locked() used g_file_resolve_relative_path to construct the
path to files/.ref, then open() without O_NOFOLLOW. Since "files" is
validated as a non-symlink during deploy and ".ref" is atomically
created as a regular file, this is not exploitable through normal
install flow. However, the function should still use safe fd-relative
operations as defense-in-depth.
Rename dir_is_locked to deploy_dir_is_locked to reflect that it
operates specifically on deploy directories, not arbitrary ones.
Hardening related to CVE-2026-97023, CVE-2026-97024
Helps: https://github.com/flatpak/flatpak/security/advisories/GHSA-5p67-xh8x-rq54
Helps: https://github.com/flatpak/flatpak/security/advisories/GHSA-8xgq-v545-vgvf
The runtime deploy path used GFile operations to manipulate files
inside files/etc (passwd, group, machine-id, resolv.conf). While
the "files" directory is validated with glnx_chaseat using
GLNX_CHASE_RESOLVE_NO_SYMLINKS, "etc" inside it is not checked.
A malicious runtime with files/etc as a symlink causes the GFile
operations (g_file_delete, g_file_replace_contents,
g_file_make_symbolic_link) to follow it and modify files at the
symlink target. On system installs (running as root), this modifies
arbitrary files — e.g. replacing /etc/resolv.conf.
This commit uses fd-based operations to prevent to prevent the symlink
attack.
Resolves: CVE-2026-97024
Resolves: https://github.com/flatpak/flatpak/security/advisories/GHSA-8xgq-v545-vgvf
The export directory cleanup during deploy used flatpak_rm_rf which
wraps glnx_shutil_rm_rf_at(AT_FDCWD, path). The kernel resolves
intermediate symlinks in the path, so a malicious ostree commit with
"export" as a symlink causes flatpak_rm_rf(export/bin) to delete files
at the symlink target. On system installs (running as root), this is
arbitrary file deletion.
This commit uses fd-based operations to prevent to prevent the symlink
attack.
Resolves: CVE-2026-97023
Resolves: https://github.com/flatpak/flatpak/security/advisories/GHSA-5p67-xh8x-rq54
Add deploy_open_fd, flatpak_deploy_get_files_fd,
flatpak_deploy_get_export_fd, and flatpak_deploy_get_metadata_fd which
open files within a deploy directory using fd-relative operations with
symlink protection.
deploy_open_fd uses a two-step resolution:
GLNX_CHASE_RESOLVE_NO_SYMLINKS at the directory boundary (files/,
export/) to reject symlinks, then GLNX_CHASE_RESOLVE_BENEATH within the
directory to safely resolve symlinks relative to the directory root.
These will be used by subsequent commits to close TOCTOU gaps where
GFile path operations were used after fd-based validation.
Prerequsite for fixing CVE-2026-97023, CVE-2026-97024
Helps: https://github.com/flatpak/flatpak/security/advisories/GHSA-5p67-xh8x-rq54
Helps: https://github.com/flatpak/flatpak/security/advisories/GHSA-8xgq-v545-vgvf
This prevents sandboxed processes from being able to kill processes
outside the sandbox with `kill (0, SIGNAL)`. The only process they can
kill like this will be the `bwrap` supervisor, which just terminates
the sandbox when killed.
Resolves: CVE-2026-97029
Resolves: https://github.com/flatpak/flatpak/security/advisories/GHSA-f3p8-vr7v-gxf2
Signed-off-by: Simon McVittie <smcv@collabora.com>
The document portal is mounted at /run/flatpak/doc inside the sandbox,
but forwarded arguments used its host mount path. With a nonstandard
host runtime directory, that path is inaccessible to the application.
Keep the host path local to mount setup and return the sandbox destination
to argument forwarding. Preserve NULL when the portal is unavailable.
Add real-portal regression tests for user and isolated system installs.
Check file read/write, escaped URIs, directories and passthrough controls.
Skip the directory subtest on portal interfaces older than version 4.
Applications using libflatpak currently have to duplicate the CLI's
private cleanup logic to offer the equivalent of uninstall --delete-data.
Add a standalone API that removes ~/.var/app data and resets permission
store entries without requiring the app to be installed. Keep it separate
from transactions so callers can retry partial failures or reset data for
an installed app.
Validate app IDs before constructing paths, propagate cancellation and
permission table errors, and document partial failure behavior.
Permission table discovery reads the on-disk database directory and does
not use the D-Bus permission store proxy. Remove the unused argument and
update callers.
Return the permission reset result directly after app data removal. This
keeps the success and error paths equivalent while removing an unnecessary
conditional.
Libflatpak needs to reuse user-data deletion and permission reset logic
that was previously private to the command-line builtins. This will let
software stores offer the equivalent of uninstall --delete-data.
Move each concern into a separate common module without changing behavior
so a public API can be added in a later commit. Name the user-data module
and its helper consistently here, and keep them distinct from the
existing appdata metadata code.
flatpak update --commit and flatpak remote-info read the download size
from xa.download-size in the commit metadata, which only covers the
ostree file objects and not extra-data. The summary cache path used by
a regular flatpak update does add extra-data sizes, so the two differed:
extra-data apps like com.jetbrains.Rider showed 1.3 MB instead of 1.6 GB.
Add flatpak_commit_add_extra_data_sizes() to sum the extra-data sizes
from a commit variant, and use it in resolve_op_from_commit() and
remote-info so they match the summary path. The existing
flatpak_repo_collect_extra_data_sizes() is changed to reuse it.
Fixes: https://github.com/flatpak/flatpak/issues/5947
The variables d, m, y are declared as 'int', but the format string
used '%u' which expects 'unsigned int *'. Change to '%d' to match
the actual argument type.
Detected by GCC -Wformat when building with warning_level=3.
BundleData retains explicit GPG key data with g_bytes_ref(), but its
cleanup treats the data as a GObject. This crashes transaction cleanup
when a bundle is installed with explicit key bytes.
Use g_clear_pointer() with g_bytes_unref() to release the retained data.
flatpak_context_to_args() built the D-Bus name options from
flatpak_policy_to_string(). That function gives the values used in the
[Session Bus Policy] and [System Bus Policy] metadata groups. Two of
them, "none" and "see", are not command-line options. A context that
contained such a policy gave --none-name= and --system-none-name=.
flatpak-run(1) writes these arguments to the [Instance] extra-args of
/.flatpak-info. flatpak-portal gives them back to flatpak(1) when a
sandboxed app calls flatpak-spawn(1). flatpak(1) then rejected the whole
command line with "Unknown option --none-name=...", so --no-talk-name
and --system-no-talk-name broke flatpak-spawn(1).
Map each policy to the option that sets it: --no-talk-name for
FLATPAK_POLICY_NONE, --talk-name for FLATPAK_POLICY_TALK, and --own-name
for FLATPAK_POLICY_OWN. FLATPAK_POLICY_SEE has no command-line option,
so emit nothing for it. It cannot occur here: the only caller serializes
a context that comes from the command line.
While I'm changing the translatable string anyway, this also
incorporates a suggestion from #6753 to quote the invalid character, so
that output is clearer in the case where the invalid character is
whitespace.
Thanks: Christian Stadelmann
Signed-off-by: Simon McVittie <smcv@collabora.com>
Until now we have been using `%c` to show invalid characters, but in
general that will corrupt our output if the input is non-ASCII,
because the individual bytes of a UTF-8 string are not valid UTF-8 alone.
Signed-off-by: Simon McVittie <smcv@collabora.com>
It is not a meson project, but we can use the patch_directory key to
overlay a meson.build file over the git checkout. It uses
meson.override_find_program so that in flatpak, a call to
find_program('variant-schema-compiler') will find the program.
Reject summaries, subsummaries, and summary indexes that are not in
GVariant normal form before passing them to the generated variant
accessor framework, which performs direct pointer arithmetic without
structural validation.
We require glib 2.46, so we can't rely on g_hash_table_new_similar.
Fixes: 17cb1135 ("context: Keep fallback-x11 separate from x11 conditionals")
Closes: #6775
On architectures like i386, socket operations were historically
multiplexed through the socketcall syscall. The seccomp socket family
filter only applied to the direct socket syscall, so a binary using
socketcall could bypass it entirely.
Switch from seccomp_rule_add_exact to seccomp_rule_add, which lets
libseccomp also block socketcall. Since libseccomp cannot inspect
socketcall arguments (they are behind a userspace pointer), this
blocks all of socketcall, forcing userspace to use the direct socket
syscalls that have been available on i386 since Linux 4.3.
apply_extra_data() used GFile path-based operations that follow
symlinks: --ro-bind/--bind with resolved paths, chmod on the extra
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.
Helps: https://github.com/flatpak/flatpak/security/advisories/GHSA-fqx6-vh4p-42cg
[smcv: Use glnx_fd_reopen() to reopen O_PATH fd as readable]
Co-authored-by: Simon McVittie <smcv@collabora.com>
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]
Co-authored-by: Simon McVittie <smcv@collabora.com>
Resolves: https://github.com/flatpak/flatpak/security/advisories/GHSA-fqx6-vh4p-42cg
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.
Helps: https://github.com/flatpak/flatpak/security/advisories/GHSA-fqx6-vh4p-42cg
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.
Resolves: https://github.com/flatpak/flatpak/security/advisories/GHSA-q4gr-vc25-57m5
Matthew White