• 1) Introduction
• 2) Insecure Polkit Rule
• 3) Bugfix
• 4) CVE Assignment
• 5) Timeline
• 6) References

1) Introduction

PortProtonQt is a GUI application to simplify launching of Windows games on Linux. A review of a custom Polkit rule installed by PortProtonQt uncovered an attack vector which allows arbitrary local users to modify NetworkManager connections or UDisks2 mounts.

This report is based on version 1.3.0 of PortProtonQt. A bugfix is available in the newly released version 1.3.1.

2) Insecure Polkit Rule

PortProtonQt installs a Polkit rules file ru.linux_gaming.PortProtonQt.rules containing the following logic:

var cmd_line = polkit.spawn(["ps", "-o", "args=", "-p", String(subject.pid)]);
var ppid = polkit.spawn(["ps", "-o", "ppid=", "-p", String(subject.pid)]).trim();
var parent_cmd_line = "";
if (ppid) {
    parent_cmd_line = polkit.spawn(["ps", "-o", "args=", "-p", ppid]);
}
var is_ppqt_call = cmd_line.includes("ppqtos") || parent_cmd_line.includes("ppqtos");

if (( action.id === "org.freedesktop.NetworkManager.settings.modify.system" ||
        action.id == "org.freedesktop.udisks2.filesystem-mount-system" ||
        action.id == "org.freedesktop.udisks2.filesystem-mount-other-seat" ||
        action.id == "org.freedesktop.udisks2.filesystem-unmount-others" ) && is_ppqt_call) {
    return polkit.Result.YES;
}

The code inspects the requesting process’s command line as reported by the ps utility, aiming to grant additional privileges to the ppqtos program. This is on one hand subject to race conditions, because the PID used by the requestor can be recycled or replaced by other programs by the time the Polkit rule runs. On the other hand, the process command line can be influenced arbitrarily to fake a ppqtos process.

We developed a simple shell script reproducer which shows that the exploitation of this vulnerability is simple and always succeeds. The vulnerability allows arbitrary local users to meddle with the network settings via NetworkManager and mount/unmount file systems via udisks. We could not spot a full local root exploit in that, although it is getting close. The impact is mostly Denial-of-Service and system integrity:

• arbitrary block devices can be mounted (but not in arbitrary locations, only under /run/media).
• arbitrary block devices can be unmounted (unless in use, but independent of their mount location).
• arbitrary NetworkManager connections can be removed and created, violating network integrity.

3) Bugfix

Upstream fixed the issue in commit f0ab40a2d which is part of a 1.3.1 bugfix release. Upstream followed our suggestion to allow these extra Polkit actions only for users in an active local session which are members of a dedicated portprotonqt group. This way the authentication bypass is restricted to interactive users that opt-in to using this feature.

The issue was introduced in PortProtonQt version 0.1.12 via commit 71a8ebd89.

4) CVE Assignment

In agreement with upstream we assigned CVE-2026-59676 to track this issue.

5) Timeline

6) References

• PortProtonQt GitHub project
• PortProtonQt 1.3.1 bugfix release
• openSUSE review bug for PortProtonQT Polkit rule
• Reproducer for the issue

• 1) Introduction
• 2) Design Overview
• 3) Security Issues
  • 3.1) Local File Deletion Attack Vector in rm_rf() (CVE-2026-59676)
  • 3.2) Process Kill Attack Vector in killall() (CVE-2026-59677)
• 4) Remaining Concerns
• 5) CVE Assignments
• 6) Timeline
• 7) References
• 8) Change History

1) Introduction

The seunshare program is part of the SELinux “sandbox” feature, which is used to confine untrusted programs using Linux mount namespaces and restrictive SELinux policies. The program is designed to be installed with setuid-root privileges, accessible to all users in the system.

We have been asked to review the program’s security with the intention of assigning the setuid bit to it on SUSE distributions in the future. Fedora Linux already ships this program with setuid-root enabled; other SELinux-enabled Linux distributions may do so as well.

During our review of the utility’s code in version 3.10 of the SELinux userspace utilities we identified two local Denial-of-Service attack vectors, which will be described in detail in the following sections. Upstream independently fixed these issues in version 3.11, without clearly marking them as security issues, however.

The rest of this report is based on version 3.10 of the codebase of seunshare.

2) Design Overview

The seunshare program is relatively small, consisting of about 1,000 lines of C code. The elevated root privileges are primarily needed to setup a custom mount namespace for the sandbox environment.

The program accepts a range of command line arguments which, among others, allow to request dedicated directories to be used for the following paths inside the sandbox:

• the user’s home directory.
• the /tmp directory.
• the /run/user/<uid> directory.

For the /run and /tmp directories, the source paths specified by the user are copied into a random temporary directory in the initial mount namespace under /tmp/.sandbox-<label>-XXXXXX using the rsync program. These directories are then bind-mounted into the sandbox’s mount namespace to appear at the expected locations.

A lot of code in seunshare is concerned with securely maintaining these temporary directories. To allow the sandbox environment to modify the directory contents, seunshare assigns group write permissions for the real group ID of the calling user, as shown in this example:

drwxrwx--T. 2 root user 80 Jul  8 16:11 /tmp/.sandbox-user-OaxmUp/

To safely access user-provided paths, the program flips its filesystem UID to the real UID of the calling user and back to root, as needed.

3) Security Issues

