--- title: Fixes available for local privilege escalation vulnerability in libblockdev using udisks description: Canonical’s security team has released updates for the libblockdev and udisks packages for all supported Ubuntu releases that are affected by the local privilege escalation vulnerability. url: https://canonical.com/blog/udisks-libblockdev-lpe-vulnerability-fixes-available?format=md --- 1. [Blog](https://canonical.com/blog) 2. Article --- [ebarretto](https://canonical.com/blog/author/ebarretto "More about ebarretto") 18 June 2025 # Fixes available for local privilege escalation vulnerability in libblockdev using udisks [Security](https://canonical.com/blog/tag/security) [Vulnerabilities](https://canonical.com/blog/tag/vulnerabilities) --- Share the article Qualys discovered two vulnerabilities in various Linux distributions which allow local attackers to escalate privileges. The first vulnerability ([CVE-2025-6018](https://ubuntu.com/security/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](https://ubuntu.com/security/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. # How the exploits work ## 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. # Affected releases | | | | | --- | --- | --- | | **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 | # How to check if you are impacted On your system, run the following command and compare the listed version to the table above. ``` apt list --installed | grep "^\(udisks2\|libblockdev\)" ``` # How to address 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. # Mitigation 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`: ``` auth_admin ``` # Acknowledgements We would like to thank Qualys for their excellent reporting. # References [Get in touch Interested in running Ubuntu in your organization?](https://ubuntu.com/about/contact-us/form) ## Sign up for our newsletter Get the latest Canonical news and updates in your inbox. Work email: \*I agree to receive information about Canonical's products and services. By submitting this form, I confirm that I have read and agree to [Canonical's Privacy Policy](https://canonical.com/legal/dataprivacy). Sign up ## Share on --- ## Related posts [### Januscape vulnerability CVE-2026-53359 mitigations available](https://canonical.com/blog/januscape-linux-vulnerability-mitigations-available) Introduction A local privilege escalation (LPE) vulnerability affecting the Linux kernel was publicly disclosed on July 6, 2026. The vulnerability was assigned CVE ID... [seth-arnold](https://canonical.com/blog/author/seth-arnold) 11 July 2026 [### DirtyClone Linux kernel local privilege escalation vulnerability fixes available](https://canonical.com/blog/dirtyclone-linux-vulnerability-fixes-available) On June 25, 2026, JFrog published their research into CVE-2026-43503, referring to the vulnerability as DirtyClone. The vulnerability had previously been responsibly disclosed... [Luci Stanescu](https://canonical.com/blog/author/lucistanescu) 1 July 2026 [### pedit COW kernel local privilege escalation vulnerability mitigations](https://canonical.com/blog/pedit-cow-linux-vulnerability-fixes-available) Mitigations are available for the Linux vulnerability with CVE ID CVE-2026-46331. The CVE ID was assigned on June 16 2026 and highlighted as a local privilege escalation (LPE)... [Luci Stanescu](https://canonical.com/blog/author/lucistanescu) 1 July 2026 [### PinTheft Linux kernel vulnerability mitigation](https://canonical.com/blog/pintheft-linux-kernel-vulnerability-mitigation) A local privilege escalation (LPE) security vulnerability in the Linux kernel, codename “PinTheft,” was publicly disclosed on May 19, 2026. The vulnerability was fixed in the... [seth-arnold](https://canonical.com/blog/author/seth-arnold) 21 May 2026