Tumbleweed – Review of the week 2026/22
Dear Tumbleweed users and hackers,
Week 22 seemed a bit less hectic than the previous one. AppArmor profiles are still being fixed left and right. We’re really sorry for all the trouble AppArmor 5.0 brought you. The number of reports on that topic is decreasing, which means the AppArmor maintainer has done a great job addressing the issues as they were reported. Let’s all give our appreciation to Christian for his dedication to the topic.
The release team managed to publish 5 snapshots (0521, 0523, 0524, 0525, and 0527) during this week, delivering the following changes:
- freerdp 3.26.0
- postfix 3.11.3
- Ruby 4.0.5
- Poppler 26.05.0
- libgit2 1.9.4
- hplip 3.26.4, See Martin’s mail regarding plugins and workarounds
- Qt 5.15.19
- Mozilla Firefox 151.0.1
- Linux kernel 7.0.10
- Agama 21 based installer to test: https://download.opensuse.org/tumbleweed/appliances/iso/agama-installer.x86_64-openSUSE.iso
The machinery is oiled, and updates are submitted frequently. Currently, we are preparing the implementation of these updates:
- Qt 6.11.1
- Mesa 26.1.1
- mariadb 11.8.7
- GNOME 50.2
- Rework of Python3 packaging (as a meta package instead of a provides of the default interpreter)
- gcc 16 as the system default compiler
Planet News Roundup
This is a roundup of articles from the openSUSE community listed on planet.opensuse.org.
The community blog aggregates a list of the featured highlights below from May 22 to 27.
Blogs this week cover security vulnerabilities discovered and patched in qSnapper’s privileged D-Bus service, a new GSoC 2026 contributor joining the openSUSE Project, nightly syslog-ng container images now available based on Alma Linux, a new plasmoid Scrolling Clock for KDE Plasma 6, a tip for previewing Markdown in the Kate editor, the April 2026 Krita report, the Mobile Linux Hackday in České Budějovice, Agama 21 and more.
Here is a summary and links for each post:
Whaleshark Opens Knopje
Sébas announces that on June 19 he will open the next edition of Knopje with a 1.5-hour melodic techno set.
Krita April 2026 Report
The KDE Blog covers the April 2026 Krita monthly report, which announces the release of Krita 5.3.2 and 6.0.2 with two months’ worth of bug fixes and improvements including text tool enhancements, performance fixes, and an Android crash fix. The post also highlights upcoming features in development and improves wide-gamut color conversion.
Introducing Shared Canned Responses
The Open Build Service Blog introduces shared canned responses in OBS, expanding a feature that previously only allowed users to create personal canned responses under their own profiles. The update allows canned responses to now be shared across projects and packages, streamlining collaboration and communication in request workflows.
How to Install exeLearning 4.0 on Your Computer
The KDE Blog explains how to install exeLearning 4.0, a free and open-source tool for creating interactive digital educational resources. The post outlines the three available editions.
Scrolling Clock Widget: Plasmoids for Plasma 6 (29)
The KDE Blog presents Scrolling Clock, the 29th widget in their Plasma 6 plasmoid series, which displays an animated clock cycling through all digits for a unique and eye-catching desktop look. Users who enjoy the widget are encouraged to support the developer through ratings, comments, or donations on the KDE Store.
Previewing Markdown Files in the Kate Editor
Victorhck shares a quick tip for enabling live Markdown preview inside the KDE Kate editor by activating the “Document Preview” plugin. The author notes that HTML preview does not work the same way and recommends using a browser for that format instead.
Nightly syslog-ng Containers Based on Alma Linux
Peter Czanik announces that nightly syslog-ng container images based on Alma Linux are now available on Docker Hub. Previously only Debian-based images were provided, but this new Alma Linux offering is built from the latest syslog-ng git snapshot packages.
Accepted into Google Summer of Code 2026 with openSUSE!
Mario Marín announces on his GSoC 2026 blog that he has been accepted into Google Summer of Code 2026 to contribute to the openSUSE project under two mentors. Over 12 weeks, he will work on improving the obs-status-service, including better SVG visualizations, a Gitea bot for Pull Request build information, and an AI-assisted stretch goal using Log Detective to analyze failed builds. He will be posting weekly progress updates on his blog.
qSnapper: Various Security Issues in Privileged D-Bus Service (CVE-2026-41045 through CVE-2026-41049)
The SUSE Security Team blog discloses five CVEs found during a security review of qSnapper, a GUI frontend for the Btrfs snapshot manager snapper. All issues were addressed through coordinated disclosure with the upstream author and fixes were shipped in the qSnapper 1.3.3 released on May 26.
MobileLinux Hackday #1 in České Budějovice
The SUSE Community Blog reports that the first Mobile Linux Hackday held in České Budějovice had a bigger turnout than the well-established Prague series with regard to attendance and synergy. The Prague series had already built a strong following over seven monthly events and the new venue signals growing momentum and geographic expansion for the Mobile Linux hackday movement in Czechia.
How to Use Desktop Icons NG (DING) on openSUSE 16 GNOME
The Geeko Blog provides a fix for the Desktop Icons NG (DING) GNOME extension failing to work on openSUSE 16. The post includes the relevant error message from /var/log/messages to help users identify the problem.
Long-Term Support Doesn’t Mean What You Think
The KDE Blog summarizes a post by KDE developer Nate Graham clarifying that LTS releases promise extended maintenance and security patches, not bug-free software or guaranteed personal support. The post draws a clear distinction between free community LTS distributions and commercially supported products and suggests that Flatpak apps can help bridge the software freshness gap on stable systems.
Haruna 1.8 Released – New Version of This KDE Media Player
The KDE Blog announces the release of Haruna 1.8, an open-source video player built on libmpv with YouTube integration. Haruna continues to be a solid alternative to Dragon Player and Kaffeine within the KDE ecosystem.
Linux Saloon 202 | Early Edition
CubicleNate recaps episode 202 of the Linux Saloon podcast, covering Colin’s use of his Surface Go running Cosmic Desktop, the release of Ubuntu 26.04 LTS, and updates on the Framework Computer Laptop 13 Pro.
Linux Saloon 203 | News Flight Night
CubicleNate recaps episode 203 of the Linux Saloon podcast, during which attendees discuss Collin’s experience with stillOS, the value of operating system rollback features, and notable news including HP sponsoring the Linux Vendor Firmware Service and KDE receiving a significant investment.
Xe Driver Support and Discover Improvements – This Week in Plasma
The KDE Blog translates Nate Graham’s weekly Plasma development summary. A standout community contribution added support for monitoring modern Intel Xe GPUs in System Monitor and its widgets. Discover also received several improvements including safer Flatpak data deletion sending files to the trash, a reorganized front page with the Editor’s Choice section moved higher, and case-insensitive search on the Updates page.
Agama 21 Released
Victorhck summarizes the release of Agama 21. The network configuration interface was redesigned with a new form supporting bond and bridge connections in addition to Ethernet and Wi-Fi. A new boot option inst.remote=0 allows disabling remote installer access for improved security in sensitive environments.
Tumbleweed – Review of the Weeks 2026/21
Victorhck and Dominique Leuenberger’s blog recap week 21 with six snapshots. The releases shipped notable updates including AppArmor 5.0.0, KDE Plasma 6.6.5, Linux kernel 7.0.6 through 7.0.9, GStreamer 1.28.3, Ruby 4.0.4, and PostgreSQL 18.4. Upcoming pipeline changes include Agama 21, GCC 16 as the default system compiler, and a rework of Python 3 packaging.
Workshop: Agentic AI and Total Automation at Linux Center València
The KDE Blog announces a hands-on workshop on agentic AI and automation taking place on June 6 at Slimbook’s Linux Center in Paterna, Valencia. The event features sessions on building intelligent agent systems using OpenClaw, privacy-respecting automation with Hermes, and a practical pair-programming workshop on Slimbook One mini PCs.
View more blogs or learn to publish your own on planet.opensuse.org.
Introducing Shared Canned Responses
Nightly syslog-ng containers based on Alma Linux
For many years, the syslog-ng project provided container images based on Debian. Most of our users run syslog-ng on RHEL & compatibles, and have asked for an RPM-based container. So, nightly containers based on Alma Linux are now also available.
A while ago, I prepared a small test project to run syslog-ng in an Alma Linux container: https://www.syslog-ng.com/community/b/blog/posts/experimental-syslog-ng-container-image-based-on-alma-linux However, that was only an experiment which I never updated. Fast forward to today: nightly syslog-ng containers based on the latest syslog-ng git snapshot package builds are now available on the Docker Hub!
Read more at https://www.syslog-ng.com/community/b/blog/posts/nightly-syslog-ng-containers-based-on-alma-linux