Since seunshare is supposed to run on SELinux-enabled systems, it is important to understand what kind of privilege escalation can be achieved when vulnerabilities are exploited in a setuid-root binary like this. Many SELinux-enabled systems, such as Fedora and openSUSE, ship with the “targeted” SELinux policy by default. This policy is focused on confining well-known system services, but assigns an unconfined SELinux context to interactive users by default to achieve a balance between security and usability.

There is currently no domain transition from the unconfined domain to the more restricted seunshare_t defined in the SELinux policy for seunshare. This means the execution of seunshare continues in the unconfined domain. Thus in the context of attacks carried out by interactive users, the impact of the vulnerabilities below will be a root-like privilege escalation despite the system running in SELinux enforced mode.

3.1) Local File Deletion Attack Vector in rm_rf() (CVE-2026-59676)

The function rm_rf() is called at the end of the utility’s execution to recursively remove temporary directory trees. While a comment in the function suggests that no symbolic links would be followed by this routine, the reality is that the openat() system call is lacking the O_NOFOLLOW flag. This creates a race condition during the recursion of the rm_rf() function:

• first an fstatat() is performed for directory contents obtained from readdir() to safely determine whether an entry refers to a sub-directory.
• when a directory is encountered the unsafe openat() happens, allowing the unprivileged user to replace the directory entry by a symbolic link in the meantime. While the O_DIRECTORY flag is passed to openat(), symbolic links in the target are still followed, as long as they point to a directory.

When the user calling seunshare is running in the unconfined SELinux domain, arbitrary root-owned files can be deleted this way. The vulnerability does not allow to delete arbitrary files of other users, however, because seunshare drops all capabilities before calling rm_rf(). This leaves the process in a somewhat strange state of privilege: it can no longer override discretionary access control (DAC) but it is still allowed to operate on files owned by the filesystem-uid of the privileged process, which is 0 during the invocation of rm_rf().

We developed a reproducer for this issue, which succeeds in executing the exploit quickly after some fine tuning of the timing for the target system. We verified that the reproducer works on current openSUSE Tumbleweed with policycoreutils 3.10 and the setuid-root bit enabled on seunshare. It does not work on current Fedora 44, as it seems Fedora backported a patch to fix this issue (it passes O_NOFOLLOW to the openat() call in question).

Upstream fixed this issue in commit 38f0a4d9a which is part of of the 3.11 upstream release.

3.2) Process Kill Attack Vector in killall() (CVE-2026-59677)

seunshare offers --kill and -Z switches as documented in its man page:

-k --kill
       Kill all processes with matching MCS level

-Z context
       Use alternate SELinux context while running the executable

Both switches combined cause the killall() function to kill all processes running with the user-provided SELinux context. This does not fully work for arbitrary target processes due to SELinux access control; however, if the calling user is running in unconfined context (as explained previously) it allows to kill e.g. root-owned processes running also in unconfined context. Once the algorithm reaches its own PID (if the context matches), it kills itself, thus it is possible that only a certain range of PIDs can be killed this way depending on the PID selection order of the algorithm in killall().

We have been able to reproduce the issue both on openSUSE and on Fedora 44 using a command line like this:

seunshare --kill -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 -t ~/some-dir/ -- /usr/bin/true

Upstream fixed this issue by dropping the --kill switch and the killall() function in commit 572db2fa.

4) Remaining Concerns

The code of seunshare has seen major changes between version 3.10 and 3.11 of the SELinux userspace utilities. The new version of the program improves on various aspects of the code; generally the code shows awareness of various filesystem-related security concerns that are relevant for setuid-root binaries. Still a number of concerns remain:

• Data which is modified in temporary directories within the sandbox is transparently copied back into the calling user’s source directory via rsync. Since the program is untrusted it can potentially create all kinds of dangerous files, which will now reside e.g. in the user’s regular home directory and could lead to security issues at a later time when accessed without care.
• The code flips the filesystem UID a lot to temporarily drop root privileges for file operations. This logic is hard to follow in parts and leaves the process in an unusual state of privilege, as the effective UID is still 0; during the first stages of the program it also still has all capabilities. Due to the filesystem UID being set to the real user’s UID, file operations are carried out using the calling user’s lower privileges, however. From a design point of view it would be preferable to let the process operate in an unprivileged state by default (effective UID and GID set to the real UID and GID). Privileges could then be raised for the few operations that actually need root privileges.
• The code currently lacks some common security precautions for setuid-root programs:
  • while a new environment variable block is set up to execute the untrusted target program, the privileged parent process keeps the untrusted environment variables of the calling user in place. These are also inherited to tools like rsync that are invoked for the purposes of setting up the sandbox. While this is not an issue at the moment, it could turn into a security issue at a later time when the code changes.
  • the umask() of the process is also kept unchanged, inheriting whatever the unprivileged parent process configured. This can cause files to receive world-readable or world-writable bits leading to unexpected attack vectors.

5) CVE Assignments

We approached the upstream SELinux userspace utilities developers and suggested to assign CVEs for the two issues discussed above. Upstream informed us that they don’t take care of CVE assignment themselves, however. Since Red Hat developers are also involved with upstream development, we were waiting for an agreement on who will assign CVEs to avoid duplicates. On 2026-07-17, after the initial publication of this report, we received a response that there is no intention by RedHat developers to assign CVEs. As a result we assigned CVEs on our end as documented in the updated blog post.

6) Timeline

7) References

• SElinux userspace utilities bugfix release 3.11
• SELinux userspace utilities Github project
• vulnerable seunshare code in upstream release 3.10
• Reproducer for the file delete issue

