On Wed, 08 Apr 2026 at 09:27:42 +0100, Simon McVittie wrote:
xdg-desktop-portal's Trash portal allows sandboxed apps to ask for a
file or directory to be moved to the trash. Similar to CVE-2026-34078 in
Flatpak, a malicious or compromised Flatpak app could ask the portal to
trash a file that it owns, then replace that file with a symlink in an
attempt to cause the portal to trash the target of the symlink on the
host system.
...
For trixie, I think the easiest way to fix the vulnerability will be to
backport 1.20.4 from testing/unstable, reverting any of the packaging
changes in 1.20.3+ds-2 and 1.20.3+ds-3 that are felt to be inappropriate
for a stable update.
Filtered debdiff and source package using that approach:
https://people.debian.org/~smcv/temp/2026/GHSA-rqr9-jwwf-wxgj/
I filtered out subprojects/libglnx/ from the debdiff. It's quite large,
but I've confirmed that it's identical to the subprojects/libglnx/ in
the flatpak trixie upload that I proposed for CVE-2026-34078 - I hope
that's an OK approach to dealing with this unstable "copylib".
As usual I also filtered out regenerated .po files for translations.
Functionally equivalent test-build with a slightly lower version number:
https://people.debian.org/~smcv/temp/2026/GHSA-rqr9-jwwf-wxgj/testbuild/
Briefly tested on a trixie GNOME VM. I didn't attempt to exercise the
trash portal, only the file saving dialog. I did try the trash portal
(via an org.gnome.Nautilus nightly build) before I uploaded to unstable,
and it does work.
Does the security team want to do a DSA for this, or should I retarget
as a stable update?
For bookworm, it'll have to be a backport of individual changes. I
suggest prioritizing trixie > bookworm and flatpak > xdg-desktop-portal.
I haven't attempted to do this backport yet.
experimental will remain vulnerable until 1.21.1 is released
I haven't uploaded this yet either, chasing Flatpak regressions took up
basically all the time I had available this week.
Thanks,
smcv
