Qualys discovered two vulnerabilities in various Linux distributions which allow local attackers to escalate privileges. The first vulnerability (CVE-2025-6018) was found in the PAM configuration. This CVE does not impact default Ubuntu installations because of how the pam_systemd.so
and pam_env.so
modules are invoked. The second vulnerability (CVE-2025-6019) affects both libblockdev and udisks2 source packages available in Ubuntu.
The two vulnerabilities are used as part of an exploit chain to escalate privileges from an unprivileged user to polkit allow_active
(representing physical console users) and then from polkit allow_active
to root. Because the first vulnerability does not apply to default Ubuntu configurations, privilege escalation can only be achieved through physical console access with default polkit rules.
CVE-2025-6018
Qualys researchers discovered that some Linux distributions could allow an attacker, who logs in via ssh, to obtain the privileges of a physical (console) allow_active
user. This attack is possible by using the pam_env.so
module to set environment variables before the pam_systemd.so
module is called, tricking pam_systemd.so
into granting console privileges. In a default configuration, Ubuntu is not vulnerable to this issue as either the pam_env.so
user_readenv
option is not set, or pam_env.so
is not located before the pam_systemd.so
module invocation.
If you have customized PAM configurations in your environment, please make sure they are not vulnerable. In particular, there should be no pam_env.so
user_readenv=1
invocations before pam_systemd.so
in any of the PAM stacks defined under /etc/pam.d/
.
CVE-2025-6019
Qualys researchers analyzed the udisks daemon, which is installed by default on most Linux distributions. When making libblockdev calls, for example to resize an XFS filesystem, those are done without the nosuid
and nodev
flags. Through this, an attacker that is allowed to mount filesystems (which in default polkit configuration requires allow_active
authorization, equivalent to physical console access) could copy into the victim’s machine an image, which contains a SUID-root shell and, by setting up a loop device with this image and requesting udisks to resize that filesystem, libblockdev would mount it in /tmp
without the nosuid
and nodev
flags. The attacker can then execute their SUID-root shell and obtain full root privileges.
In order to successfully carry out the exploit, the attacker would need to have mount privileges, which in the default polkit configuration require physical console access.
Release | Package Name | Fixed Version |
Trusty (14.04) | libblockdev | Not present |
Xenial (16.04) | libblockdev | Not present |
Bionic (18.04) | libblockdev | 2.16-2ubuntu0.1~esm1 |
Focal (20.04) | libblockdev | 2.23-2ubuntu3+esm1 |
Jammy (22.04) | libblockdev | 2.26-1ubuntu0.1 |
Noble (24.04) | libblockdev | 3.1.1-1ubuntu0.1 |
Oracular (24.10) | libblockdev | 3.1.1-2ubuntu0.1 |
Plucky (25.04) | libblockdev | 3.3.0-2ubuntu0.1 |
Trusty (14.04) | udisks2 | Not affected |
Xenial (16.04) | udisks2 | Not affected |
Bionic (18.04) | udisks2 | 2.7.6-3ubuntu0.2+esm1 |
Focal (20.04) | udisks2 | 2.8.4-1ubuntu2+esm1 |
Jammy (22.04) | udisks2 | 2.9.4-1ubuntu2.2 |
Noble (24.04) | udisks2 | 2.10.1-6ubuntu1.2 |
Oracular (24.10) | udisks2 | 2.10.1-9ubuntu3.2 |
Plucky (25.04) | udisks2 | 2.10.1-11ubuntu2.2 |
On your system, run the following command and compare the listed version to the table above.
apt list --installed | grep "^\(udisks2\|libblockdev\)"
We recommend you upgrade all packages:
sudo apt update && sudo apt upgrade
If this is not possible, the affected component can be targeted:
# For noble and newer:
sudo apt update && sudo apt install --only-upgrade libblockdev3 udisks2
# For jammy and older:
sudo apt update && sudo apt install --only-upgrade libblockdev2 udisks2
The unattended-upgrades feature is enabled by default for Ubuntu 16.04 LTS onwards. This service:
- Applies new security updates every 24 hours automatically.
- If you have this enabled, the patches above will be automatically applied within 24 hours of being available.
The strongest protection is to apply the security updates. The following mitigations have also been explored. If security updates cannot be applied, you should only apply the following steps as a last resort and restore the original policy file once updates are applied. Please note that, as this is not a configuration file, any update or reinstallation of the udisks2 package will revert local changes.
The advice from Qualys is:
On /usr/share/polkit-1/actions/org.freedesktop.UDisks2.policy
modify the polkit rule for org.freedesktop.udisks2.modify-device
. Change the allow_active
from yes
to auth_admin
:
<allow_active>auth_admin</allow_active>
We would like to thank Qualys for their excellent reporting.