8) Change History

• 1) Introduction
• 2) Overview of the qSnapper D-Bus Service
• 3) Security Issues
  • 3.1) Weak Polkit Authentication Check is Subject to Race Condition (CVE-2026-41045)
  • 3.2) Path Traversal via configName Parameter (CVE-2026-41046)
  • 3.3) Information Leak via “diff” Methods (CVE-2026-41047)
  • 3.4) Caching of Authentication allows Authentication Bypass (CVE-2026-41048, CVE-2026-41049)
  • 3.5) Defense-in-Depth Issues when Restoring Arbitrary Files
  • 3.6) Other Issues
• 4) Upstream Bugfixes
• 5) Disclosure Process
• 6) Timeline
• 7) References
• Change History

1) Introduction

qSnapper is a GUI frontend for the snapper utility for managing Btrfs filesystem snapshots. In April we received a review request for qSnapper, because it contains a privileged D-Bus service and Polkit policies.

Normally, Btrfs snapshots can only be managed with root privileges. qSnapper aims to provide more user-friendly and fine-grained access to snapshot management features, based on a privileged daemon which utilizes D-Bus and Polkit. Our review of the service uncovered various security issues, which led to a longer coordinated disclosure to allow upstream to develop bugfixes, which are part of upstream release 1.3.3.

The full details of the security issues will be covered in the sections below. The original review was performed on qSnapper release 1.1.3. Since bigger upstream changes appeared in the meantime this report is based on qSnapper release 1.3.2, however.

2) Overview of the qSnapper D-Bus Service

The qSnapper project contains a daemon named qsnapper-dbus-service, which runs with full root privileges. The daemon provides the D-Bus interface “com.presire.qsnapper.Operations” on the system bus; some of its methods are provided to arbitrary users in the system without authentication, while the majority of them is protected by Polkit authentication checks. The implementation of the various D-Bus methods offered by the service is found in snapshotoperations.cpp. All of the security issues outlined below are located in this compilation unit.

3) Security Issues

3.1) Weak Polkit Authentication Check is Subject to Race Condition (CVE-2026-41045)

The SnapshotOperations::checkAuthorization() function uses Polkit’s UnixProcess subject in an unsafe way to authenticate clients. The code obtains the client’s PID from the active D-Bus connection, which leads to a race condition. At the time the Polkit daemon (polkitd) checks the provided PID, the process in question can already have been replaced by another, privileged process. This is a well-known class of Polkit authentication bypasses which was assigned CVE-2013-4288.

In effect this means that clients may be able to bypass all Polkit authentication checks performed by qSnapper, although the attack is somewhat complex and might need multiple attempts to succeed. There is nothing stopping a local attacker from doing that, however. In combination with the configuration path traversal in D-Bus methods like WriteSnapperConfig() described below, this can be used to achieve a full local root exploit.

To fix this, we suggested to use Polkit’s SystemBusName subject instead. With this subject, the D-Bus daemon obtains the client’s UID in a race-free fashion from the UNIX domain socket the client used to connect, and polkitd cannot be fooled by recycled PIDs.

3.2) Path Traversal via configName Parameter (CVE-2026-41046)

All the D-Bus methods accepting a configName parameter (that is nearly all of them) suffer from a path traversal vulnerability. This string parameter is directly passed to snapper::Snapper(), which is part of the libsnapper API, without checking its safety. libsnapper expects a basename here to look up a configuration file in /etc/snapper/configs. In the context of qSnapper this string can contain additional path components like ../../path/to/crafted.cfg. This allows clients to use arbitrary configuration files as input to libsnapper.

When looking at the writeSnapperConfig() D-Bus method, which requires admin authentication, this path traversal allows to write largely attacker-controlled data to arbitrary locations. Combined with the Polkit authentication bypass described earlier in section 3.1, this would allow for a full local root exploit.

In case of other D-Bus methods which use the “list-snapshots” Polkit action, the path traversal is also accessible to locally logged-in users without any authentication. Luckily the libsnapper configuration file format offers no features that lead to a trivial local root exploit in this context. The impact of the vulnerability can be any of the following, however:

• local Denial-of-Service (DoS): by pointing libsnapper to a special file like /dev/zero, the daemon will consume the maximum amount of memory and be killed by the kernel. By pointing libsnapper to a named FIFO special file, the daemon will block indefinitely.
• information leak from parsing of private files: by pointing libsnapper to a private file like /etc/shadow, libsnapper will parse the sensitive data from the file as configuration data. If any logging features are active and the logs can be accessed by unprivileged users, then private data from such a file might leak into the unprivileged context. We are not aware of such an information leak in default installations, however.
• by providing crafted configuration data further attacks can be carried out:
  • SUBVOLUME can be pointed to arbitrary mounts in the system. Luckily libsnapper is conservative in its file operations here, and quite strictly verifies the validity of this path; it verifies if it is really a mount point and is backed by the expected block device and file system etc.
  • ALLOW_USERS and ALLOW_GROUPS can be set to arbitrary users and groups, allowing them officially to control the Snapper configuration.
  • The SYNC_ACL setting causes libsnapper to apply ACL entries to the .snapshots directory of the volume path, granting the users and groups from ALLOW_USERS and ALLOW_GROUPS to access the snapshot data. Thus this is a major local information leak.