syslog-ng logo
Accepted into Google Summer of Code 2026 with openSUSE!
I am extremely excited to announce that I have been selected to participate in Google Summer of Code (GSoC) 2026! I will be contributing to the openSUSE Project.
The Project: Enhancing openSUSE Git Workflow
During the next 12 weeks, I will be working on improving the obs-status-service. Under the mentorship of Daniel García Moreno (dgarcia) and Doug, my main objectives include:
- Improving Visualizations: Extending the Go tool to generate better SVG images with new CSS styles and making them interactive with JavaScript.
- Gitea Bot Integration: Implementing a new bot for Gitea that provides useful build information directly inside Pull Requests.
- AI Integration (Stretch Goal): Exploring the use of AI through Log Detective to analyze and assist with PRs that fail to build.
Moving Forward
Given the dynamic nature of the GSoC program and software development itself, it’s very likely that these initial goals will adapt and change slightly as the weeks go by.
I’m ready to learn, face new challenges, and contribute to the open-source community. Stay tuned, as I will be posting my weekly progress right here!
qSnapper: Various Security Issues in Privileged D-Bus Service (CVE-2026-41045 through CVE-2026-41048)
Table of Contents
- 1) Introduction
- 2) Overview of the qSnapper D-Bus Service
-
3) Security Issues
- 3.1) Weak Polkit Authentication Check is Subject to Race Condition (CVE-2026-41045)
- 3.2) Path Traversal via
configNameParameter (CVE-2026-41046) - 3.3) Information Leak via “diff” Methods (CVE-2026-41047)
- 3.4) Caching of Authentication allows Authentication Bypass (CVE-2026-41048, CVE-2026-41049)
- 3.5) Defense-in-Depth Issues when Restoring Arbitrary Files
- 3.6) Other Issues
- 4) Upstream Bugfixes
- 5) Disclosure Process
- 6) Timeline
- 7) References
1) Introduction
qSnapper is a GUI frontend for the snapper utility for managing Btrfs filesystem snapshots. In April we received a review request for qSnapper, because it contains a privileged D-Bus service and Polkit policies.
Normally, Btrfs snapshots can only be managed with root privileges. qSnapper aims to provide more user-friendly and fine-grained access to snapshot management features, based on a privileged daemon which utilizes D-Bus and Polkit. Our review of the service uncovered various security issues, which led to a longer coordinated disclosure to allow upstream to develop bugfixes, which are part of upstream release 1.3.3.
The full details of the security issues will be covered in the sections below. The original review was performed on qSnapper release 1.1.3. Since bigger upstream changes appeared in the meantime this report is based on qSnapper release 1.3.2, however.
2) Overview of the qSnapper D-Bus Service
The qSnapper project contains a daemon named qsnapper-dbus-service, which
runs with full root privileges. The daemon provides the D-Bus interface
“com.presire.qsnapper.Operations” on the system bus; some of its methods
are provided to arbitrary users in the system without authentication, while the
majority of them is protected by Polkit authentication checks. The
implementation of the various D-Bus methods offered by the service is found in
snapshotoperations.cpp. All of the security issues
outlined below are located in this compilation unit.
3) Security Issues
3.1) Weak Polkit Authentication Check is Subject to Race Condition (CVE-2026-41045)
The SnapshotOperations::checkAuthorization()
function uses Polkit’s UnixProcess subject in an unsafe way to authenticate
clients. The code obtains the client’s PID from the active D-Bus connection,
which leads to a race condition. At the time the Polkit daemon (polkitd)
checks the provided PID, the process in question can already have been
replaced by another, privileged process. This is a well-known class of Polkit
authentication bypasses which was assigned CVE-2013-4288.
In effect this means that clients may be able to bypass all Polkit
authentication checks performed by qSnapper, although the attack is somewhat
complex and might need multiple attempts to succeed. There is nothing stopping
a local attacker from doing that, however. In combination with the configuration
path traversal in D-Bus methods like
WriteSnapperConfig() described below, this can be used to achieve a full
local root exploit.
To fix this, we suggested to use Polkit’s SystemBusName subject instead. With
this subject, the D-Bus daemon obtains the client’s UID in a race-free fashion
from the UNIX domain socket the client used to connect, and polkitd cannot be
fooled by recycled PIDs.
3.2) Path Traversal via configName Parameter (CVE-2026-41046)
All the D-Bus methods accepting a configName parameter
(that is nearly all of them) suffer from a path traversal vulnerability. This
string parameter is directly passed to snapper::Snapper(), which is part of
the libsnapper API, without checking its safety. libsnapper expects a basename
here to look up a configuration file in /etc/snapper/configs. In the context
of qSnapper this string can contain additional path components like
../../path/to/crafted.cfg. This allows clients to use arbitrary
configuration files as input to libsnapper.
When looking at the writeSnapperConfig() D-Bus method, which requires admin authentication, this path traversal allows to write largely attacker-controlled data to arbitrary locations. Combined with the Polkit authentication bypass described earlier in section 3.1, this would allow for a full local root exploit.
In case of other D-Bus methods which use the “list-snapshots” Polkit action, the path traversal is also accessible to locally logged-in users without any authentication. Luckily the libsnapper configuration file format offers no features that lead to a trivial local root exploit in this context. The impact of the vulnerability can be any of the following, however:
- local Denial-of-Service (DoS): by pointing libsnapper to a special file like
/dev/zero, the daemon will consume the maximum amount of memory and be killed by the kernel. By pointing libsnapper to a named FIFO special file, the daemon will block indefinitely. - information leak from parsing of private files: by pointing libsnapper to a
private file like
/etc/shadow, libsnapper will parse the sensitive data from the file as configuration data. If any logging features are active and the logs can be accessed by unprivileged users, then private data from such a file might leak into the unprivileged context. We are not aware of such an information leak in default installations, however. - by providing crafted configuration data further attacks can be carried out:
-
SUBVOLUMEcan be pointed to arbitrary mounts in the system. Luckily libsnapper is conservative in its file operations here, and quite strictly verifies the validity of this path; it verifies if it is really a mount point and is backed by the expected block device and file system etc. -
ALLOW_USERSandALLOW_GROUPScan be set to arbitrary users and groups, allowing them officially to control the Snapper configuration. - The
SYNC_ACLsetting causes libsnapper to apply ACL entries to the.snapshotsdirectory of the volume path, granting the users and groups fromALLOW_USERSandALLOW_GROUPSto access the snapshot data. Thus this is a major local information leak.
-
libsnapper is using different backends depending on the file system type. Different code is used for each backend, which means that the exploitability of some aspects of the vulnerability depends on which backend is used. On openSUSE only the Btrfs and LVM thin volume backends are compiled-in by default, which only offer little additional attack surface.
To fix the issue, we suggested to upstream to verify the configName
parameter in all cases and reject it if any / or .. components are
found in it.
3.3) Information Leak via “diff” Methods (CVE-2026-41047)
The Polkit action “list-snapshots” is allowed for locally logged-in users without authentication, and is used by multiple qSnapper D-Bus methods which are likely considered “read-only” operations not harmful to the system. In version 1.1.3 of qSnapper the following methods are relying on this Polkit action:
ListSnapshots()GetFileChanges()GetFileDiffAndDetails()
In version 1.3.2 of qSnapper these additional methods are using the action:
GetFileChangesBetween()GetFileDiffBetween()
These methods allow to obtain information about metadata changes of arbitrary
files between snapshots or between snapshots and the live filesystem. The
newer GetFileDiffBetween() method even offers full file content diff output.
These are major local information leaks, since unprivileged users can get a
diff e.g. of the /etc/shadow file between different system states, or
changes from root’s home directory which could leak sensitive data like
passwords or private keys.
To fix this, we suggested to upstream that all methods providing non-public
information get restricted by auth_admin Polkit checks. Alternatively, a check
could be implemented whether the files to be diffed are normally accessible to
the caller by using checks similar to the access() system call; such an
approach would likely be rather complex and error-prone, however.
3.4) Caching of Authentication allows Authentication Bypass (CVE-2026-41048, CVE-2026-41049)
In version 1.2.1 of qSnapper an m_authenticated flag was introduced to the
daemon’s code, which caches authentication once a client has passed certain Polkit
action authentication checks. This cached authentication is shared between the
methods DeleteSnapshot(),
RestoreFiles() and
RestoreFilesDirect(). There are two issues
with this approach:
-
DeleteSnapshot()uses the “delete-snapshot” action, while the other methods use the “rollback-snapshot” action. If a caller can authenticate for “delete-snapshot” then it is also implicitly authenticated for “rollback-snapshot” and vice versa. This is not how Polkit is intended to be used. If a system administrator decides to relax the authentication requirement for “delete-snapshot”, then this automatically implies the “rollback-snapshot” action now, which are two very different impacts to the system. We assigned CVE-2026-41048 for this aspect of the issue. - The implementation of the caching logic assumes that a single interactive
client is talking to the daemon. In fact, arbitrary users can invoke
these methods. If a legitimate client is authenticated for one of the affected
actions once, then arbitrary other users like
nobodyare now also considered authenticated and Polkit will not be invoked anymore. This authentication bypass allows for a full local root exploit in the context of theRestoreFiles()methods, as outlined below in section 3.6. We assigned CVE-2026-41049 for this aspect of the issue.
We suggested to upstream to drop this form of authentication caching, or alternatively implement an authentication cache tied to each user and each Polkit action in question to avoid the issues.
3.5) Defense-in-Depth Issues when Restoring Arbitrary Files
This section discusses Defense-in-Depth issues which remain once all the
more tangible issues discussed above are fixed. The
restoreFiles() D-Bus method accepts arbitrary
filePaths as parameter to be restored from a version found in a snapshot.
Clients need to authenticate as an administrator to do this, so there is no
direct attack surface. Let’s consider the path /var/lib/colord/mapping.db to
be restored, however:
# On openSUSE Tumbleweed this directory is owned and writable by `colord`
$ ls -lh /var/lib/colord
drwxr-xr-x 3 colord colord 4.0K Mar 6 2024 .
At the time the qSnapper service performs the
chown() system call, the colord service user can
stage a symlink attack in the colord directory and cause arbitrary files in
the system to receive colord ownership, allowing a colord to root
exploit. A similar issue affects the copyRegularFile()
function, where a file on the live file system is
newly created.
This issue is hard to fix, given the many different file system situations
that the restore operation can end up in. The basic algorithm to address the
problem would need to use low-level system calls like openat(), fchown()
and fstatat() to safely traverse file system paths and inspect any symbolic
links on the way. Given the complexity of the bugfix and limited impact, we
agreed with the upstream author that this fix does not need to be prepared
during the coordinated disclosure period but can be developed in the open
afterwards.
Given the amount of front-line security issues already found in qSnapper in the course of this review, we refrained from assigning a dedicated CVE for these Defense-in-Depth issues in this case.
3.6) Other Issues
This section covers a number of other issues that are not fully-fledged security issues, but still represent weaknesses or possible hardenings for the qSnapper implementation.
- the D-Bus method
RestoreFiles()implements complex file operations to rollback changes of a file path to the state found in a snapshot. These file operations allow authenticated clients to achieve nearly arbitrary file operations:- recursive deletion of arbitrary paths
- copy of arbitrary files to arbitrary locations
- change of ownership of files to arbitrary users
- change of the file mode to arbitrary values
This is because the method is not verifying whether the claimed file exists in the snapshot in the first place and whether the
filePathscontain any../directory components to escape the snapshot directory. While this method is protected by Polkit’sauth_adminsetting, any D-Bus method should be written conservatively and in such a way that the intended purpose of the method cannot be bypassed. The very similar methodRestoreFilesDirect()has the same issues and also contains a lot of duplicate code which should be merged with the other method’s code. - the Quit() method can be called by anyone in the system without authentication. This is kind of a local DoS against an active qSnapper daemon in use by other users in the system.
- the logfile created in
/var/log/qSnapperwill be world-readable, which could leak sensitive information. For hardening purposes it could be made private toroot.
4) Upstream Bugfixes
The upstream author closely followed our suggestions to fix the security issues described in this report. Version 1.3.3 of qSnapper contains the following bugfixes:
-
commit a6caf538 addresses the following
issues:
- the Polkit
UnixProcesssubject is replaced by theSystemBusNamesubject to avoid the race condition during authentication (issue 3.1). - the
configNameparameter in all D-Bus methods is now carefully verified and rejected if it allows path traversal (issue 3.2). - the authentication caching is removed (issue 3.4).
- the
RestoreFilesmethods reject path traversal attempts (see section 3.6).
- the Polkit
-
commit f375b74c addresses the
following issues:
- a new
view-diffPolkit action is introduced to generate file diffs which requiresauth_adminauthentication to prevent information leaks (issue 3.3). - the unauthenticated
QuitD-Bus method was dropped (see section 3.6). - log files are now created without world-readable bit (see section 3.6).
- a new
The more complex defense-in-depth issues outlined in section 3.5 will be addressed by upstream in the open at a later time.
5) Disclosure Process
Once we established contact with the upstream author, we had a very constructive discussion of the coordinated disclosure process. Upstream quickly acknowledged the issues, opted for coordinated disclosure and communicated a time schedule when bugfixes were expected to be available for review and when a bugfix release of qSnapper would be published. When we agreed on the final bugfixes in the middle of May, we agreed on choosing an earlier publication date than originally intended.
We want to thank the upstream author for handling this report in a very professional fashion and for greatly improving the security and robustness of qSnapper.
6) Timeline
| 2026-04-09 | Lacking any other point of contact, we created a public GitHub issue asking for a security contact. |
| 2026-04-13 | The upstream developer responded in the issue providing an email address for us to reach out to. |
| 2026-04-13 | We reached out to the developer privately by email providing a detailed report and offering coordinated disclosure. |
| 2026-04-14 | Due to issues with mail servers our email did not reach the upstream developer. Upstream offered us another email address to try. |
| 2026-04-15 | We received a reply from the upstream developer confirming the issues and requesting coordinated disclosure. Upstream accepted our offer to assign CVEs for the issues. A preliminary disclosure date of 2026-07-07 was established. |
| 2026-04-17 | We assigned CVEs and shared them with upstream. |
| 2026-05-08 | We received a tarball containing the current release candidate code of qSnapper. |
| 2026-05-11 | We asked the upstream author if individual bugfixes could be supplied instead. |
| 2026-05-12 | We received the individual patches we asked for. |
| 2026-05-12 | We provided feedback on the current state of the patches. Apart from minor details and hardening suggestions the patches were already in good shape. |
| 2026-05-14 | We received updated patches for review and found no further issues. Given the good progress on the bugfixes, an earlier coordinated release date of 2026-05-26 was agreed upon. |
| 2026-05-26 | As planned, upstream released qSnapper 1.3.3 containing the bugfixes. |
| 2026-05-26 | Publication of this report. |
7) References
MobileLinux Hackday #1 in České Budějovice Outperforms Prague!
Breaking New Ground: Mobile Linux Hackday #1 in České Budějovice Outperforms Prague! If you’ve been following the Mobile Linux journey in Czechia, you know we’ve built a fantastic routine in Prague. We have a really successful series behind us consisting of 7 monthly hackdays, always hosted at the Prague SUSE office. But when the stars […]
The post MobileLinux Hackday #1 in České Budějovice Outperforms Prague! appeared first on SUSE Communities.
Linux Saloon 203 | News Flight Night
