/var/lib/selinux were not covered by snapshots and
could not be rolled back./etc/selinux, which allows the SELinux
policy to be fully covered by snapshots.SELinux has been the Mandatory Access Control mechanism on openSUSE distributions such as MicroOS and Leap Micro since 2022, and most recently openSUSE Tumbleweed switched the default MAC to SELinux in February 2025.
The files installed on a system by the SELinux policy package have traditionally
been split between /var/lib/selinux, /usr/share/selinux and /etc/selinux
on most Linux distributions, including openSUSE. The separation across these
directory trees conflicts with the modern Linux concept of atomic/image-based
updates, which in openSUSE has been implemented as a snapshot and rollback
mechanism based on BTRFS. This mechanism only snapshots
the /usr and /etc trees, intended for packages and configuration
respectively. Other directory trees are meant for user files or, as in the case
of /var, for mutable system state files, and as such are not covered by
snapshots.
Installing SELinux policy files under /var violates this requirement, and can
result in inconsistency in case of rollbacks: policy files under /etc and
/usr would be rolled back, but files under /var would not be touched.
To resolve this issue, we have migrated SELinux policy files under /var to
/etc. The migration is automatic and does not require any user interaction in
standard setups. This blog post explains the issue in more detail, documents the
steps taken to migrate the files, and describes known issues and how to resolve
them.
Atomic/image-based update systems have become increasingly relevant in recent years. In openSUSE, this concept has been realised as both fully transactional systems (e.g. MicroOS, Leap Micro) and as regular distributions with automatic snapshots and the possibility to rollback broken updates (e.g. Tumbleweed). In both of these cases, the traditional SELinux policy packaging causes some issues.
In case of a rollback of an update containing a change to the SELinux policy, if
there is a mismatch between what was rolled back (/usr/share/selinux and
/etc/selinux) and what could not (/var/lib/selinux), this could lead to
policy build issues, external module installation issues, and could bring the
SELinux policy and the whole system into a state which is difficult to recover
from automatically.
In practice, these issues are very rare, since they require a particular set of circumstances:
As a matter of policy, these kinds of backwards-incompatible policy updates are never performed on distributions such as Leap Micro (except possibly during migration between major distribution versions), thus preventing the issue. On Tumbleweed and MicroOS these updates can happen, albeit rarely, and when combined with the probability of a rollback and the further triggering actions they become exceedingly rare.
Manually reinstalling the SELinux policy package (and any affected external policy modules) is sufficient to fix the issues, but this is still an undesirable characteristic of this legacy packaging structure.
To permanently address the aforementioned issues, we decided to migrate SELinux
policy files under /var/lib/selinux to /etc/selinux. As mentioned, this
location was already used for other SELinux policy files, and is covered by the
snapshot and rollback mechanism.
The migration was tracked in bsc#1221342. After a long period of automated and manual testing over the past few months, the migration will be performed in an upcoming Tumbleweed snapshot.
Some of the challenges encountered during the implementation of the migration process were:
/var/lib/selinux once no snapshot is using the old path/etc/selinux and last pre-migration state in /var/lib/selinuxThe migration process is automatic and in most situations will not be visible
to the user, except for information printed in the zypper output during the
update. The process takes care not only of the migration of policy
modules provided by the system SELinux policy (e.g. selinux-policy-targeted),
but also of custom modules installed by other packages (see below) and local
modifications to SELinux configuration (booleans, users, ports, …).
To allow the migration to be fully reverted, the process temporarily preserves
the “old” /var/lib/selinux/ directory tree even after the migration. Once no
snapshots are found which still refer to /var/lib/selinux, the whole directory
tree is safely deleted.
Most of the steps are done during package update, except for the final cleanup step which is performed on the system after the migration has been completed. During package update, the migration process will:
/etc on different BTRFS subvolume
or no BTRFS at all), and what to do in this case./etc/selinux/selinux_modules_migrated-*)/var/lib/selinux) to preserve state (marker files
selinux_modules_pending-* and temp_selinux_modules_dir_created)/etc/selinux)*.local files, 200, 400 and
disabled folders) from the old location to the new location, show diff in
case of missing custom modules from /etc/selinux (marker file
selinux_modules_migrated-*)cleanoldsepoldir.service) and
script(/usr/libexec/selinux/cleanoldsepoldir.sh) to remove the old
/var/lib/selinux location once no snapshot is using itAfter package update:
cleanoldsepoldir service checks if any snapshot still requires
/var/lib/selinux. If not, it removes the directory, and creates marker file
var_lib_selinux_deleted to stop the cleanoldsepoldir service from running
again.$ /usr/libexec/selinux/cleanoldsepoldir.sh -h
This script checks if it is safe to remove the old /var/lib/selinux directory.
Usage:
/usr/libexec/selinux/cleanoldsepoldir.sh (Checks snapshots and deletes /var/lib/selinux if safe)
/usr/libexec/selinux/cleanoldsepoldir.sh --check-custom-selinux-modules (Checks for unmigrated custom modules)
/usr/libexec/selinux/cleanoldsepoldir.sh -h|--help (Displays this help message)
These packages contain the SELinux policy packaging and were the main object of the migration:
libsemanage-conf (store-root set to /etc/selinux/semanage.conf)selinux-policy (service cleanoldsepoldir.service and script
cleanoldsepoldir.sh)selinux-policy-* (actual migration and marker files in /etc/selinux)All packages which set SELinux booleans were rebuilt:
selinux-policy-targeted-gamingselinux-policy-sapenablementcontainer-selinuxlibvirtPackages which ship custom SELinux modules were also fixed and rebuilt:
cockpit-ws-selinuxdrbd-selinuxgoogle-guest-oslogin-selinuxswtpm-selinuxtigervnc-selinuxtpm2.0-abrmd-selinuxWe tried to identify all packages affected by this migration, but if you should find other packages in Tumbleweed which need to be migrated, please report a bug.
/etc/selinux/selinux_modules_migrated-*
corresponding to your installed policy (e.g.
/etc/selinux/selinux_modules_migrated-targeted). If the directory exists,
the migration has been successful. If not, please open a bug.selinux-policy* package and any affected external modules:
$ sudo zypper in -f selinux-policy selinux-policy-targeted
/var/lib/selinux is preserved,
which means that some older snapshots may still be inconsistent with it. If
rolling back to one of these older snapshots is necessary, you can fix the
issues after rolling back by reinstalling the policy and any affected external
modules as detailed above.The openSUSE SELinux team is committed to keeping openSUSE users safe with SELinux, and to fixing problems that SELinux may cause to the community. To facilitate changes with SELinux we rely on users to work with us and provide feedback, so that we understand what the current problematic areas are. If you encounter problems with SELinux feel free to open a bug or reach out over the mailing list.
chown() via Symlink Attack in sync() Methodreset() Method/var/lib/plasmalogin/wallpapers in save() Methodsave() Methodsave() MethodIn recent releases of the KDE desktop environment a fork of the SDDM display
manager called plasma-login-manager has been
integrated. As usual this led to a review in our team for the
privileged D-Bus components contained in the package. While most of the code
remains the same, the new upstream added a privileged D-Bus
helper called plasmaloginauthhelper, which suffers from
defense-in-depth security issues. The full details of the
issues will be discussed in the following sections.
For this review we looked into plasma-login-manager version 6.6.2.
plasmaloginauthhelper makes the D-Bus interface
“org.kde.kcontrol.kcmplasmalogin” accessible to all users in the system via
the D-Bus system bus. It offers three actions sync(), reset() and save()
which are all by default protected by Polkit’s auth_admin setting.
These methods allow to manage configuration data stored in the home directory
of the plasmalogin service user, which has a preset of /var/lib/plasmalogin.
The helper runs with full root privileges and interprets various
client-supplied data. The plasmalogin home directory has the following
permissions:
drwxr-x--- 5 plasmalogin plasmalogin 4.0K Mar 24 13:25
Actually this helper is also a kind of fork of a helper found in the
sddm-kcm repository, which we covered in a previous
report. It seems the codebase has not improved since then,
but rather additional attack surface has been added in the meantime.
chown() via Symlink Attack in sync() MethodIn the sync() method the helper service naively performs
chown() calls on files located in the service user’s home
directory (/var/lib/plasmalogin), allowing a plasmalogin to root
exploit.
The chown() is performed for the paths $PLASMALOGIN_HOME/.config,
$PLASMALOGIN_HOME/.config/fontconfig as well for a list of configuration
files like plasmarc placed into $PLASMALOGIN_HOME/.config.
A compromised plasmalogin service account can place symbolic links here to
direct the chown() to arbitrary files in the system. After the chown() the
helper writes client-supplied content into these files, which will also end up
in arbitrary files in case of a symlink attack.
This method’s logic would also allow deletion of certain files like plasmarc
in arbitrary directories, would the relevant
statement in the service implementation not lack the
final filename component in the path construction:
QFile(homeDir + QStringLiteral("/.config/")).remove();
Thus this removal logic doesn’t work at all at the moment, since it attempts
to remove the .config directory instead of the actual configuration files.
reset() MethodIn the reset() method the paths $PLASMALOGIN_HOME/.cache and
$PLASMALOGIN_HOME/.config/fontconfig are recursively deleted. For this
purpose the Qt API QDir::removeRecursively() is used. The
implementation of this function follows symbolic links even in the
final path component, which means that a compromised plasmalogin service
user can leverage this logic to achieve the deletion of arbitrary directory
trees in the system.
/var/lib/plasmalogin/wallpapers in save() MethodIn the save() method the path /var/lib/plasmalogin/wallpapers
is created and opened by root, using a system call
sequence affected by a race condition. A compromised plasmalogin user can
replace the directory by a symbolic link in time for the service to write
wallpaper files to arbitrary locations in the system, leading to local
Denial-of-Service (DoS) and integrity violation.
In this spot the helper employs a low-level openat2() system
call to avoid symbolic link resolution, but this only
applies to the actual files placed within the wallpaper directory, not to the
directory itself, which is naively opened before that.
save() MethodIn the save() method the contents of the file /etc/plasmalogin.conf can be
completely controlled by the caller. Since this
method is protected by auth_admin Polkit authentication this is basically
acceptable, but there is not even an integrity or syntax check of the data,
the method blindly forwards whatever the client passes to it into this file,
without a maximum size limit or any sanity checks. While this is not directly a
security issue it is a lack of robustness, because the D-Bus service is
responsible for maintaining a sane structure of the privileged configuration
file, preventing a broken system e.g. in case of buggy clients.
save() MethodFor the actual wallpaper files, file descriptor passing
is employed, which is good. There is no upper limit enforced on the amount of
data placed into the wallpapers directory, however, which allows to exhaust
disk space in /var/lib/plasmalogin.
Even file descriptors passed from clients should be verified to check whether they refer to regular files and have no unexpected file flags set. This verification is missing.
We suggested the following fixes to upstream:
plasmalogin user before
performing any file system operations in /var/lib/plasmalogin, thereby
eliminating all symlink attack surface. There still remains
Denial-of-Service (DoS) attack surface if the service user places e.g. a named
FIFO pipe somewhere. Avoiding this requires careful inspection of each path
component by the service before opening it./etc/plasmalogin.conf.plasmalogin user’s home directory.O_PATH set.None of the issues in this report is exploitable in a default installation of
plasma-login-manager. Most of the problems affect the situation when the
plasmalogin service user is compromised and thus affect defense-in-depth.
It is conceivable, however, that some actions in the helper, like the
wallpaper management, could be reduced to lesser authentication requirements
like a Polkit yes setting for locally logged-in users in the future, be it
due to upstream changes or due to choices made by system integrators. Then
further problems like disk space exhaustion by other unprivileged users could
sneak in as well.
Based on the high severity of the defense-in-depth issues shown in this
report, our assessment is that there is effectively no separation between
root and the plasmalogin service user account.
At this time there is no bugfix available by upstream, but a security fix is planned for the next Plasma release on May 12. We have not been involved in upstream’s bugfix process so far and have no knowledge about the approach that will be taken to address the issues from this report.
We suggested a single CVE assignment relating to the lack of privilege drop of the D-Bus service, which is the root cause of most of the issues described in this report. In coordination with upstream we assigned CVE-2026-25710 and shared it with them to track these defects.
| 2026-03-30 | We reached out to security@kde.org with a report of the problems, offering coordinated disclosure. We stated that in our eyes, due to the issues being restricted to defense-in-depth, an embargo would not be strictly necessary. |
| 2026-03-30 | Upstream provided a short reply, asking for a CVE assignment. |
| 2026-03-31 | We assigned CVE-2026-25710 and shared it with upstream. |
| 2026-04-13 | Lacking a more detailed response from upstream we asked once more whether they would like to perform coordinated disclosure and what the desired coordinated release date (CRD) would be in that case. |
| 2026-04-13 | We received a reply from upstream stating that no coordinated disclosure would be necessary and bugfixes would be published via public pull requests soon in expectation of a security release on May 12. |
| 2026-04-13 | To be sure we asked upstream once more whether they agreed to us publishing the report right away. |
| 2026-04-20 | Lacking a response and with no visible publication on upstream’s end we asked once more if publication on our end would be acceptable for them. |
| 2026-04-21 | We received a response confirming that we were allowed to publish right away. |
The winter months have passed for us and as usual we want to give you an overview of what topics our team covered in the area of code reviews during this time. We did not publish any dedicated security reports for a while, after we had to deal with a little burst of publications at the beginning of the year. Still we haven’t been idle during this time and looked into various packages and components, which we will cover in this post.
The next section discusses continued review efforts
surrounding new systemd releases. Section 3 covers a follow-up
audit of changes in the Snap package manager. Section 4
looks at bootkitd, a D-Bus service for managing bootloader configuration.
Section 5 deals with libpgpr, a signature parsing library
which was pulled out of the RPM package manager codebase. Section
6 is about changes we reviewed in a new release of GNOME display
manager (GDM). Section 7 contains a review report about the
rtkit real-time scheduling D-Bus service. Section 8
provides an insight into efforts to package SteamOS components for openSUSE
Tumbleweed. Section 9 looks into an attempt to get Deepin
desktop components back into openSUSE.
We already gave an insight into our efforts of reviewing changes in systemd v258 in our previous spotlight post. Meanwhile systemd upstream has established a new release model leading to more frequent releases and backports of new features into existing stable branches. This has caused an increase of review requests in our team, as can be seen by the following list of review bugs we received since the v258 version release:
The review of changes in systemd 260 has just been finished and the new version is about to become available in openSUSE Tumbleweed soon. The backports into stable 258 branches have been easy to review so far, since they are mostly clean cherry-pick merges of changes reviewed by us earlier already.
So far we did not find any issues in the continued changes in systemd, but it remains a challenging review target especially in the area of virtual machine and container APIs, as we have explained in earlier posts on the topic.
After we accepted snap into openSUSE Tumbleweed a while ago we received a follow-up review request, which revolves around a feature to transparently make systemd services available which have been installed via Snaps.
We have accepted the change, but asked the packagers to include a notice in the package informing openSUSE users that systemd services installed via Snaps are not covered by the security review processes of SUSE product security.
Bootkitd is a D-Bus service for programmatically managing
bootloader configuration. We received a review request for
its inclusion into openSUSE Tumbleweed. The service is implemented in the Rust
programming language and is a simple case regarding security, since it is only
accessible by root. Thus no privilege boundaries are crossed and privilege
escalation is not a concern.
libpgpr is a library which has been recently separated from
the main RPM package manager codebase. Its purpose is the parsing and
verification of PGP signatures as they are found embedded in RPM files. Given
the sensitive nature of PGP cryptography and potentially crafted input data,
we have been asked to check the security of this library.
The library consists of a legacy C codebase living up to the C90 standard. The library API is not well documented and not very consistent at the moment. At the same time the code is concerned with memory management and binary data structure parsing of high complexity. These shortcomings notwithstanding, the implementation seems to have matured over time and we believe there are currently no major errors to be found when processing untrusted data.
In our opinion, the biggest danger regarding security in this codebase will likely be future changes which might introduce regressions. Also users of the library won’t easily know what to expect of the API, since requirements are not clearly marked (e.g. which parameters are optional, when memory ownership transfers happen and so on).
We provided comprehensive comments on the codebase to upstream, suggesting various refactoring, improvements and test coverage to bring the project up to a more modern standard.
In February our openSUSE Gnome Display Manager (GDM) maintainers started preparing the upgrade for release 50, which was in Beta testing at the time, but should be fully released by now. The new version triggered a follow-up review of D-Bus and Polkit related features in GDM.
GDM is tightly integrated with GNOME remote desktop (GRD) these days and the changes we’ve seen here are related to this integration. The differences compared to the previous version of GDM have been small in the area of D-Bus and Polkit, though, and no problematic additional attack surface has been added in this version.
The rtkit daemon has been around on Linux distributions for
a long time. Its purpose it to allow unprivileged programs in the system to
make use of real-time scheduling features in a controlled fashion. Linux
offers two real-time scheduling policies SCHED_RR and
SCHED_FIFO, which perform Round-robin or First-in First-out scheduling
respectively. Rogue processes running under one of these policies can easily
lock up the complete system due to no other userspace threads being scheduled
by the kernel anymore. For this reason, only tasks holding the CAP_SYS_NICE
capability (usually only root) are allowed to assign these scheduling
settings.
This is where rtkit comes in: it offers a D-Bus interface to allow
unprivileged processes to enjoy real-time scheduling features while being
under supervision of the rtkit daemon to prevent any negative side effects.
In a recent update of rtkit to version 0.14, changes in its D-Bus
configuration triggered a follow-up review after over a decade
since our team last looked at it. rtkit is installed and running (or
activatable) by default on a number of Linux distributions like openSUSE,
Debian or Fedora. Due to this prevalence of rtkit in Linux systems, the
inherent danger of a local Denial-of-Service and in light of the amount of
time passed since the last full review, we thought it wise to have a fresh look
at the service’s implementation.
The rtkit D-Bus configuration follows a bit of an unusual approach by
maintaining a deny list of methods which may not be
invoked by non-root users. This is not ideal, since additional methods will
automatically be accessible to all users in the system, should a developer
forget to update the deny list. At the moment no problems exist in this area,
however.
The blacklisted D-Bus methods which are only accessible to root affect the
global state of the daemon. The remaining D-Bus methods are used to request
real-time scheduling for caller-owned processes. These methods are
additionally protected by Polkit authentication; the related Polkit actions
are set to yes for local users in an active session, meaning that local
interactive users can invoke them without authentication.
The implementation of Polkit authentication relies on
rather complex custom code based on the “unix-process” Polkit authentication
subject. This subject is often affected by race conditions and the D-Bus
“system-bus-name” subject should rather be used. In this case the use of
“unix-process” is acceptable, since the request includes not only the client’s
PID but also its process start time and UID, which is retrieved from the UNIX
domain socket D-Bus connection. Thus there should be no way that race
conditions can be exploited in a way that the client is mistaken for root,
for example.
The actual application of real-time scheduling to a client’s target
process is highly affected by race conditions, due to the retrieval of data
from /proc/<pid> and the fact that processes can disappear and/or be
repurposed at any time. The developers are obviously aware of the potential
issues, since they verify the target process’s properties before and after
changing its scheduling properties. Such detection
of a race condition after the fact is problematic when the risk is a lockup of
the whole system.
Due to this, the daemon also maintains a watchdog and a canary thread to counteract any unexpected effects of unprivileged real-time scheduling. The watchdog runs at the highest real-time scheduling priority and periodically monitors whether the canary thread, which is running with low scheduling priority, is still being scheduled. If a stall is detected, then the watchdog thread removes the real-time scheduling settings from all registered client tasks to recover the system. Additionally the daemon monitors the amount of requests individual users are sending, and blocks them if a threshold is exceeded.
It is clear that the implementation of this service is confronted with various
uncertainties and it tries to make up for them. The overall result is not
ideal but should be good enough to prevent major security issues. An
improvement to the design could be to obtain a directory file descriptor for
/proc/<pid> of the target process, verify the process’s credentials and
further on only use the directory file descriptor anymore for accessing
process data. Explicit PID file descriptors might also help in some other
spots these days (they can also be used for authentication with Polkit now,
for example).
There is continued effort by community packagers to bring SteamOS-related components to openSUSE. We already covered one of these components in one of last year’s spotlight posts. This winter we received three additional review requests in this area. Packaging these components is often difficult, because the programs use fixed non-standard paths and approaches that don’t fit well into a general-purpose Linux distribution. We will look into the individual packages in the following sub-sections.
This review is about a fan control daemon which
regulates the speed of the Steam Deck fan. The daemon itself is acceptable, it
mostly deals with hardware information and controls found in /sys and
therefore it crosses no security boundaries. It also creates a world-readable
logfile in /var/log, which only contains fan data, however, thus not
resulting in a relevant information leak towards unprivileged users.
A Polkit action allows to start and stop the daemon by providing the
administrator password, which is also fine. A wrapper script which performs
these start/stop actions is placed into
/usr/bin/steamos-polkit-helpers/jupiter-fan-control, which is a non-standard
location, but according to the packager is hard-coded into SteamOS components
and cannot be changed.
This review is concerned with a set of scripts which allow to perform a factory reset operation on SteamOS. On openSUSE there is nothing sensible that can be done in terms of a factory reset, thus the packager added scripts that are in effect no-ops. Still these scripts were supposed to be invoked with root privileges via Polkit authentication. After a longer discussion with the maintainer we decided to take a different approach that does not require to run dummy scripts with root privileges, but still allows system integrators to hook into the process and change the behaviour.
The third review is concerned with a bunch of SteamOS scripts that automatically perform actions like mounting removable devices without requiring authentication, expecting a single “deck” interactive user in the system. The community packager discussed some aspects of these privileged operations with us and how to best integrate them into openSUSE. The effort is still ongoing.
A year ago we announced the removal of Deepin desktop components from openSUSE because of policy violations and bad security. Deepin upstream promised to improve the problematic components and we offered to have a fresh look at things when they would have something new to show. As a result a follow-up review bug was created in which the Deepin package maintainer claimed that all reported security issues were fixed by upstream. The following sections discuss two of the D-Bus components we revisited in this context.
A small D-Bus helper for controlling laptop backlight seemed like a promising start; the code is clean and conservative. It is lacking Polkit authentication, however, which means that any user in the system can meddle with the backlight. Such settings are usually restricted to local interactive users in an active session. We informed upstream about this shortcoming and there is supposed to be a fix available by now, but we didn’t look into it yet.
The Deepin accounts service offers a larger D-Bus interface for managing user accounts in the system. We looked into version 6.1.66 of the project. Unfortunately we quickly discovered new security issues in this component:
CreateGuestUser() D-Bus method, which
requires admin authentication, creates a user account with an empty password
and a home directory in a random location in /tmp. The creation of this
directory is affected by a race condition, which could allow other users in
the system to pre-create the directory. A home directory in /tmp is highly
unusual and empty passwords, even for guest accounts, are bad practice.SetHomeDir() D-Bus method, which requires
only user-level self-authentication, allows to move the user’s home
directory into arbitrary new locations, even /root. This operation is
performed via the command line usermod -m -d <new-home-path> <username>. The
only aspect that prevents a simple local root exploit is that usermod
refuses to perform the operation if the calling user still has processes
running in the system. How this API function could ever be used meaningfully
for self-administration, then, is puzzling. It might be possible for an
attacker to overcome this check, however, by quickly killing all of its
processes just in time for the usermod invocation to succeed.SetPassword() D-Bus method, again
accessible by providing the user password, is affected by multiple issues:
ModifyPasswd().removeLoginKeyring()
which is invoked in this context operates as root in the user’s home
directory, offering local Denial-of-Service attack surface.newPwdChangerX() performs a
chown() on the client’s .XAuthority file placed into
/run/user/<uid>/.XAuthority, which is a local root exploit attack vector.The openSUSE Deepin packager informed us that there are also fixes for these issues available by now, but we did not get around to verify them yet.
Due to the recurring number of security issues, the amount of time required by upstream to address them and a lack of a formal security fix workflow in the Deepin project we stopped assigning CVEs for the issues we find in Deepin. We don’t see much value in further CVEs since the security issues are often quickly replaced by other security issues, thus resulting mostly in noise. Overall we don’t recommend to use Deepin components until the security culture of Deepin upstream improves.
By now we are also treating Deepin review requests with lower priority, since the efforts which went on for years still haven’t yielded acceptable results and we would rather invest our resources into other, more promising packages.
One of the fundamental goals of the SUSE Security Team is to keep a high standard regarding software available in SUSE distributions. Not blindly accepting new software releases is necessary to uphold this commitment, which also means often revisiting software we already looked into before.
Keeping up with the fast pace of projects like systemd can be challenging in this regard, but the security issues we continue to find e.g. in Deepin software show that this work is still useful. The Spotlight series is one way to highlight this continuous and not always necessarily glamorous work.
]]>Cosmic is a Linux desktop environment written in the Rust programming language. There is an ongoing effort to package it for openSUSE Tumbleweed; in this context we reviewed a number of Cosmic components, among them a D-Bus service found in cosmic-greeter. We found issues when the service accesses home directories of unprivileged users, which will be described further below. This report is based on cosmic-greeter version 1.0.8.
cosmic-greeter-daemon is implemented in
daemon/src/main.rs, runs with full root privileges
and offers a D-Bus interface “com.system76.CosmicGreeter” on the D-Bus system
bus. The interface only provides a single D-Bus method
“com.system76.CosmicGreeter.GetUserData”.
This D-Bus method is only allowed to be called by members of the
cosmic-greeter group, not by arbitrary other unprivileged users. What the
method does is basically looking up all
non-system user accounts in /etc/passwd and gathering Cosmic configuration
data from every user’s home directory.
The code contains a comment, outlining that it is important to drop privileges to the owner of the home directory being processed, to prevent security issues. While this is a good starting point, the actual implementation of this logic is still lacking in a number of spots.
Following is an excerpt of an strace of the cosmic-greeter-daemon process
during invocation of the D-Bus method. The output will help illustrate some of
the issues in question:
setresuid(-1, 1000, -1) = 0
<...>
statx(AT_FDCWD, "/var/lib/AccountsService/icons/<user>", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7feb5d5f8a50) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/home/<user>/.local/share/cosmic/com.system76.CosmicTheme.Mode/v1", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7feb5d5f8800) = -1 ENOENT (No such file or directory)
mkdir("/home/<user>/.config/cosmic/com.system76.CosmicTheme.Mode/v1", 0777) = -1 EEXIST (File exists)
statx(AT_FDCWD, "/home/<user>/.config/cosmic/com.system76.CosmicTheme.Mode/v1", AT_STATX_SYNC_AS_STAT, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFDIR|0755, stx_size=4096, ...}) = 0
statx(AT_FDCWD, "/home/<user>/.config/cosmic/com.system76.CosmicTheme.Mode/v1/is_dark", AT_STATX_SYNC_AS_STAT, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFCHR|0666, stx_size=0, ...}) = 0
mkdir("/home/<user>/.config/cosmic/com.system76.CosmicTheme.Dark/v1", 0777) = -1 EEXIST (File exists)
openat(AT_FDCWD, "/home/<user>/.config/cosmic/com.system76.CosmicTheme.Dark/v1/palette", O_RDONLY|O_CLOEXEC) = 11
<...>
setresuid(-1, 0, -1 <unfinished ...>
What we are seeing here is that the privilege drop only concerns the effective
user ID of the cosmic-greeter-daemon process. The root group credentials are
retained. This means any potential attacks by the owner of a home directory
can still try to leverage root group credentials to their advantage.
Given this, the file operations performed in the user’s home directory are subject to a range of security issues:
directory components within the path can be replaced by symbolic links. E.g. if a user places a symlink like this:
$HOME/.config/cosmic → /root/.config/cosmic
then the daemon would actually process root’s Cosmic configuration files, provided that root’s home directory is accessible for members of the root group.
stat() before trying to open
configuration files, for example. This is a typical
Time-of-Check/Time-of-Use (TOCTOU) race condition, however, because the owner
of the home directory can attempt to replace a regular file by a symbolic link
or special file by the time the actual open() call is performed by the
daemon. This can lead to the following potential issues:
/dev/zero, an out-of-memory situation
can be triggered in the daemon, causing it to be killed by the kernel,
leading to a local Denial-of-Service (DoS).nobody user account is included (UID 65534). As a
result, the daemon also attempts to process Cosmic configuration in
/var/lib/nobody on openSUSE.
This grants processes operating with nobody privileges the opportunity to
attempt to exploit the daemon’s logic.The severity of these issues is reduced by the fact that only members of the
cosmic-greeter group are allowed to invoke the GetUserData D-Bus method,
thus potential attackers have to wait for an authorized process to call the
function to attempt to exploit it. We don’t have enough insight into the
bigger picture of the Cosmic desktop environment, but it could be possible
that local users are able to indirectly trigger the execution of this D-Bus
method by using other APIs made available by Cosmic.
We suggested the following improvements to upstream to deal with the issues:
O_NOFOLLOW|O_NONBLOCK
to prevent symlink attacks, then perform an fstat() on the open file
to determine its type in a race-free fashion.nobody user account should be explicitly excluded based on its name
for distributions that set a valid shell for this account.cosmic-greeter-daemon.service can
be extended with directives like ProtectSystem=full. This needs some tuning,
though, since the daemon still needs to be able to read files in home
directories of other users.Upstream implemented commit 63cd93bddd0 containing the following changes:
UID_MIN and UID_MAX as configured
in /etc/login.defs will be considered./var/lib/accountservice will be opened with O_NOFOLLOW
(actually an unrelated change / security hardening).This bugfix is part of upstream release 1.0.9 and newer.
What is still missing from our point of view is the prevention of local DoS attack surface when accessing files in the user’s home directory. We informed upstream about this but have not heard back about this topic for a while.
Upstream has not expressed any wishes regarding CVE assignment, or whether one should be assigned at all. We decided to assign a single CVE-2026-25704 from our pool to track the main aspect of this report, the incomplete privilege drop in the daemon.
| 2026-03-11 | We forwarded this report to security@system76.com and the main developer of cosmic-greeter, offering coordinated disclosure. |
| 2026-03-11 | Upstream confirmed the issue and opted out of coordinated disclosure. |
| 2026-03-11 | We got a follow-up response asking us to keep the information private for while longer after all. |
| 2026-03-11 | We received a patch from upstream corresponding to commit 63cd93bddd0 and have been asked to review it. |
| 2026-03-12 | Upstream meanwhile created a public pull request based on this bugfix and informed us that the report no longer needed to be private. |
| 2026-03-13 | We assigned CVE-2026-25704 to track the main aspect of the vulnerability, an incomplete privilege drop. |
| 2026-03-13 | We shared the CVE with upstream and provided feedback on the bugfix, mainly pointing out that local Denial-of-Service (DoS) attack service still remains. |
| 2026-03-13 | Upstream informed us that they are going to address these remaining issues as well. |
| 2026-03-24 | We asked upstream about the status of the additional fixes, but received no response so far. |
| 2026-04-16 | Publication of this report. |
UYUNI is an open source system management solution, forked from Spacewalk and upstream community project from which SUSE Multi-Linux Manager is derived.
The audit started in January 2024 with the perimeter definition. Since it’s not feasible to audit everything, a list of packages was chosen and submitted to UYUNI product owner. The criteria for including a package in the perimeter were:
salt package (fundamental for UYUNI server and minions interaction)In March 2024 the code scanning activities effectively started.
Auditing a complex codebase like UYUNI is not just running a static analysis tool and waiting for it to complete. It is a complex and long-running journey that took one year and a half to complete.
The codebase is big with a lot of sub-packages. Each sub-package was treated as a standalone audit with its own Bugzilla bug, its own list of affected vulnerabilities and its own report. The final report was produced by combining the reports of all sub-packages.
The audited codebase is more than 4.5 millions lines of code, with at least 7 different programming languages.
| Language | Files | Lines of code |
|---|---|---|
| JavaScript | 2547 | 3805282 |
| Java | 4052 | 369100 |
| Go | 795 | 250684 |
| Python | 407 | 103965 |
| JSP | 641 | 36861 |
| Shell | 86 | 6744 |
| Perl | 65 | 6070 |
As you may wonder, using a single catch-all tool to analyze such a heterogeneous codebase is not possible.
Every package in the scanning perimeter was audited looking at the source both using tools and by manual inspection. The running server was continuously inspected dynamically looking for low-hanging fruit like cross-site-scripting (XSS), SQL injection and similar, and for business logic flaws.
Each security issue was then triaged and if necessary a CVE identifier was assigned and the vulnerability put under EMBARGO. Using the openSUSE coordinated disclosure policy as a framework, we coordinate with upstream and disclose the issue when solved.
We use Bugzilla as tracking authority for audits and vulnerabilities found during the activity. A master bug (boo#1218619) was created with the purpose of acting as a main container for all sub-packages audit bugs.
Each audit bug contains all affecting vulnerabilities and, of course, a vulnerability bug can be set as blocker to more sub-packages.
For the activity, a set of KVM-powered machines were created:
The server is the main UYUNI component orchestrating minions attestation and enabling system administrators to launch commands and interact with minions using the web interface.
A minion, in the UYUNI slang, is a Linux-powered machine (ideally it is a client in a local network), connected to the server.
A UYUNI proxy is a particular kind of server, used to fetch packages from software distribution channels and centrally store software packages for an efficient distribution to minions. Distribution channels are software repositories and a system administrator subscribes his own UYUNI instance to different repositories.
Each server was running openSUSE MicroOS as underlying operating system and minions were running either openSUSE Tumbleweed or Ubuntu Linux distributions.
For the testing activities we used two different machines. A virtual machine running openSUSE Tumbleweed, used for source code inspection and a virtual machine running Kali Linux installed to help in penetration testing activities.
Burp Suite community was the main tool used trying to spot security issues in the running application.
To help, during the UYUNI application browsing, a custom tool was developed. While browsing the web UI trying to find business logic flaws, I felt the need for something running in the background spotting low-hanging fruit in web pages form, cookies and more. The tool eventually became an OSS project named nightcrawler-mitm. It’s a mitmproxy extension implementing both an active and a passive scanner running several security controls in the background.
Also for auditing the source code, opensource tools were used. Some of the tools used are famous OSS projects, like:
To help me during the activities, I also used some SAST tools previously written by myself, like:
As discussed before, every finding was tracked on a separate bugzilla bug. Each bug was linked, marking as a blocking bug, to any sub-package audit bug affected by the associated vulnerability.
Of course, every vulnerability was confirmed by a successful exploitation, before being added to our Bugzilla tracking system. Vulnerabilities were assigned to UYUNI developers and tracked until a fix was released. A CVE was also assigned if required by the issue severity.
The standard CVSS version 4 was used as a scoring system and to assign a severity. The rationale is that if a CVSS is lower than 5, then the severity is low, it is medium if CVSS is between 5 and 7 and high otherwise. The same approach was used to assign a triage score to each sub-package. The triage score will be used in the future to decide if the sub-package must be in future audit perimeter or not.
At the end of the audit, the list of issues and the triage score created a technical report sent to UYUNI developers.
During the audit, seven CVEs were found and fixed, and numerous minor issues were addressed, improving the product’s reliability and overall security posture.
A reflected cross-site scripting has been found in the HTTP proxy pane of the setup wizard UI element. Tracked in boo#1231852
A reflected cross-site scripting has been found in the Organization Credentials pane of the setup wizard UI element. Tracked in boo#1231922
Some URLs, served by the SystemsController.java class are vulnerable to a reflected XSS vulnerability. Some example of vulnerable URLs are listed in the Github advisory as well. The
advisory
was filed by an external independent researcher following
our coordinated disclosure policy.
Tracked in boo#1239826
Credentials to be used in UYUNI HTTP proxy are disclosed in the error log in case of wrong port number or misspelled hostname. Tracked in boo#1245005
During an internal assessment, a customer found an issue with the remote-commands websocket endpoint (/rhn/websocket/minion/remote-commands).
Using websockets, anyone with the ability to connect to port 443 of SUSE Manager is able to run any command as root on any client with no authentication. The customer using our coordinated disclosure policy as a reference, reported the issue which was then fixed and publicly disclosed. Tracked in
boo#1246119
During an internal assessment, a customer found that some reflected cross-site scriptings were possible due to improper input validation. The issue was tracked in the private SUSE bugzilla instance, since some customer sensitive information was included. However the issue is described in the public CVE-2025-53883 page.
A Path Traversal vulnerability in the tftpsync/add and tftpsync/delete scripts allows a remote attacker on an adjacent network to write or delete files on the filesystem with the privileges of the unprivileged wwwrun user. Although the endpoint is unauthenticated, access is restricted to a list of allowed IP addresses. The unprivileged user has write access to a directory that controls the provisioning of other systems, leading to a full compromise of those subsequent systems. Tracked in
boo#1246277
Additional vulnerabilities were identified that, while valid, did not meet the criteria for CVE assignment:
Last but not least, during the audit also some codebase improvements were suggested to raise the security posture even further:
The UYUNI audit was an intense and rewarding run. The good results in term of number of found vulnerabilities and the fast reaction to release the fixes, confirmed UYUNI as a solid and reliable product for the community.
As all software, of course it can be improved in terms of code quality by applying safe coding patterns, using secure and reliable third-party libraries and consolidating the usage of one or two programming languages. This is an important step, because it creates a common ground for engineers and a solid codebase for the community to entice contributions and pull requests.
A vibrant codebase, using a balanced mix between standard and cutting edge technologies can increase adoption of the product and it can attract developers and contributors.
It also helps in adopting safe coding best practices that are widely updated and developed for newer technologies rather than ancient and not actively used programming languages.
The low number of vulnerabilities found, and the reaction time in fixing the serious ones, indicate that the project is well-curated and actively maintained. The security posture is good and it can be safely deployed in production.
Like every journey, the final destination is not the reward itself. The UYUNI project is actively under development with a monthly (more or less) release cycle.
The next audit will start in the first quarter of 2026 and it will be another one year and a half rollercoaster ride, with rabbit holes, false positives, suspected CVEs turning out to be not exploitable and real root dance issues.
The fun part is to audit code written in multiple languages, with different stacks and libraries.
It’s not rewarding only from a security perspective, it’s a real learning experience.
systemd v258 Code Reviewplasma-setup KDE Package
plocate Binaryvirtualbmc Project
snapd Package ManagerThe winter season has already begun for most of the people in our team and with the Christmas holidays behind us, which granted us some well-earned rest, we want to take a look back at what happened in our team during the autumn months. During this time we already published a few dedicated review reports:
OpenSMTPD mail
transfer agent.scx scheduler project allowing
for a major local Denial-of-Service.lightdm to root in
lightdm-kde-greeter leading to major improvements of its D-Bus code.smb4k, resulting in upstream fixing a series of
long-standing issues in the affected component.In this post, as usual in the spotlight series, we will look into some topics
that did not justify dedicated reports. First we will discuss our continued
efforts to review privileged components found in the
systemd v258 release, which involved diving deep into some low-level aspects
of the Linux kernel API. Section 3 looks at D-Bus
issues we found in plasma-setup, a new component for the KDE desktop.
Section 4 covers recent discussions about granting special
setgid permissions to the plocate package. Section 5
gives insight into security issues found in the virtualbmc OpenStack
project, which turned out to be for testing purposes only. Section
6 discusses revived efforts to bring the Snap package manager
to openSUSE.
systemd v258 Code ReviewWe already discussed our systemd v258 review efforts in the previous
spotlight edition. At the time we found a
local root exploit in the systemd-machined API, which could be fixed before
the final release of v258. For the addition of this new major version of
systemd to openSUSE Tumbleweed, we still needed to look more closely into a
number of other D-Bus and Varlink services that have been added.
During autumn we completed the review of changes in
systemd-mountfsd and
systemd-nsresourced. Some of the changes
introduced with these services allow unprivileged users to perform a number of
container-related operations without requiring special privileges.
The io.systemd.MountFileSystem.MountDirectory API
call in mountfsd, for example, allows to obtain
a mount file descriptor for a directory owned by the calling user, on which a
user and group ID mapping is applied corresponding to a user namespace file
descriptor also owned by the caller. Some newer, little-known Linux system
calls like open_tree() and
mount_setattr() are used to achieve this. This niche
topic and the low-level nature of the involved APIs result in quite complex
code which needed careful reviewing. We are happy to report that we could find
no issues in this area, however.
The nsresourced service, among other features, allows unprivileged users to
obtain a dynamic range of user and group IDs for use with user namespaces. The
tools newuidmap and newgidmap already
allowed this for a longer time based on static configuration files. The
nsresourced service applies dynamic limits and ID ranges to processes in
the system, however, which makes things quite more complicated. This even
includes an EBPF program, which keeps track
of the uses of the resulting user namespace file descriptors. Despite this
complexity we could not find any issues in this component either.
What kept us busy for a longer time was logic
invoked by mountfsd to obtain the
user and group ID mapping tied to the user namespace file descriptor passed by
the unprivileged client. To retrieve this information, the utility function
ns_enter_and_pin() forks a short-lived
child process which joins the user namespace provided by the client. The
parent process then reads the child’s uid_map and gid_map nodes from
/proc/<child-pid>.
The mountfsd daemon runs with root privileges (although some sandboxing is
applied to it as well), which will be inherited by the short-lived child
process. Once the child process joins the user namespace provided by the
unprivileged client, the security domain of this process changes, however,
because the client owning the namespace is supposed to have full control over
processes associated with it.
One consequence of this is that the owner of the user namespace can send
arbitrary signals to the short-lived systemd process, e.g. to kill it. This
would only result in a kind of Denial-of-Service against the client itself and
should not cause any security issues.
We expected another important ramification of this to be in the area of the
ptrace() system call. The following is stated in the “ptrace
access mode checking” section of the ptrace(2) man page:
(3) Deny access if neither of the following is true:
• The real, effective, and saved-set user IDs of the target
match the caller's user ID, and the real, effective, and
saved-set group IDs of the target match the caller's group
ID.
• The caller has the CAP_SYS_PTRACE capability in the user
namespace of the target.
According to the second item, the unprivileged client, which owns all
capabilities in its user namespace, should be able to trace the short-lived
systemd process which joins the client-controlled user namespace. This
ability would have allowed for an interesting privilege escalation, because
tracing capabilities also include the ability to modify the target process,
e.g. to change its code and data. While trying to reproduce this, the kernel
always denied ptrace() access to this short-lived process, however, and we
were not sure why. Unclarity in such aspects is not a good thing when it
concerns security, thus we set out to get to the bottom of this.
After diving deep into the Linux kernel’s ptrace() code, we found the
commit which is responsible for the rejection of
tracing access in this scenario. The background of this commit actually is
to prevent owners of unprivileged user namespaces from accessing the
executable of processes created in the initial namespace. ptrace() access to
the target PID is now only allowed if the target process performed an
execve() while being a member of the newly joined user namespace. In summary
this means the following:
fork() and setns() to join a user namespace,
then ptrace() access to this process is denied to the owner of the user
namespace.fork(), setns() and execve(), then ptrace()
access to this process is granted to the owner of the user namespace.This detail is not documented in the ptrace() man page and it
took us a while to fully understand what was going on. With this well
understood we could finally move on, knowing that the logic in mountfsd is
robust.
plasma-setup KDE PackageThis new KDE component was first named KISS (KDE initial system setup), but
meanwhile has been renamed to plasma-setup.
Its purpose is to perform initial system configuration based on a graphical
wizard, when a Linux system has been freshly installed.
Our openSUSE KDE packagers asked for a review of this new component, expecting it to be part of a major KDE release in autumn. It turned out that this had not been planned by upstream after all (or plans changed). Still the review we performed turned out to be useful, since we identified various security problems in the existing code which could be fixed by upstream before the new component had seen production use.
The following report is based on the plasma-setup source code as of upstream
commit 08ed810e0e7. While the graphical
components of plasma-setup run with low privileges, there exists a D-Bus
helper service running as root, kde-initial-system-setup-auth-helper,
which allows to perform a number of operations with elevated privileges. These
operations are guarded by Polkit authorization rules. The dedicated user
account kde-initial-system-setup is allowed to invoke any of these actions
without authentication. Beyond this, any locally logged-in users are also
allowed to invoke the operations without authentication. The latter is quite
problematic, as will be outlined below.
The implementation of the D-Bus callbacks for these actions is found in
src/auth/authhelper.cpp. The following
sub-sections discuss issues in a couple of these actions.
This action receives a “username” parameter
from the unprivileged D-Bus client. The username is not verified by the
privileged helper, it only needs to be convertible to QString. The helper
then creates all the directory components of
/home/<username>/.config/autostart. After this, the file
/home/<username>/.config/autostart/remove-autologin.desktop is created and
fixed data is written into it.
This action allows local users to create arbitrary world-readable directories
owned by root. This can be achieved by passing a string like
../../my/desired/path as “username”. Furthermore, by placing a symlink at
the expected location of remove-autologin.desktop, arbitrary files in the
system can be overwritten, leading to a local Denial-of-Service.
The implementation of the action also causes the created directories and files
to be owned by root:root, and not by the user that actually owns the home
directory, which is unclean.
Apart from restricting access to the helper to the kde-initial-system-setup
user, the implementation of this action should verify whether the
passed-in username actually exists. Furthermore, the home directory of this
account should be obtained via the getpwent() API, instead
of assuming that /home/<username> will always be the correct home directory.
When the execution of this helper is actually limited to the initial setup
context, it could be technically acceptable to operate as root in the newly
created user’s home directory. For reasons of prudence and giving a good
example, we still recommend to drop privileges to the target user account
before actually writing the .desktop file in the user’s home directory.
The method call associated with this action also receives a “username” parameter which is not verified. The following command line is invoked based on the “username” parameter:
chown -R <username>:<username> /home/<username>
This is on the verge of a local root exploit, save for the fact that chown
expects a valid user and group account to give the ownership to, which at the
same time needs to result in the proper path to operate on. A username
containing path elements will fail, because the necessary characters like /
are by default denied in usernames.
This action still allows to potentially change ownership of all files of
arbitrary other users’ home directories. Fortunately the recursive chown
algorithm is not subject to symlink attacks these days. If somebody would be
able to place a symlink in place of their home directory in
/home/<username>, then the symlink would still be followed, however.
The username could also be interpreted as an arbitrary command line argument
to chown, thwarted only by the fact that the <username>:<username>
argument is constructed here instead of just passing <username>, which will
prevent proper command line arguments from being passed.
As for the previous action, the implementation should verify if the username
is valid and determine the proper home directory and group via getpwent().
The assumption that username and group are equivalent is also problematic
here.
Why this operation would be needed at all for a newly created home directory
is questionable. When new user accounts are created, file ownership should
already be correct. If this action is supposed to fix the ownership of files
created by other plasma-setup actions in the home directory as root (as is
seen in the createnewuserautostarthook action),
then this is only a hack which should be removed in favor of not creating
files as root in unprivileged users’ home directories in the first place.
Again this method receives a “username”
parameter which is not verified. The
implementation writes the following content to the file
/etc/sddm.conf.d/99-kde-initial-system-setup.conf:
[Autologin]
User=<username>
Session=plasma
Relogin=true
This SDDM configuration snippet is supposed to automatically login the given user account. For some reason that we did not investigate more deeply, the configuration was not effective during our tests on openSUSE Tumbleweed. We could verify that the configuration file created this way was parsed and evaluated in SDDM, however, so something else must have been amiss.
The automatic login is supposed to work, though, and if it does, then any
local user account can call this action with root as username, which should
cause an automatic login of the root user the next time SDDM runs.
By passing crafted strings for “username”, the content of the drop-in configuration file can even be fully controlled by local users. The following “username” would create a General section with a crafted “RebootCommand”, for example:
user\n[General]\nRebootCommand=/home/myuser/evil
Provided the configuration snippet is actually in effect in SDDM, this action allows for a local root exploit.
As for the other actions, the implementation should verify whether the passed
“username” is valid and does not equal root.
We privately approached KDE security on 2025-09-22 with a detailed report
about these findings. As a result we established contact with the
plasma-setup developer and discussed fixes for the issues. It was decided to
perform the bugfix in the open, since the component was not yet part of a
stable release of KDE. We reviewed an upstream merge
request during the course of two weeks and upstream
managed to arrive at a much improved version of the KAuth helper component.
As of commit e6eb1cd9a8d the privileged
helper carefully scrutinizes the input parameters received via D-Bus, and it
also drops privileges to the calling user before operating in the unprivileged
user’s home directory. Also the KAuth actions provided by the helper are now
restricted to the plasma-setup service user and no longer accessible to
all locally logged-in users. The latter would still be problematic, since it
would allow to setup automatic login for arbitrary other users in the system,
for example.
plocate BinaryAn openSUSE community member approached us about granting special setgid
privileges to the plocate binary. plocate is a modern and
fast replacement for the classic locate program. Upstream supports operation
of the plocate program with the setgid bit assigned to the plocate
group. This means that the program is granted plocate group privileges
during execution.
When updatedb, locate’s utility for indexing files, would be invoked with
full root privileges, then the database in /var/lib/plocate would contain
information about all files in the file system. This way locate would grant
all users in the system read access to this information, resulting in an
information leak, because users can see paths that they would not normally be
allowed to list, like all the files stored in the /root home directory. For
this reason the plocate-updatedb system service on openSUSE Tumbleweed runs
as nobody:nobody, resulting in a system-wide plocate database which only
contains information about publicly accessible paths in the system. For being
able to locate their own private files, users need to create their own
user-specific databases instead.
The purpose of the setgid privilege is to address this locate database
access issue. plocate supports a mode in which updatedb is invoked with
full root privileges, but the ownership of the central database is changed to
root:plocate and file mode 0640. When plocate is installed as
setgid-plocate then it is still allowed to access the central database. The
program drops the special group credentials quickly again, right after opening
the database. The program then ensures that the calling user will only be able
to retrieve information about files that it is allowed to access based on its
real credentials.
There is a minor security issue found in this approach. Since the plocate
database does not contain metadata about the files it indexed, the plocate
program needs to check the ownership of files in the file system at the time
the search query runs. This is a sort of a TOCTOU (time-of-check time-of-use)
race condition. There can be situations when the verification in plocate
yields wrong results:
root# mkdir --mode=1777 /shared
root# mkdir --mode=0700 /shared/secret-dir
root# touch /shared/secret-dir/secret-file
root# updatedb
# root will be able to locate any files in secret-dir
root# locate /shared/se
/shared/secret-dir
/shared/secret-dir/secret-file
# non-root cannot locate the secret-file
user$ locate /shared/se
/shared/secret-dir
# now consider root deletes the secret-dir again
root# rm -rf /shared/secret-dir
# now the unprivileged user takes ownership of this path
user$ mkdir --mode=0755 /shared/secret-dir
# this only works before `updatedb` is called again, because then it will
# notice that secret-file no longer exists and delete it from the database.
#
# when the unprivileged user calls locate this time, the secret-file will show
# up, since the "secret-dir" is now controlled by the unprivileged caller.
user$ locate /shared/se
/shared/secret-dir
/shared/secret-dir/secret-file
This problem likely cannot be easily fixed in the plocate code, since it
would require changing the database format radically, increasing database size
as a result, only to fix an unlikely problem.
The information leak is minor and should rarely be exploitable. For this
reason we left it up to the openSUSE plocate package maintainer whether the
setgid-plocate approach should be used, or not.
virtualbmc ProjectBy way of our efforts to monitor newly introduced systemd services in
openSUSE Tumbleweed, the python-virtualbmc
package caught our attention. The program allows to emulate a board management
controller (BMC) interface for use with libvirt.
Part of the package is a daemon running with full root privileges, listening
for ZeroMQ API requests on localhost. A number of unauthenticated API calls
in this context raised our suspicions, which is why we scheduled a full
review of this package. A closer look showed that the
unauthenticated API calls were indeed problematic, even allowing for a full
local root exploit.
We filed a detailed private bug report on
LaunchPad for the OpenStack project, but had
difficulties getting a response. After some weeks we reached out to an
individual member of the OpenStack security team and learned from the reply
that the virtualbmc project was not intended for production use at all, but is
rather a utility intended for use in testing environments. This is also
documented in the repository’s README, which was
overlooked by us. As a result we filed a delete request for the
python-virtualbmc package in openSUSE Tumbleweed, and the package has
already been removed.
For completeness, a detailed report of the security issues in the virtualbmc daemon follows below.
vbmcdWhen the virtualbmc systemd service is started, then /usr/bin/vbmcd runs
with full root privileges. It offers a ZeroMQ-based network API, listening on
localhost port 50891 by default. Any local user in the system can talk to the
daemon this way.
A simple request which can be sent to the daemon (in JSON format) is the following stop command, for example:
{
"command": "stop",
"port": 1234,
"domain_names": ["../../home/myaccount/mydomain"],
}
The domain_name passed here will be used by the daemon to lookup a
supposedly trusted per-domain configuration file, which is by default located
in /root/.vbmc/<domain>/config. Since the daemon does not scrutinize the
input domain_name, a local attacker can include directory components in the
name, to trick the daemon into accessing an attacker-controlled configuration
file.
In the context of the stop command used here, the daemon will try to update
the domain’s configuration file in case a change of domain state is detected.
The path for writing out the updated configuration file will be constructed
using the domain_name found in the input configuration file. Thus the local
attacker can place data like this into /home/myaccount/mydomain/config:
[VirtualBMC]
domain_name = ../../etc/sudoers.d
port = 1234
active = true
address = some
evil stuff
myaccount ALL=(ALL:ALL) NOPASSWD: ALL
The daemon will now believe that the domain’s state changed, because the input
configuration file contains active = true, while the daemon was asked to
stop the domain. This will trigger logic to write out an updated configuration
file with the new state of the domain configuration. The logic for this is
found in the _vbmc_enabled() member
function.
Since the domain_name found in the crafted configuration file is set to
../../etc/sudoers.d, the daemon will write the new configuration file into
/root/.vbmcd/../../etc/sudoers.d/config. To get an advantage from this, the
attacker must get the daemon to write out at least one valid sudoers
configuration line into the new configuration file.
The attacker has only a limited degree of freedom at this stage, because
the daemon will write out the new configuration file via the Python
configparser module and will only consider the [VirtualBMC] section as
well as any of the configuration keys listed in the VBMC_OPTIONS
list defined in the daemon’s code.
To help with the exploit, the
configparser
multiline syntax comes to the rescue: any lines following an assignment which
are indented will be accepted as part of the configuration value. When writing
the settings out to a new configuration file, these multiline settings will be
preserved. This is put to use in the example above, which contains a final
line myaccount ALL=.... This line will now appear along with the rest of the
configuration data in /etc/sudoers.d/config.
As a result, when the attacker now invokes sudo su -, a couple of sudoers
parsing errors will appear, but in the end, access is granted and a root shell
will be obtained by the attacker.
This approach of using a sudoers drop-in configuration file is just one of the
more obvious approaches that came to mind. There’s a lot of different ways
to exploit this, however, for example by overwriting shell scripts or script
snippets in /etc or /usr/bin and then waiting for a privileged process to
run them. This would be even easier, because shell scripts have less
strict syntax requirements compared to the sudoers configuration file. The
effect would not be immediate, however, like in the sudoers approach.
We offer a Python script for download, which
is a Proof-of-Concept (PoC) to reproduce the local root exploit in the context
of an arbitrary unprivileged user on the system, when vbmcd is running with
its default configuration. sudo needs to be installed, naturally, for the
exploit to work.
In general, the API offered by vbmcd on localhost is missing input
sanitization and authorization. Authorization seems only to be performed
indirectly via libvirt. In this context clients can also pass crafted
libvirt_uri parameters, for example, which seem to make it possible to let
the daemon connect to arbitrary URLs via SSH. There also is no isolation
between different users’ domain configurations, e.g. the “stop” command used
above can be issued for any domain configured by another user in the system.
To make this API safe, we believe there needs to be an ownership model for each domain’s configuration, a verification of the client’s credentials in some form (a UNIX domain socket would allow this more easily) and sanitization of all input parameters to avoid any unexpected side effects.
Since the daemon listens on an unprivileged port on localhost, other
unprivileged users can try to bind to this port first and provide a fake
vbmcd service. Since the API requests can also contain secret credentials,
this would pose a major local information leak. For safe operation, the API
would need to bind to a privileged port on localhost instead.
snapd Package ManagerIn 2019 we received a request to add the snapd package
manager to openSUSE, which involved a review of the
setuid-root program snap-confine. At the time we were
generally satisfied with the code quality and design of the program, but still
found a few low to medium severity security issues
and gave recommendations on how to improve the code in some spots. The
packagers have meanwhile been busy with other topics and we never saw
an updated openSUSE package containing the necessary changes, which is why we
closed the related bugs after a period of inactivity.
In August we received a follow-up request for addition of an
updated snapd package. We revisited the privileged components and again
provided feedback to upstream. This time
all remaining issues could be resolved and the new package has been allowed to
become part of openSUSE Tumbleweed. We are happy to see these old efforts not
going completely to waste, and welcome the possibility to use Snap packages on
openSUSE Tumbleweed in the future.
Again we hope we’ve been able to give you some additional insight into our efforts to maintain the security of SUSE distributions and open source software. We are looking forward to the next edition of the spotlight series, which will be published in about three months from now.
]]>InputPlumber is a utility for combining Linux input devices into virtual input devices. It is mostly used in the context of Linux gaming and is part of SteamOS.
An openSUSE community member packaged InputPlumber which required a review by the SUSE security team, as it contains a D-Bus system service. The first version of InputPlumber we reviewed was completely lacking client authentication, causing us to reject it. A follow-up version contained Polkit authentication, which turned out to be lacking in multiple regards. At this point we approached upstream with a detailed report and established coordinated disclosure. Starting with version v0.69.0 of InputPlumber most (but not all) of the issues in this report have been addressed. SteamOS also published new images for version 3.7.20 containing the fixes.
This report is based on InputPlumber release v0.67.0. The next section provides an overview of InputPlumber’s D-Bus service. Section 3 looks into the security issues in detail. Section 4 discusses the fixes we suggested to upstream. Section 5 looks into the upstream bugfixes to address the issues and aspects that remain unfixed. Section 6 covers the CVE assignments we did for the issues we found. Section 7 provides a summary of the coordinated disclosure process we followed for this report.
InputPlumber is implemented in Rust and the size of the code base is surprisingly high for this type of project, adding up to about 50,000 lines of code overall (not counting vendor code) and about 3,000 lines dedicated to the D-Bus API specifically.
The InputPlumber D-Bus service runs with full root privileges, offering the “org.shadowblip.InputManager” interface on the D-Bus system bus. Additionally various interfaces representing Linux input devices are provided by the daemon, like a keyboard interface. In summary the service provides around 90 different D-Bus properties and about 10 different interfaces on various objects exported by it. The Polkit policy lists over 100 different actions, controlling every aspect of the D-Bus API including read/write access to individual properties.
Initially we looked into InputPlumber version
v0.62.2. In this version there is no Polkit
authorization at all for the D-Bus interfaces. There are also no
restrictions in the configuration of the D-Bus service, allowing all users in
the system to connect to it, even low privilege user accounts like nobody.
We thought about reaching out to upstream already at this point, when we noticed that in InputPlumber version v0.63.0 (which was meanwhile published on GitHub) Polkit authentication had been added via commit 0a80f3d85. Thus we asked our community maintainer to update the package to at least that version for us to have another look.
Due to other priorities we only got around to taking a fresh look at the package at a later time, when the package had already been updated to version v0.67.0, on which this report is based.
Looking into this version we first discovered that the Polkit authentication was still not effective in the package build provided to us. The reason for this was that Polkit support was only a compile-time feature on Rust Cargo configuration level - which was disabled by default. We believe that in this version there is also no canonical way to enable the feature when using the Makefile found in the repository. For this reason we created our own build of InputPlumber and applied a patch to hard-enable the Polkit feature for testing.
In this custom package build of InputPlumber the Polkit authentication
triggered as expected. While looking into the implementation of the Polkit
authentication wrapper, however, we noticed that the Polkit
authentication logic uses the “unix-process” Polkit subject in an unsafe way.
It retrieves the caller’s PID from the D-Bus connection and passes this
information on to the Polkit daemon. This suffers from a race condition,
because the client can attempt to have its PID replaced by a privileged
process by the time polkitd gets around to actually look at the credentials
of the process.
This is a well-known issue when using the “unix-process” Polkit subject which was assigned CVE-2013-4288 in the past. For this reason the subject has been marked as deprecated in Polkit. The “unix-process” subject is seeing new use these days, however, when combined with the use of Linux PID file descriptors, which are not affected by the race condition.
In summary none of the versions of InputPlumber we looked into provided sufficient authentication, even if integrators would have managed to actually enable the Polkit layer in versions v0.63.0 and later. Thus all InputPlumber D-Bus methods can be considered accessible by all users in the system without authentication.
Considering the unprivileged access to the D-Bus methods provided by InputPlumber, the following two methods quickly caught our attention as being problematic:
CreateCompositeDevice(in s config_path)This method parses the provided input path as YAML to create a CompositeDevice configuration and suffers from the following issues:
/dev/zero
as input file, leading to memory exhaustion in InputPlumber)./root/.bash_history:
user $ gdbus call -y -d org.shadowblip.InputPlumber -o /org/shadowblip/InputPlumber/Manager \
-m org.shadowblip.InputManager.CreateCompositeDevice /root/.bash_history
Error: GDBus.Error:org.freedesktop.DBus.Error.Failed: Unable to deserialize: invalid type: string "cd /etc/polkit-1/rules.d/", expected struct CompositeDeviceConfig at line 2 column 1
The string cd /etc/polkit-1/rules.d is an entry from root’s history file
in this case.
CreateTargetDevice(in s kind)This method allows to create a virtual keyboard input device like this:
user $ gdbus call -y -d org.shadowblip.InputPlumber -o /org/shadowblip/InputPlumber/Manager \
-m org.shadowblip.InputManager.CreateTargetDevice keyboard
Once the virtual keyboard has been created, key presses can be injected into the active user session (login terminal or graphical desktop) like this:
user $ gdbus call -y -d org.shadowblip.InputPlumber -o /org/shadowblip/InputPlumber/devices/target/keyboard0 \
-m org.shadowblip.Input.Keyboard.SendKey KEY_R true
All supported key symbols are found in keyboard.rs.
Using this ability, any user in the system can inject input to an active
desktop session or the active login terminal screen, possibly leading to
arbitrary code execution in the context of the currently logged in user, if
any.
We suggested the following action items to upstream to improve the security of the InputPlumber D-Bus API:
inputplumber systemd service. By using settings
like ProtectSystem=full the service can be tightened to avoid any unexpected
side effects when things go wrong at the first line of defense.Upstream mostly followed our suggestions and fixed the issues as follows:
All of these fixes are contained in InputPlumber version v0.69.0 and later.
Upstream initially wanted to avoid breaking the D-Bus API by switching to file
descriptors instead of path names, as we suggested. We strongly recommended to
do this, however, to avoid various issues that can occur when clients pass
malicious file paths. An upstream developer then created a pull
request which introduces file descriptors in the API.
We provided feedback that this is going in the right direction, but suggested to
also perform checks on the file descriptors passed by clients to make sure they
refer to regular files and have no unusual open flags like O_PATH set.
At the time of publication of this report we noticed that the improvements of
the D-Bus API to use file descriptors have not been merged yet and are not
available in a release. Thus some aspects of the issues described in this
report remain unaddressed, although they are now at least protected by proper
Polkit authentication. Sensitive methods like CreateCompositeDevice also
require admin privileges to be called, thus
these are mostly defense-in-depth issues, or only relevant when integrators
or admins relax Polkit authentication requirements.
In agreement with upstream we performed the following CVE assignments corresponding to this report:
CVE-2025-66005: lack of authorization of the InputManager D-Bus interface in InputPlumber versions before v0.63.0 can lead to local Denial-of-Service, information leak or even privilege escalation in the context of the currently active user session.
CVE-2025-14338: Polkit authentication disabled by default and a race condition in the Polkit authorization check in versions before v0.69.0 can lead to the same issues as in CVE-2025-66005.
We informed upstream about the security issues on 2025-11-25 and offered coordinated disclosure. Upstream quickly confirmed the issues and agreed to follow coordinated disclosure. The developers discussed bugfixes with us, which they provided in public GitHub pull requests. This way the information about the issues was not fully private anymore, but we agreed to keep the full report private for a longer time, until new SteamOS images would be published, containing a fixed InputPlumber.
We found out only at the time of publication that not all aspects of the issues have been addressed in the bugfix release.
We want to thank the InputPlumber developers for their cooperation regarding this report.
| 2025-11-21 | We contacted one of the developers of InputPlumber, asking for the proper security contact for the project. |
| 2025-11-21 | We got a swift reply and learned that we reached the correct person for security reports already. |
| 2025-11-25 | We forwarded a detailed report outlining the issues in InputPlumber to upstream, offering coordinated disclosure. |
| 2025-11-25 | Upstream confirmed the issues and opted for coordinated disclosure. |
| 2025-12-08 | Upstream pointed us to a couple of public pull requests which should address the issues and asked us to review them. |
| 2025-12-10 | We provided feedback on the pull requests. The D-Bus API still used client-controlled paths at this point, and we suggested to turn them into file descriptors. We also pointed out that the issues were no longer fully private in light of the public pull requests, but suggested to keep the full report private for longer until an agreed upon date. |
| 2025-12-10 | We assigned CVEs for the issues and communicated them to upstream. |
| 2025-12-12 | Upstream informed us that they wanted to keep the original D-Bus API stable, but agreed to add an additional fix to use file descriptors anyway. |
| 2025-12-16 | We asked upstream whether they were able to agree on a general publication date for the report by now. |
| 2025-12-22 | Upstream pointed us to another public GitHub pull request introducing file descriptors in the D-Bus API. |
| 2025-12-22 | Upstream informed us that the publication date still needed further internal discussions and that they would get back to us. |
| 2025-12-23 | We provided feedback to upstream about the additional pull request. We generally agreed with the change but suggested to also check file descriptor type and flags on the service side, to avoid unexpected file descriptors being passed by clients. |
| 2025-12-27 | Upstream informed us that Valve was planning to publish new SteamOS images containing the InputPlumber fixes on January 9, which was agreed upon for general publication date of the full report. |
| 2025-01-09 | Upstream informed us about publication of the new SteamOS images, thanking us for our support. |
| 2025-01-09 | Publication of this report. |
Foomuuri is an nftables-based firewall manager for Linux. The project includes a D-Bus daemon which offers an API similar to firewalld. In early December an openSUSE community member asked us to review Foomuuri for addition to openSUSE Tumbleweed.
During the review we quickly noticed a lack of client authorization and input validation in the implementation of Foomuuri’s D-Bus service. We reported the issues to upstream and performed coordinated disclosure. Upstream published version 0.31 of Foomuuri on 2026-01-07 which contains bugfixes for the security issues.
The next section provides an overview of the Foomuuri D-Bus service. Section 3) discusses the security issues in detail. Section 4) provides an overview of the upstream bugfixes to address the issues. Section 5) looks into the CVEs which were assigned. Section 6) gives insight into the coordinated disclosure process which was established for these findings.
This report is based on Foomuuri release v0.29.
Foomuuri runs with full root privileges and registers a D-Bus interface under the name”fi.foobar.Foomuuri1”. Optionally a firewalld drop-in replacement interface is also registered under “org.fedoraproject.FirewallD1”. Both interfaces hook into the same logic, however, and there is no need to look at them separately.
There are only a few methods provided by the D-Bus interface: getting the list of available zones and managing the assignment of network interfaces to zones.
There is no authentication layer like Polkit present in the Foomuuri D-Bus service, and there are also no restrictions on D-Bus configuration level as to who is allowed to connect to the D-Bus interfaces provided.
As a result any local user, including low privilege service user accounts or
even nobody, can invoke the D-Bus interface and change the firewall
configuration. The only state which can be modified this way is the assignment
of interfaces to zones, but this is enough to weaken the firewall
configuration or to perform a limited Denial-of-Service.
Apart from the lack of access restrictions pointed out above, the input
parameters to the D-Bus methods are not carefully scrutinized. While the zone
input parameter is at least checked against currently configured
zones, no further checks are performed on the
interface parameter. This means that, e.g. via the “addInterface” D-Bus
method, arbitrary strings can be passed as interface name. There is also
intentionally no check if the specified name corresponds to an existing
network device in the system (to allow seamless coverage of network devices
even before they are added to the system).
One result from this can be log spoofing, since the interface name is
passed to logging functions unmodified. The string could contain control
characters or newlines, which can manipulate the log.
In DbusCommon.add_interface() the possibly
crafted interface name is added to the to-be-generated JSON configuration via
the out() method. While we did not verify whether this works in practice, a
local attacker could attempt to largely control the JSON configuration passed
to nftables, by skillfully embedding additional JSON configuration in the
interface parameter.
We were worried that this could even lead to arbitrary code execution by
abusing features of nftables like loading external files or plugin code, but
it turned out that there are no such features available in the nftables
configuration format.
umask used in Daemonize CodeFoomuuri contains optional support to daemonize itself. Normally this is done
by systemd and the code in question is not invoked. It contains
logic to set the daemon’s umask to 0, however, which is a bad
default, since applications or libraries which intend to foster user control of
the file mode of newly created files can pass modes like 0666 to open(),
rendering them world-writable.
Foomuuri does not contain any code paths that create new files, but the umask
setting is also inherited by child processes, for example. While we did not
think this was a tangible security issue in this form, we suggested to choose a
more conservative value here to prevent future issues.
We suggested the following fixes to upstream:
root only, maybe also to
members of a dedicated opt-in group. Alternatively Polkit could be used for
authentication of callers, which is more effort and complex, however.interface input parameter should be verified right from the
beginning of each D-Bus method to make sure that it does not contain
any whitespace or special characters and is not longer than IFNAMSIZ bytes
(which is currently 16 bytes on Linux).ProtectSystem=full to Foomuuri’s systemd services,
to prevent possible privilege escalation should anything go wrong at
the first line of defense.Upstream decided to implement Polkit authentication for Foomuuri’s D-Bus service and otherwise followed closely our suggestions:
interface parameter to prevent manipulation of the JSON configuration
data.umask used in the daemonize code
to a more conservative 0o022 setting, preventing world- or group-writable
files from coming into existence.ProtectSystem=full
directive to all Foomuuri systemd service units.All of the bugfixes are contained in version 0.31 of Foomuuri.
In agreement with upstream we assigned the following two CVEs corresponding to this report:
CVE-2025-67603: lack of client authorization allows arbitrary users to influence the firewall configuration (issue 3.1).
CVE-2025-67858: a crafted interface input parameter to D-Bus methods can
lead to integrity loss of the firewall configuration or further unspecified
impact by manipulating the JSON configuration passed to nft
(issue 3.2).
We reported these issues to the upstream developer on 2025-12-11, offering coordinated disclosure. We soon got a reply and discussed the details of the non-disclosure process. Upstream quickly shared patches with us for review and we agreed on the final patches already on 2025-12-19. In light of the approaching Christmas season we agreed on a publication date of 2026-01-07 for general disclosure.
We want to thank the upstream author for the prompt reaction and cooperation in fixing the issues.
| 2025-12-11 | We contacted the Foomuuri developer by email providing a detailed report about the D-Bus related findings and offered coordinated disclosure. |
| 2025-12-12 | The upstream author confirmed the issues, agreed to coordinated disclosure and asked us to assign CVEs the way we suggested them. 2026-01-07 was suggested for publication date. |
| 2025-12-15 | We discussed some additional technical details like the umask issue and the question of whether arbitrary code execution could result from the ability to control the JSON configuration passed to nft. |
| 2025-12-18 | Upstream shared with us a first version of patches for the issues we reported. The patches for minor issues and hardening were already published on GitHub at this point. |
| 2025-12-19 | We provided feedback on the patches, suggesting minor improvements. |
| 2025-12-19 | With the fixes ready we discussed whether earlier publication would make sense, but we agreed to stick to the date of 2026-01-07 to accommodate the Christmas holiday season. |
| 2026-01-07 | Upstream release v0.31 was published. |
| 2026-01-07 | Publication of this report. |
TLP is a utility for saving laptop battery power when running Linux (note: the TLP acronym has no special meaning). In version 1.9.0 of TLP a profiles daemon similar to GNOME’s power profiles daemon has been added to the project, providing a D-Bus API for controlling some of TLP’s settings.
Our SUSE TLP package maintainer asked us for a review of the changes contained in the new TLP release, leading us to discover issues in the Polkit authentication logic used in TLP’s profiles daemon, which allow a complete authentication bypass. While looking into the daemon we also found some additional security problems in the area of local Denial-of-Service (DoS).
We reported the issues to upstream in December and performed coordinated disclosure. TLP release 1.9.1 contains fixes for the issues described below. This report is based on TLP 1.9.0.
The next section provides a quick overview of the TLP power daemon. Section 3 discusses the security issues we discovered in detail. Section 4 looks into the CVEs we assigned. Section 5 provides a summary of the coordinated disclosure process we followed for these findings.
The new TLP power daemon is implemented in a Python script of moderate
size. The daemon runs with full root privileges and accepts
D-Bus client connections from arbitrary users. For authorization of clients a
Polkit policy defines a couple of actions which are
checked in the daemon’s _check_polkit_auth() function.
Some of these actions are allowed for local users in an active session without
providing further credentials, others require admin credentials.
The check_polkit_auth() function relies on Polkit’s
“unix-process” subject in an unsafe way. The function obtains the caller’s PID
and passes this information to the Polkit daemon for authorization, which is
inherently subject to a race condition: at the time the Polkit daemon looks up
the provided PID, the process can already have been replaced by a different
one with higher privileges than the D-Bus client actually has.
As a result of this, the Polkit authorization check in the TLP power daemon can be bypassed by local users, allowing them to arbitrarily control the power profile in use as well as the daemon’s log settings.
This is a well-known issue when using the “unix-process” Polkit subject which was assigned CVE-2013-4288 in the past. For this reason the subject has been marked as deprecated in Polkit. The “unix-process” subject is seeing new use these days, however, when combined with the use of Linux PID file descriptors, which are not affected by the race condition.
We suggested to upstream to switch to Polkit’s D-Bus “system bus name” subject instead, which is a robust way to authenticate D-Bus clients based on the UNIX domain socket the client uses to connect to the bus. This is what upstream did in commit 08aa9cd.
The D-Bus methods “HoldProfile” and “ReleaseProfile” can be used by locally logged-in users without admin authentication and allow to establish a “profile hold”, preventing the profile from being automatically switched until it is released again.
The “HoldProfile” method returns a cookie value to the caller which needs to be presented to the “ReleaseProfile” method again to release it. This cookie value is a simple integer which starts counting at zero and is incremented for each call to “HoldProfile”. This makes the cookie value predictable and allows other, unrelated users or applications to release an active profile hold by trying to guess the cookie value in use.
We suggested to upstream to make the cookie value unpredictable by generating a random number. This is what upstream did in commit a88002e.
cookie Parameter in “ReleaseProfile” Method Leads to Unhandled ExceptionAs described in the previous section, the “ReleaseProfile” D-Bus
method expects an integer cookie parameter as input.
The Python D-Bus framework used to implement the method allows clients to pass
non-integer types as cookie, however, which causes an exception to be thrown
in the daemon. This does not lead to the daemon exiting, however, since the
framework catches the exception.
The issue can be reproduced via the following command line:
user$ dbus-send --system --dest=org.freedesktop.UPower.PowerProfiles \
--type=method_call --print-reply /org/freedesktop/UPower/PowerProfiles \
org.freedesktop.UPower.PowerProfiles.ReleaseProfile string:test
Error org.freedesktop.DBus.Python.ValueError: Traceback (most recent call
last):
File "/usr/lib/python3.13/site-packages/dbus/service.py", line 712, in
_message_cb
retval = candidate_method(self, *args, **keywords)
File "/usr/sbin/tlp-pd", line 223, in ReleaseProfile
cookie = int(cookie)
ValueError: invalid literal for int() with base 10: dbus.String('test')
While this is not strictly a security issue, we still suggested to make the
daemon more robust by actively catching type mismatch issues for the cookie
input parameter. Upstream followed this suggestion and implemented it in the
same commit as above which introduces unpredictable
cookie values.
The profile hold mechanism described in section
3.2 allows local users in an active session
to create an unlimited number of profile holds without admin authentication.
This can lead to resource exhaustion in the TLP power daemon, since an integer
is entered into a Python dictionary along with arbitrary strings reason and
application_id which are also supplied by the client. This API thus
offers Denial-of-Service attack surface.
We found a similar issue in GNOME’s power profile daemon some years ago, but GNOME upstream disagreed with our analysis at the time, which is why SUSE distributions are applying a custom patch to limit the number parallel profile holds.
We asked upstream whether there are any valid use cases for supporting a large number of profile holds in parallel, and it turns out that the typical use case is only to support a single profile hold at any given time. Thus upstream agreed to restrict the number of profile holds to a maximum of 16, which is implemented in commit 6a637c9.
We assigned CVE-2025-67859 to track issue 3.1 (Polkit authentication bypass). Issues 3.2 (predictable cookie values) and 3.4 (unlimited number of profile holds) would formally also justify CVE assignments; their severity is low, however, and we agreed with upstream to focus on the main aspect of the Polkit authentication bypass.
We reached out to the upstream author on December 16 with details about the issues and offered coordinated disclosure. Upstream confirmed the issues and accepted coordinated disclosure. We discussed patches and further details over the course of the following two weeks. Due to the approaching Christmas holiday season we decided to set the general publication date to January 7.
We want to express our thanks to the TLP upstream author for the smooth cooperation in handling these issues.
| 2025-12-16 | We reached out to the upstream developer by email providing a detailed report and offered coordinated disclosure. |
| 2025-12-17 | We received a reply discussing details of the report. Coordinated disclosure was established with a preliminary publication date set to 2026-01-27. |
| 2025-12-20 | We received a set of patches from upstream for review. 2026-01-07 was suggested as new publication date. |
| 2025-12-23 | We provided positive feedback on the patches and agreed to the new publication date. We also pointed out the additional problem of the unlimited number of profile holds (issue 3.4). |
| 2025-12-25 | We received a follow-up patch from upstream limiting the number of profile holds. |
| 2025-12-29 | We reviewed the follow-up patch and provided positive feedback to upstream. |
| 2025-01-07 | Upstream published bugfix release 1.9.1 as planned. |
| 2025-01-07 | Publication of this report. |
Smb4KMountHelper::mount()
Smb4KMountHelper::unmount()
smb4k is a KDE desktop related utility which allows unprivileged mounting of Samba/CIFS network shares. The SUSE security team reviewed its privileged KAuth helper component already in 2017 which led to the discovery of CVE-2017-8422 (general KAuth authentication bypass) and CVE-2017-8849 (local root exploit via smb4k mount helper).
This September we were asked to reconsider smb4k for inclusion in openSUSE Tumbleweed. The resulting review showed that the mount helper still lacks input validation, is affected by race conditions and has a bug in its existing verification logic. This leads to local attack vectors which allow Denial-of-Service or even a local root exploit.
Many Linux distributions and also some BSDs are potentially affected by the issues described in this report. We offered coordinated disclosure to upstream and the maximum 90 days non-disclosure period was fully spent to arrive at a patch which addresses all the issues. This patch is found in commit 0dea60194a, which is part of the 4.0.5 bugfix release of smb4k.
The following section provides a short overview of the privileged mount helper. Section 3 looks into the problems found in the helper’s mount method. Section 4 in turn looks into the issues found in the helper’s unmount method. Section 5 contains further remarks on the helper’s code quality and security concerns. Section 6 discusses the fixes we suggested to upstream to address the issues. Section 7 gives details about the bugfix which was finally implemented by upstream. Section 8 suggests possible workarounds that can be applied to avoid the issues found in this report. Section 9 provides reproducers for the issues.
This report is based on smb4k release 4.0.4.
The problematic privileged mount helper component of smb4k is relatively small
and can be found in the file smb4kmounthelper.cpp. The
helper runs with full root privileges and implements two KAuth actions
accessible via D-Bus: mounting and unmounting a network share. Both actions
are allowed for local users in active sessions without authentication, based
on the Polkit yes setting.
Smb4KMountHelper::mount()The helper does not impose any restrictions on the target directory
where the desired Samba share will be mounted. This means the share can
also be mounted over /bin, for example. Should the client have control
over the contents of the network share, then this allows for a local root
exploit by placing crafted binaries e.g. for /bin/bash on the share, which
are bound to be executed by privileged processes at some point.
If the share’s content cannot be controlled by the attacker, then this serves as a local Denial-of-Service attack vector, as vital system programs will become inaccessible.
To fix this, we suggest to only allow mounting of network shares in a pre-defined location which is not controlled by unprivileged users.
mount.cifsThe client can specify arbitrary additional command line arguments in the
mh_options parameter, which will be passed to the mount.cifs
program. The command line constructed by the mount helper
looks like this:
/sbin/mount.cifs <URL> <mountpoint> <options>...
All of these arguments, except for the path to the mount.cifs program
itself, are actually controlled by the client. It is not the generic mount
program which is invoked here, otherwise the client could already perform
arbitrary mounts in the system. Instead the attacker is restricted to what the
special-purpose mount.cifs binary provides.
The mount.cifs program supports a plethora of mount
options. Investigating the effect of each one would go
beyond the scope of this report. There is one simple privilege escalation
vector, however: passing filemode=04777,uid=0 to the command line results in
every file on the network share mount receiving setuid-root permissions. If
the content of the network share is controlled by the attacker, then this can
easily be used to introduce an attacker-controlled setuid-root program into
the system. This would then allow for a local root exploit even if issue
3.1) would be fixed.
Other mount.cifs options like port=<port> could be used to direct the
kernel to a CIFS server controlled by the attacker itself, listening on an
unprivileged port on localhost. This way a local attacker could provide the
necessary crafted network share for executing the exploits described in this
report on its own, without relying on external network resources.
To fix this, we suggest to restrict the mh_options to a whitelist of allowed
parameters, and also verify the options’ values in case they can contain
problematic settings.
KRB5CCNAME Environment Variable Passed To mount.cifsThe client can provide an arbitrary path in the mh_krb5ticket parameter;
the mount helper will place this path into the KRB5CCNAME environment
variable for the mount.cifs child process. This is
to allow use of the client’s Kerberos credentials for mounting the network
share.
The client can pass a path pointing to file system locations normally not
accessible to it. In a multi-user scenario this would allow, for
example, to hijack another user’s Kerberos credentials, by passing a path to
the credentials cache of the other user. It might also lead to information
leaks of files like /etc/shadow, should mount.cifs output file content to
the system logs or on stderr (the output of which is returned to the client
via D-Bus).
Furthermore, this path could be used for file existence tests or for a local
Denial-of-Service attack (by pointing to special files like /dev/zero or a
named FIFO pipe).
To fix this, we recommend not to pass a path, but an already open file descriptor from the client to the helper, to avoid the opening of arbitrary files with root privileges.
Smb4KMountHelper::unmount()return Statement on Mount Path Verification FailureThis is similar to issue 3.1) above
regarding mounting. In smb4kmounthelper.cpp line
177 there is an if block that acts on the
situation when the mh_mountpoint path supplied by the client does not match
any of the available Samba mounts returned from
KMountPoint::currentMountPoints().
The problem is that this if block only sets an error message, but does not
actually terminate the function execution with return. This means the
verification is ineffective and local users can unmount arbitrary file systems
despite the check.
This is a major local Denial-of-Service attack vector, which can lead to a complete system outage. In some special contexts it might even allow information leaks or privilege escalation, when file system locations have been made inaccessible by mounting other file systems on top (we can imagine something like this e.g. in the context of container setups).
umountSimilar to issue 3.2) above, the privileged
helper forwards arbitrary command line parameters provided by the client in
mh_options to the command line of the umount program. This happens in
smb4kmounthelper.cpp line 187. Basically the umount
program will be invoked like this:
/sbin/umount <options>... <mount-point>
Assuming issue 4.1) would be fixed, the
<mount-point> parameter cannot be chosen arbitrarily by the client, but must
match an existing “cifs”, “smbfs” or “smb3” type mount path. As long as such a
mount path exists, the client can pass arbitrary additional mount points as
“options”, which will then be unmounted as well. This is a lighter variant of
issue 4.1), leading to local Denial-of-Service if the described pre-condition
is fulfilled.
Apart from this, umount offers various options that
can influence the way it operates. One option that sticks out is -N
--namespace ns, which causes the program to unmount the file system in an
arbitrary mount namespace. This could impact privileged processes, other
users’ containers or jailed processes.
To fix this, we suggest to restrict the mh_options to a whitelist of allowed
parameters.
KMountPoint::currentMountPoints()This is not directly an issue in smb4k itself, but an issue in the KIO
library which implements the KMountPoint API. During our
tests we used version v6.17.0 of this library.
The mount helper’s umount() function attempts to verify
the input path provided by the client by comparing it against current mounts
in the system as reported by the kernel. Only active “cifs”, “smbfs” and
“smb3” file system mounts are supposed to be unmounted. To this end the
current list of mounted file systems is obtained from
KMountPoint::currentMountPoints(KMountPoint::BasicInfoNeeded | KMountPoint::NeedMountOptions);
The implementation of currentMountPoints() relies on the libmount
library to retrieve a list of mount points. The
libmount library provides a proven implementation for safely parsing
files like /proc/self/mountinfo, which we reviewed ourselves a few years
ago and deemed robust. After safely obtaining the information from
libmount, the KIO library performs some actions on top, however, which
can lead to security relevant issues.
One minor issue is found in kmountpoint.cpp line 365, where
stat() is called on the target mount directory of each mount entry. This
potentially accesses untrusted paths, also from FUSE file systems, which could
in some cases cause a local Denial-of-Service if stat() blocks. Also, the
supposed mount point could be unmounted by the time the stat() call is
performed, allowing the path to point to an arbitrary file (also following
symbolic links), which would lead to incorrect information in the m_deviceID
field of the information returned by currentMountPoints().
Later on the code tries to “resolve GVFS mount points” in line
382. The resolveGvfsMountPoints()
function that implements this logic looks for mount
entries with “gvfsd-fuse” as source device name. For each of these mount
points the function will list the mount’s directory contents and look for
directory entries of the form <type>:<label>, where type refers to the
file system type that is expected to be found there. The function then
synthesizes additional mount entries from this information which will be
returned to the caller, appearing as fully-fledged regular mounts.
There are two problems with this. For one, these operations are all subject to
race conditions; the mount table entries can change at any time. Secondly,
there exists a common way for unprivileged users in Linux systems to create
mount points with arbitrary source device names. This is the fusermount
setuid-root utility, which is used for mounting FUSE file systems. Local users
can create a fake gvfsd-fuse mount point like this:
$ export _FUSE_COMMFD=0
$ mkdir $HOME/mnt
$ fusermount $HOME/mnt -ononempty,fsname=gvfsd-fuse
$ mount | tail -n1
gvfsd-fuse on /home/$USER/mnt type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)
The default FUSE configuration prevents the root user from accessing
non-root controlled FUSE file systems. To overcome this limitation, an
attacker can perform the following steps:
gvfsd-fuse mount like shown above.unmount() logic in smb4k’s mount helper.$HOME/mnt after currentMountPoints() obtained the
mount information from libmount, but before it calls
resolveGvfsMountPoints().cifs:mymount. These directories can already be placed
there in advance, of course.currentMountPoints() function will return a
synthesized entry to the mount helper which lists a CIFS mount in the
unprivileged user’s $HOME/mnt/cifs:mymount.Using this approach, the verification step in the mount helper’s
unmount() function can be bypassed even if issues
4.1) and
4.2) would be fixed.
There are further potential issues in the KMountPoint logic, e.g. in
finalizeCurrentMountPoint() the source device name is resolved if the
KMountPoint::NeedRealDeviceName flag is passed by the caller. This
provides another opportunity for unprivileged FUSE mounts with fake
source device names to influence the outcome, e.g. to perform
file existence tests or otherwise trick the caller of the KIO library.
Due to these problems, the information obtained from
currentMountPoints() currently cannot be used to base security related
decisions on. Generally root should not perform these additional
queries at all. The library could check for geteuid() == 0 to prevent
the execution of this dangerous logic in privileged contexts.
For unprivileged applications we could imagine the addition of a flag like
KMountPoint::AllowUnsafe, which opts in to the problematic behaviour. Only
applications that are aware of the potential problems would then pass this
flag.
When we reported this, KDE security at first stated that the problems
described in this section would only affect smb4k and no other users of the
KMountPoint API. We found it questionable to consider a library’s API secure
only based on its supposed current users. Beyond that, even unprivileged
processes using this API might fall victim to other users in the system
crafting gvfsd mount information. One could argue that there is an issue in
the fusermount utility to begin with. The KMountPoint API is explicitly
processing a FUSE-based file system, however, and thus it should be prepared
to deal with the peculiarities this entails.
When we pointed out our continued concern to KDE security, it was suggested that we create an upstream issue, or ideally provide a bugfix ourselves. While we are happy to help where we can, the issue at hand is a larger API design topic, and we believe it should be dealt with carefully by the responsible upstream developers, allowing them also to learn from this experience. For this reason we only created the upstream issue, as was suggested to us.
Even if all the other issues discussed in this section would be fixed, the
current mount helper code allows to unmount arbitrary Samba shares, no matter
if they have been originally mounted by smb4k itself (for the same user or a
different one), or by other components in the system (e.g. via a fixed entry
in /etc/fstab).
Similarly to issue 3.1) above, we suggest to restrict smb4k mounts to a pre-defined location not controlled by unprivileged users to address this issue.
mh_command Client ParameterBoth helper actions compare an arbitrary path supplied by the client in
mh_command to the trusted “mount” or “unmount” program path returned
from findMountExecutable() or findUmountExecutable(), respectively. This
is odd. It seems this comparison is a remnant from the attempted fix of
CVE-2017-8849. This is superfluous logic that increases the complexity of both
client and helper unnecessarily and can cause confusion, at best.
The helper should choose the trusted mount program on its own and stop
considering the mh_command parameter at all.
There is a redundant check for online network interfaces in smb4kmounthelper.cpp line 38 and line 205. This code should be placed into a separate function instead, to avoid code duplication and to increase readability.
This online check is also highly heuristic, and it might be possible for unprivileged users to influence its outcome e.g. by creating unprivileged pseudo network devices that appear to be online.
mount.cifs and umount Follow Symbolic LinksBoth mount.cifs and umount follow symbolic links in path arguments. This
means that even if the mount helper would try to verify a path pointing to a
client-controlled location, this could be replaced with a symbolic link
by the time the actual mount.cifs or umount utility runs, and the mount
logic would then operate on a completely different location than expected by
the helper.
Apart from the individual suggestions mentioned in the context of the issues above, we believe the range and severity of the issues uncovered shows that a major redesign of the mount helper utility is necessary to address all the problems in a robust way.
Here are some suggestions regarding a larger redesign:
/mounts/smb4k, only controlled by
root, should be used for these purposes. Some form of tracking which mount
belongs to which user would be needed (e.g. giving ownership of the mount to
the client that requested it). This is more like udisks
solves the problem of mounting devices on user request.mount.cifs or umount won’t work securely. A more abstract interface with
well-defined settings for mounting or unmounting would help to restrict the
degrees of freedom that a client has. This would also improve the decoupling
of the helper’s interface from the concrete implementation, this way the
helper could e.g. change the implementation to call the mount() and
umount() system calls directly, instead of going through the mount
utilities.During the course of a month we discussed various versions of patches with the smb4k upstream developer, until we arrived at a workable patch just in time for publication of this report after the 90 days maximum embargo period we offered. The main aspects of the bugfix are as follows:
mount and unmount the options passed by the client are now more
closely scrutinized, and only settings present in a whitelist of options are
allowed anymore.filemode mount option, which is still basically supported, is now
checked to make sure no special file bits are present.uid and gid mount options can only be set to the UID/GID of the
caller, not to arbitrary IDs anymore./run/smb4k. This way, unprivileged users can no longer place symlinks in
the mount destination paths. Mounts are placed in per-UID subdirectories
such that different clients cannot influence each other’s mounts anymore.KMountPoint API is no longer used and has been replaced by
Qt’s QStorageInfo API. Formally the investigation of existing mount points
would no longer be necessary at all with the trusted mount tree location,
but the upstream developer preferred to keep this extra verification step
for the time being.We want to express our thanks to Alexander Reinholdt, the smb4k upstream developer, for cooperating with us and finishing the patch in time for publication. This way a series of long-standing issues in smb4k could finally be addressed.
If the upstream bugfix cannot be used right away, the following suggestions can be considered to remove the attack surface described in this report:
auth_admin. This way the problematic logic can only be
reached by already privileged users. This contradicts the original purpose of
smb4k, however, to allow unprivileged mounts and unmounts of network shares.smb4k. Coupled with a security disclaimer, this would allow
users that really want to use this feature to opt-in.The KAuth D-Bus interface cannot easily be invoked via utilities like gdbus,
because it expects a serialized QVariantMap as input. We offer two C++
programs which can be used to perform standalone tests of smb4k’s mount helper
API for the purposes of reproducing the attack vectors described in this
report, smb4k_mount.cpp and
smb4k_unmount.cpp. There are comments in the
source code of the reproducers that explain how to compile and use them.
Formally the findings in this report could justify a large count of CVEs, but we decided to condense them into the two main aspects that result from the issues:
When the end of the 90 days maximum non-disclosure period we offered upstream approached, due to lack of feedback from KDE Security, we assigned these CVEs as we originally suggested them to upstream.
We reached out to KDE security on September 11 and shared the full details about the issues described in this report, offering coordinated disclosure. For nearly the first two months of the maximum 90 days non-disclosure period, we had difficulties getting clear answers from KDE security about the expected publication date, whether they acknowledged the findings or even whether they wanted to practice coordinated disclosure at all.
We only saw some visible progress at the beginning of November, when the smb4k upstream developer joined the discussion and started developing bugfixes. The progress remained slow, however, due to limited resources on the end of the developer. Still, from this point onwards the discussion turned out helpful and cooperative, and we could finally see that the non-disclosure time was actually being put to use. We managed to agree on a bugfix that addresses all the issues only less than a week before the 90 days maximum embargo period would be reached.
In summary, we are not completely happy about how the coordinated disclosure developed in this case. We perceived an unwillingness on the end of KDE security to communicate and to help in coordinating the disclosure. We believe the issue could have been fixed faster by suggesting a workaround to users and by developing a bugfix in the open, with the help of the rest of the community.
| 2025-09-11 | We forwarded our report to security@kde.org, offering coordinated disclosure. |
| 2025-09-17 | We received acknowledgement of receipt from KDE security. |
| 2025-09-29 | Not having heard anything else from upstream, we asked at least for a confirmation of the issues described in the report and a formal decision whether coordinated disclosure was desired. We asked to get feedback until October 2, lest we would publish the information on our end. |
| 2025-10-01 | We got a reply from KDE security that they were working on the issue, without answering our questions. We replied again and tried to clarify that we did not intend to put time pressure on upstream, but would like to clearly setup the coordinated disclosure process. |
| 2025-10-02 | We got a short reply that they could not give us an expected publication date, repeating again that they were working on the issue. Our questions pertaining the process still remained unanswered. We once more explained that we would like to be involved in reviewing potential bugfixes where we could offer our help, and that we would like to avoid non-disclosure time passing without any visible progress. |
| 2025-10-07 | KDE security informed us that the fix was moving forward without giving further details. |
| 2025-11-07 | The smb4k developer, Alexander Reinholdt, contacted us directly sharing a first batch of suggested bugfixes. |
| 2025-11-12 | We provided detailed feedback on the security relevant part of the patch, pointing out various problems that remained, and new problems that got introduced. |
| 2025-11-12 | KDE security chimed in about the KMountPoint topic, stating that smb4k would be the only privileged component using this API. |
| 2025-11-13 | We replied to KDE security explaining in more detail the remaining concerns we had regarding the KMountPoint API. |
| 2025-11-16 | The smb4k developer thanked us for the review of the patch, and sent back detailed comments on our input. He told us he would be working on a follow-up patch set. |
| 2025-11-26 | The smb4k developer informed us that it would take still more time for him to provide the improved version of the patch. |
| 2025-11-26 | We thanked the developer for his continued effort, but also reminded all participants that the end of the 90 days maximum non-disclosure period we offered was approaching in two weeks. We suggested the alternative of publishing a temporary workaround instead (like increasing authentication requirements), should a full bugfix be out of reach within the remaining time. We also suggested to involve the distros mailing list at this time, to give other Linux and BSD distributions a chance to prepare before general publication of the report. |
| 2025-11-27 | On the topic of the KMountPoint API, KDE security clarified that they ideally would like a merge request from us addressing our concerns. |
| 2025-11-28 | We assigned the CVEs the way we initially suggested them to upstream, to provide them as additional information to the distros mailing list. We also shared the CVEs with upstream. |
| 2025-11-30 | The upstream developer shared an improved patch set with us. |
| 2025-12-01 | We sent another round of comments back to the upstream developer. The new patch was still lacking in a number of areas. |
| 2025-12-01 | We forwarded a draft of this report to the distros mailing list, announcing publication of the issues on 2025-12-10. We pointed out that no proper bugfix was available for sharing at this time. |
| 2025-12-03 | We received yet another version of the suggested patch from the upstream developer. |
| 2025-12-04 | This time we found no remaining security issues, agreed on the patch, but still commented on a couple of quality and style aspects. |
| 2025-12-04 | We forwarded the bugfix from the upstream developer to the distros mailing list. |
| 2025-12-05 | We asked the upstream developer to publish a bugfix release on 2025-12-10, which he agreed upon. |
| 2025-12-10 | Upstream published the bugfix release 4.0.5 as planned. |
| 2025-12-10 | Publication of this report. |