libsnapper is using different backends depending on the file system type. Different code is used for each backend, which means that the exploitability of some aspects of the vulnerability depends on which backend is used. On openSUSE only the Btrfs and LVM thin volume backends are compiled-in by default, which only offer little additional attack surface.

To fix the issue, we suggested to upstream to verify the configName parameter in all cases and reject it if any / or .. components are found in it.

3.3) Information Leak via “diff” Methods (CVE-2026-41047)

The Polkit action “list-snapshots” is allowed for locally logged-in users without authentication, and is used by multiple qSnapper D-Bus methods which are likely considered “read-only” operations not harmful to the system. In version 1.1.3 of qSnapper the following methods are relying on this Polkit action:

• ListSnapshots()
• GetFileChanges()
• GetFileDiffAndDetails()

In version 1.3.2 of qSnapper these additional methods are using the action:

• GetFileChangesBetween()
• GetFileDiffBetween()

These methods allow to obtain information about metadata changes of arbitrary files between snapshots or between snapshots and the live filesystem. The newer GetFileDiffBetween() method even offers full file content diff output. These are major local information leaks, since unprivileged users can get a diff e.g. of the /etc/shadow file between different system states, or changes from root’s home directory which could leak sensitive data like passwords or private keys.

To fix this, we suggested to upstream that all methods providing non-public information get restricted by auth_admin Polkit checks. Alternatively, a check could be implemented whether the files to be diffed are normally accessible to the caller by using checks similar to the access() system call; such an approach would likely be rather complex and error-prone, however.

3.4) Caching of Authentication allows Authentication Bypass (CVE-2026-41048, CVE-2026-41049)

In version 1.2.1 of qSnapper an m_authenticated flag was introduced to the daemon’s code, which caches authentication once a client has passed certain Polkit action authentication checks. This cached authentication is shared between the methods DeleteSnapshot(), RestoreFiles() and RestoreFilesDirect(). There are two issues with this approach:

• DeleteSnapshot() uses the “delete-snapshot” action, while the other methods use the “rollback-snapshot” action. If a caller can authenticate for “delete-snapshot” then it is also implicitly authenticated for “rollback-snapshot” and vice versa. This is not how Polkit is intended to be used. If a system administrator decides to relax the authentication requirement for “delete-snapshot”, then this automatically implies the “rollback-snapshot” action now, which are two very different impacts to the system. We assigned CVE-2026-41048 for this aspect of the issue.
• The implementation of the caching logic assumes that a single interactive client is talking to the daemon. In fact, arbitrary users can invoke these methods. If a legitimate client is authenticated for one of the affected actions once, then arbitrary other users like nobody are now also considered authenticated and Polkit will not be invoked anymore. This authentication bypass allows for a full local root exploit in the context of the RestoreFiles() methods, as outlined below in section 3.6. We assigned CVE-2026-41049 for this aspect of the issue.

We suggested to upstream to drop this form of authentication caching, or alternatively implement an authentication cache tied to each user and each Polkit action in question to avoid the issues.

3.5) Defense-in-Depth Issues when Restoring Arbitrary Files

This section discusses Defense-in-Depth issues which remain once all the more tangible issues discussed above are fixed. The restoreFiles() D-Bus method accepts arbitrary filePaths as parameter to be restored from a version found in a snapshot. Clients need to authenticate as an administrator to do this, so there is no direct attack surface. Let’s consider the path /var/lib/colord/mapping.db to be restored, however:

# On openSUSE Tumbleweed this directory is owned and writable by `colord`
$ ls -lh /var/lib/colord
drwxr-xr-x 3 colord colord 4.0K Mar 6 2024 .

At the time the qSnapper service performs the chown() system call, the colord service user can stage a symlink attack in the colord directory and cause arbitrary files in the system to receive colord ownership, allowing a colord to root exploit. A similar issue affects the copyRegularFile() function, where a file on the live file system is newly created.

This issue is hard to fix, given the many different file system situations that the restore operation can end up in. The basic algorithm to address the problem would need to use low-level system calls like openat(), fchown() and fstatat() to safely traverse file system paths and inspect any symbolic links on the way. Given the complexity of the bugfix and limited impact, we agreed with the upstream author that this fix does not need to be prepared during the coordinated disclosure period but can be developed in the open afterwards.

Given the amount of front-line security issues already found in qSnapper in the course of this review, we refrained from assigning a dedicated CVE for these Defense-in-Depth issues in this case.

3.6) Other Issues

This section covers a number of other issues that are not fully-fledged security issues, but still represent weaknesses or possible hardenings for the qSnapper implementation.

• the D-Bus method RestoreFiles() implements complex file operations to rollback changes of a file path to the state found in a snapshot. These file operations allow authenticated clients to achieve nearly arbitrary file operations:
  • recursive deletion of arbitrary paths
  • copy of arbitrary files to arbitrary locations
  • change of ownership of files to arbitrary users
  • change of the file mode to arbitrary values

  This is because the method is not verifying whether the claimed file exists in the snapshot in the first place and whether the filePaths contain any ../ directory components to escape the snapshot directory. While this method is protected by Polkit’s auth_admin setting, any D-Bus method should be written conservatively and in such a way that the intended purpose of the method cannot be bypassed. The very similar method RestoreFilesDirect() has the same issues and also contains a lot of duplicate code which should be merged with the other method’s code.

• the Quit() method can be called by anyone in the system without authentication. This is kind of a local DoS against an active qSnapper daemon in use by other users in the system.
• the logfile created in /var/log/qSnapper will be world-readable, which could leak sensitive information. For hardening purposes it could be made private to root.

4) Upstream Bugfixes

The upstream author closely followed our suggestions to fix the security issues described in this report. Version 1.3.3 of qSnapper contains the following bugfixes:

• commit a6caf538 addresses the following issues:
  • the Polkit UnixProcess subject is replaced by the SystemBusName subject to avoid the race condition during authentication (issue 3.1).
  • the configName parameter in all D-Bus methods is now carefully verified and rejected if it allows path traversal (issue 3.2).
  • the authentication caching is removed (issue 3.4).
  • the RestoreFiles methods reject path traversal attempts (see section 3.6).
• commit f375b74c addresses the following issues:
  • a new view-diff Polkit action is introduced to generate file diffs which requires auth_admin authentication to prevent information leaks (issue 3.3).
  • the unauthenticated Quit D-Bus method was dropped (see section 3.6).
  • log files are now created without world-readable bit (see section 3.6).

The more complex defense-in-depth issues outlined in section 3.5 have been addressed in the open later on and are contained in release v1.3.4.

5) Disclosure Process

Once we established contact with the upstream author, we had a very constructive discussion of the coordinated disclosure process. Upstream quickly acknowledged the issues, opted for coordinated disclosure and communicated a time schedule when bugfixes were expected to be available for review and when a bugfix release of qSnapper would be published. When we agreed on the final bugfixes in the middle of May, we agreed on choosing an earlier publication date than originally intended.

We want to thank the upstream author for handling this report in a very professional fashion and for greatly improving the security and robustness of qSnapper.

6) Timeline

7) References

• qSnapper GitHub repository
• qSnapper 1.3.3 bugfix release
• openSUSE review bug for qSnapper

Change History

• Introduction
• Review Summary
• Disk Space Exhaustion Issue
• Upstream Report
• CVE Assignment
• Timeline
• References

Introduction

malcontent is a parental control system for the GNOME desktop environment which allows to restrict access to adult Internet content and to keep track of and restrict the amount of screen time for children. As part of the GNOME 50 version update malcontent 0.14.0 was packaged for openSUSE, triggering a review of changes in the package’s D-Bus methods and Polkit actions.

During this review we identified a local disk space exhaustion attack vector via one of the newly added D-Bus methods. There is currently no upstream bugfix available for the issue. The full details about the issue and communication with upstream will be provided in the following sections.

Review Summary

The complexity of malcontent increased a lot compared to the last time we looked into it. There now exist three different malcontent D-Bus daemons utilizing three different service user accounts and some additional daemons not providing D-Bus interfaces on top of that.

Some parts of the user tracking in malcontent suffer from race conditions. We believe this is acceptable, given that parental controls don’t need to be strong security boundaries; it is sufficient if the target audience (children) is not able to bypass the parental controls.

Disk Space Exhaustion Issue

The newly introduced RecordUsage D-Bus method in malcontent-timerd is problematic beyond the possibility to bypass parental controls. It allows arbitrary users in the system to slowly fill up disk space in /var/lib/malcontent-timerd. The following shell construct is a simple reproducer of the issue:

for I in `seq 100000`; do
    gdbus call -y -d org.freedesktop.MalcontentTimer1 \
        -o /org/freedesktop/MalcontentTimer1 \
        -m org.freedesktop.MalcontentTimer1.Child.RecordUsage \
        "[(0, 1000, \"app\", \"org.gnome.MyApp$I\")]"
done

The daemon will create an entry for every supposed GNOME app identifier passed to it in /var/lib/malcontent-timerd/store/<caller-username>.gvdb. This will slowly use up the disk space in /var and therefore is a local Denial-of-Service attack vector.

To fix the problem, the method call could be restricted to callers in local active sessions. Furthermore an upper limit of usage entries could be placed on every user account to prevent excess disk usage.

Upstream Report

We reported this issue privately via the upstream’s GitLab bug tracker on 2026-02-18 offering coordinated disclosure. We only received an initial reply a couple of weeks later in which upstream confirmed the issue but also mentioned that there is a lack of developer resources for malcontent. At this time we expressed our opinion that a non-disclosure period would not be strictly necessary since the impact of the issue is not high. We never received further replies from upstream, so we decided to go public with this report to avoid wasting more time without a bugfix being developed.

CVE Assignment

Due to the lack of replies we could not discuss with upstream whether a CVE assignment is appropriate for this issue. Given that upstream at least basically confirmed the issue and there is no bugfix available we assigned CVE-2026-44931 to track the defect and to make others aware.

Timeline

References

• malcontent freedesktop repository
• malcontent upstream private bug about this issue
• openSUSE review bug for malcontent 0.14.0

• 0) TL;DR
• 1) Introduction
• 2) Issues with current SELinux policy packaging
• 3) Solution: migration from /var to /etc
  • Packages involved in the migration
• 4) Troubleshooting
• 5) Closing Remarks
• 6) References
• Change History

0) TL;DR

• The SELinux policy packaging had long-standing issues on systems using BTRFS snapshots: files under /var/lib/selinux were not covered by snapshots and could not be rolled back.
• These files have now been migrated to /etc/selinux, which allows the SELinux policy to be fully covered by snapshots.
• The migration applies to openSUSE Tumbleweed and MicroOS systems using SELinux.
• The migration is transparent to the user and automatic on default setups. If you have a non-standard filesystem setup, or if you observe issues, read the full post below.

1) Introduction

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.

2) Issues with current SELinux policy packaging

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:

1. installing a policy update which contains backwards-incompatible changes (e.g. adding or removing SELinux types, attributes, modules …)
2. rolling back this update
3. performing some action which requires the SELinux policy items affected by the rollback, such as rebuilding the policy or an affected external policy module (either manually or e.g. via RPM package installation).

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.

3) Solution: migration from /var to /etc

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 several months, the migration was performed in Tumbleweed snapshot 20260505.

Some of the challenges encountered during the implementation of the migration process were:

• different rollback and update behaviour on classical and transactional systems (also transactional-update before version 5 used overlayfs for /etc)
• preserving existing local modifications to the SELinux configuration
• migrating custom modules (installed by packages or manually created by the user)
• packaging changes or rebuilds of some packages to properly reflect location changes, including RPM SELinux macros
• cleanup of /var/lib/selinux once no snapshot is using the old path
• installation on a fresh system, without migrating an existing system
• observability of discrepancies between migrated modules in /etc/selinux and last pre-migration state in /var/lib/selinux

The 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:

• print information about the migration process and inform the user if the system satisfies the migration requirements (root BTRFS subvolume present) or if a non-standard setup was detected (e.g. /etc on different BTRFS subvolume or no BTRFS at all), and what to do in this case.
• check if the system has already been migrated and skip migration in this case (using marker files in /etc/selinux/selinux_modules_migrated-*)
• backup the old location (/var/lib/selinux) to preserve state (marker files selinux_modules_pending-* and temp_selinux_modules_dir_created)
• install package (modules) into the new location (/etc/selinux)
• copy local changes and custom modules (*.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-*)
• install cleanup systemd service (cleanoldsepoldir.service) and script(/usr/libexec/selinux/cleanoldsepoldir.sh) to remove the old /var/lib/selinux location once no snapshot is using it

After package update:

• at boot, the 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.
• the cleanup script also allows the user to check if there are some custom SELinux modules missing in the new location, and has some heuristics to find the RPM packages of non-migrated modules to reinstall them

$ /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)

Packages involved in the migration

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-gaming
• selinux-policy-sapenablement
• container-selinux
• libvirt

Packages which ship custom SELinux modules were also fixed and rebuilt:

• cockpit-ws-selinux
• drbd-selinux
• google-guest-oslogin-selinux
• swtpm-selinux
• tigervnc-selinux
• tpm2.0-abrmd-selinux

We 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.

4) Troubleshooting

• If you have a non-standard filesystem setup (e.g. using custom BTRFS subvolumes, not using BTRFS at all, …) the migration may not work for you fully. You can find out if the migration was successful by checking for the presence of the directory /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.
• If you observe any issues resembling those described in Section 2, you can resolve them by reinstalling the selinux-policy* package and any affected external modules:

  $ sudo zypper in -f selinux-policy selinux-policy-targeted
  

• After the migration, only the last state of /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.

5) Closing Remarks

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.

6) References

• Tumbleweed Adopts SELinux as Default
• Policy migration tracker bug
• openSUSE Bugreport SELinux
• openSUSE SELinux Mailing List

Change History

• 1) Introduction
• 2) Helper Overview
• 3) Security Issues
  • 3.a) Arbitrary chown() via Symlink Attack in sync() Method
  • 3.b) Arbitrary File Deletion in reset() Method
  • 3.c) Symlink Attack via /var/lib/plasmalogin/wallpapers in save() Method
  • 3.d) Missing Integrity Check of Configuration Data in save() Method
  • 3.e) Lack of File Descriptor and File Size Verification in save() Method
• 4) Suggested Fixes
• 5) Severity
• 6) Upstream Bugfix
• 7) CVE Assignment
• 8) Timeline
• 9) References

1) Introduction

In 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.

2) Helper Overview

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.

3) Security Issues

3.a) Arbitrary chown() via Symlink Attack in sync() Method

In 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.

3.b) Arbitrary File Deletion in reset() Method

In 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.

3.c) Symlink Attack via /var/lib/plasmalogin/wallpapers in save() Method

In 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.

3.d) Missing Integrity Check of Configuration Data in save() Method

In 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.

3.e) Lack of File Descriptor and File Size Verification in save() Method

For 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.

4) Suggested Fixes

We suggested the following fixes to upstream:

• Foremost the helper should drop privileges to the 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.
• The helper should verify the structure and size of data written to /etc/plasmalogin.conf.
• The helper should place a limit on the maximum amount of space which may be used for wallpapers in the plasmalogin user’s home directory.
• The helper should verify the type and flags of file descriptors passed by the client. The descriptors should not have special file types and they should not have any unexpected flags like O_PATH set.

5) Severity

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.

6) Upstream Bugfix

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.

7) CVE Assignment

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.

8) Timeline

9) References

• blog post about issues in sddm-kcm6
• blog post about the introduction of file descriptor passing in kauth
• openSUSE plasma-login-manager KCM helper review bug
• plasmaloginauthhelper code
• plasma-login-manager repository

• 1) Introduction
• 2) systemd v258 - v260 Continued Reviews of D-Bus and Varlink Changes
• 3) snapd: Follow-up Audit for Transparent Inclusion of Snap Systemd Services
• 4) bootkitd: D-Bus Service for Manipulating Bootloader Configuration
• 5) libpgpr: RPM PGP Signature Parsing Library
• 6) GDM: Changes and Additions in Release 50
• 7) rtkit: D-Bus Service to Support Unprivileged Realtime Scheduling
• 8) SteamOS Package Additions
  • jupiter-fan-control
  • gamescope-session-steam-factory-reset
  • jupiter-hw-support
• 9) Revisit of Deepin Desktop D-Bus Services after Removal from openSUSE
  • Backlight Helper
  • Accounts Service
  • Summary
• 10) Conclusion

1) Introduction

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.

2) systemd v258 - v260 Continued Reviews of D-Bus and Varlink Changes

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:

• bsc#1257388: follow-up review of backported code in systemd 258.3
• bsc#1257943: follow-up review of backported code in systemd 258.4
• bsc#1255368: review of changes introduced in systemd 259
• bsc#1259318: review of changes introduced in systemd 260

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.

3) snapd: Follow-up Audit for Transparent Inclusion of Snap Systemd Services

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.

4) bootkitd: D-Bus Service for Manipulating Bootloader Configuration

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.

5) libpgpr: RPM PGP Signature Parsing Library

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.

6) GDM: Changes and Additions in Release 50

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.

7) rtkit: D-Bus Service to Support Unprivileged Realtime Scheduling

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).

8) SteamOS Package Additions

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.

jupiter-fan-control

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.

gamescope-session-steam-factory-reset

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.

jupiter-hw-support

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.

9) Revisit of Deepin Desktop D-Bus Services after Removal from openSUSE

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.

Backlight Helper

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.

Accounts Service

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:

• the 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.
• the 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.
• the SetPassword() D-Bus method, again accessible by providing the user password, is affected by multiple issues:
  • the new user password is leaked in the process command line constructed in ModifyPasswd().
  • the function removeLoginKeyring() which is invoked in this context operates as root in the user’s home directory, offering local Denial-of-Service attack surface.
  • an insufficient check is made by the D-Bus service, which tries to verify whether the client is running a trusted password change application. The check is affected by a race condition and can be circumvented by malicious clients.
  • the function 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.

Summary

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.

10) Conclusion

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.

• Introduction
• Overview
• Security Issues
• Suggested Fixes
• Upstream Bugfix
• CVE Assignment
• Timeline
• References

Introduction

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.

Overview

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.

Security Issues

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.

• since the daemon also attempts to create directories under some conditions, these directories could be created in arbitrary locations where the root group has write permission.
• the daemon checks the type of files via 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:
  • parsing of private files accessible to the root group. Whether the data parsed from such files could ever leak into the context of a local attacker is a matter that we did not investigate more closely for the purpose of this report.
  • by placing a symbolic link to e.g. /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).
  • by placing a FIFO named pipe in the location the daemon would block on it forever, also leading to a local DoS.
• the daemon considers accounts with user IDs ≥ 1000 as regular user accounts. On many Linux distributions this means that also the 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.

Suggested Fixes

We suggested the following improvements to upstream to deal with the issues:

• the privileges should be fully dropped to the target user account, including group ID and the supplementary group IDs.
• to prevent potential DoS attack surface, the daemon should carefully open target paths element by element, passing 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.
• the nobody user account should be explicitly excluded based on its name for distributions that set a valid shell for this account.
• as additional hardening, the systemd unit 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 Bugfix

Upstream implemented commit 63cd93bddd0 containing the following changes:

• the daemon properly drops its group and supplementary group IDs to the target user’s.
• only user IDs in the range defined by UID_MIN and UID_MAX as configured in /etc/login.defs will be considered.
• icon files in /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.

CVE Assignment

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.

Timeline

References

• Cosmic Website
• openSUSE cosmic-greeter review bug
• cosmic-greeter privilege drop bugfix
• Upstream Release 1.0.9 containing the bugfix

• 1) Introduction
• 2) The methodology
  • Some numbers about the codebase
  • The activity tracking
  • The setup
  • The attacker’s corner
  • The reporting method
• 3) Audit results
  • CVE-2024-49502: spacewalk-web: Reflected XSS in Setup Wizard, HTTP Proxy credentials pane
  • CVE-2024-49503: spacewalk-web: Reflected XSS in Setup Wizard, Organization Credentials
  • CVE-2025-23392: spacewalk-java: reflected XSS in SystemsController.java
  • CVE-2025-46809: Plain text HTTP Proxy user:password in repolog accessible from the UYUNI 5.x webUI
  • CVE-2025-46811: Unprotected websocket endpoint
  • CVE-2025-53883: spacewalk-java: various XSS found on search page
  • CVE-2025-53880: susemanager-tftpsync-recv: arbitrary file creation and deletion due to path traversal
  • Other minor findings
• 4) Conclusions
• 5) What’s next?
• 6) Links

1) Introduction

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:

• the package implementing UYUNI web UI
• the package implementing API or websocket layer
• the package implementing UYUNI backend
• the salt package (fundamental for UYUNI server and minions interaction)
• packages not included in previous UYUNI audits

In March 2024 the code scanning activities effectively started.

2) The methodology

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.

Some numbers about the codebase

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.

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.

The activity tracking

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.

The setup

For the activity, a set of KVM-powered machines were created:

• a UYUNI server instance
• a UYUNI proxy instance
• a couple of minions, Linux workstations attached and managed centrally by the master.

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.

The attacker’s corner

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.

The tools

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:

• bandit
• semgrep
• npm audit

To help me during the activities, I also used some SAST tools previously written by myself, like:

• dr_source
• dawnscanner

The reporting method

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.

3) Audit results

During the audit, seven CVEs were found and fixed, and numerous minor issues were addressed, improving the product’s reliability and overall security posture.

CVE-2024-49502: spacewalk-web: Reflected XSS in Setup Wizard, HTTP Proxy credentials pane

A reflected cross-site scripting has been found in the HTTP proxy pane of the setup wizard UI element. Tracked in boo#1231852

CVE-2024-49503: spacewalk-web: Reflected XSS in Setup Wizard, Organization Credentials

A reflected cross-site scripting has been found in the Organization Credentials pane of the setup wizard UI element. Tracked in boo#1231922

CVE-2025-23392: spacewalk-java: reflected XSS in SystemsController.java

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

CVE-2025-46809: Plain text HTTP Proxy user:password in repolog accessible from the UYUNI 5.x webUI

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

CVE-2025-46811: Unprotected websocket endpoint

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

CVE-2025-53883: spacewalk-java: various XSS found on search page

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.

CVE-2025-53880: susemanager-tftpsync-recv: arbitrary file creation and deletion due to path traversal

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

Other minor findings

Additional vulnerabilities were identified that, while valid, did not meet the criteria for CVE assignment:

• boo#1231900: VUL-0: arbitrary log messages in API can lead to a disk space exhaustion (and so to a denial of service)
• boo#1245740: VUL-0: Default venv-salt-minion environment is activated on the different user accounts
• boo#1243679: VUL-0: Insecure communication in TFTP proxy sync.
• boo#1243768: VUL-0: Potential Command InjectionPattern in check_push Function. No activity: a follow-up was requested.
• boo#1239636: VUL-0: log pollution in class TraceBackEvent
• boo#1237368: VUL-0: unhandled exception when dealing with numeric request parameters
• boo#1243087: VUL-0: spacewalk-search: unexploitable XSS in XML RPC Server.
• boo#1227577: VUL-0: spacecmd and spacewalk-backend: usage of unsafe third party library for XML.

Last but not least, during the audit also some codebase improvements were suggested to raise the security posture even further:

• boo#1228945: AUDIT-FIND: spacewalk-utils: Sensitive information disclosure in backup file
• boo#1223313: AUDIT-FIND: Possible deserialization issue in spacewalk-client-tools (affecting only SUMA 4.x)
• boo#1228116: AUDIT-FIND: spacewalk-admin: mgr-monitoring-ctl doesn’t sanitize PILLAR parameter
• boo#1231983: AUDIT-FIND: spacewalk-web: generatePassword() improve namespace entropy
• boo#1246941: AUDIT-FIND: saline: Hardening Against Insecure Deserialization
• boo#1247015: AUDIT-FIND: saline: Race Condition in Service Startup Allows for IPC Hijacking on Systems with a Permissive umask
• boo#1227579: AUDIT-FIND: spacecmd: get rid of pickle to read and parse configuration files.

4) Conclusions

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.

5) What’s next?

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.

6) Links

• The master Bugzilla bug.
• The latest stable version 2025.10 of UYUNI containing all the relevant fixes.
• The nightcrawler-mitm tool, written to actively and passively scan the web application in the background.
• The dr_source tool, written as a SAST companion tool mainly for Java but improved with support for other programming languages.
• The UYUNI source code on Github
• The openSUSE coordinated disclosure policy

• 1) Introduction
• 2) Completion of systemd v258 Code Review
• 3) D-Bus Issues in Unreleased plasma-setup KDE Package
  • org.kde.initialsystemsetup.createnewuserautostarthook
  • org.kde.initialsystemsetup.setnewuserhomedirectoryownership
  • org.kde.initialsystemsetup.setnewusertempautologin
  • Upstream Fixes
• 4) Discussion about Granting setgid Privileges to the plocate Binary
• 5) Local Root Exploit in OpenStack’s non-production virtualbmc Project
  • Lack of Authorization and Input Validation in vbmcd
  • Reproducer
  • Further Concerns
• 6) Revisit of the snapd Package Manager
• 7) Conclusion

1) Introduction

The 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:

• trivial local Denial-of-Service in the OpenSMTPD mail transfer agent.
• unauthenticated D-Bus API in the scx scheduler project allowing for a major local Denial-of-Service.
• minor privilege escalation from lightdm to root in lightdm-kde-greeter leading to major improvements of its D-Bus code.
• major local vulnerabilities in the D-Bus interface of 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.

2) Completion of systemd v258 Code Review

We 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:

• if a process only performs fork() and setns() to join a user namespace, then ptrace() access to this process is denied to the owner of the user namespace.
• if a process performs 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.

3) D-Bus Issues in Unreleased plasma-setup KDE Package

This 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.

org.kde.initialsystemsetup.createnewuserautostarthook

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.

Suggested Fixes

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.

org.kde.initialsystemsetup.setnewuserhomedirectoryownership

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.

Suggested Fixes

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.

org.kde.initialsystemsetup.setnewusertempautologin

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.

Suggested Fixes

As for the other actions, the implementation should verify whether the passed “username” is valid and does not equal root.

Upstream Fixes

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.

4) Discussion about Granting setgid Privileges to the plocate Binary

An 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.

5) Local Root Exploit in OpenStack’s non-production virtualbmc Project

By 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.

Lack of Authorization and Input Validation in vbmcd

When 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.

Reproducer

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.

Further Concerns

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.

6) Revisit of the snapd Package Manager

In 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.

7) Conclusion

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.