A local attacker with /dev/uinput access can inject arbitrary udev properties through the libinput-device-group helper. Depending on downstream udev rules, this can result in root code execution (e.g. via injected REMOVECMD properties executed at device removal time). REMOVECMD is in the default udev rules and expected to be present on virtually all machines.

An issue was discovered in GStreamer gst-plugins-good before 1.28.2. When parsing MP4 audio tracks, the isomp4 plugin's qtdemuxaudiocaps function does not sufficiently validate atom data before performing division operations, leading to denial of service due to integer division by zero.

An issue was discovered in GStreamer gst-plugins-good before 1.28.2. When parsing MP4 audio tracks, the isomp4 plugin's qtdemuxparsetrak function does not sufficiently validate atom data before performing division operations, leading to denial of service due to integer division by zero.

A flaw was found in libinput. An attacker capable of deploying a Lua plugin file in specific system directories can exploit a dangling pointer vulnerability. This occurs when a garbage collection cleanup function is called, leaving a pointer that can then be printed to system logs. This could potentially expose sensitive data if the memory location is re-used, leading to information disclosure. For this exploit to work, Lua plugins must be enabled in libinput and loaded by the compositor.

A flaw was found in libinput. A local attacker who can place a specially crafted Lua bytecode file in certain system or user configuration directories can bypass security restrictions. This allows the attacker to run unauthorized code with the same permissions as the program using libinput, such as a graphical compositor. This could lead to the attacker monitoring keyboard input and sending that information to an external location.

A flaw was found in polkit. A local user can exploit this by providing a specially crafted, excessively long input to the polkit-agent-helper-1 setuid binary via standard input (stdin). This unbounded input can lead to an out-of-memory (OOM) condition, resulting in a Denial of Service (DoS) for the system.

An incomplete fix for CVE-2024-47778 allows an out-of-bounds read in gstwavparseadtlchunk() function. The patch added a size validation check lsize + 8 > size, but it does not account for the GSTROUNDUP2(lsize) used in the actual offset calculation. When lsize is an odd number, the parser advances more bytes than validated, causing OOB read.

A flaw was found in the udisks storage management daemon that exposes a privileged D-Bus API for restoring LUKS encryption headers without proper authorization checks. The issue allows a local unprivileged user to instruct the root-owned udisks daemon to overwrite encryption metadata on block devices. This can permanently invalidate encryption keys and render encrypted volumes inaccessible. Successful exploitation results in a denial-of-service condition through irreversible data loss.

A flaw was found in the udisks storage management daemon that allows unprivileged users to back up LUKS encryption headers without authorization. The issue occurs because a privileged D-Bus method responsible for exporting encryption metadata does not perform a policy check. As a result, sensitive cryptographic metadata can be read and written to attacker-controlled locations. This weakens the confidentiality guarantees of encrypted storage volumes.

https://securitylab.github.com/advisories/GHSL-2025-042poppler/ advises: Coordinated Disclosure Timeline

2025-04-03: Reported as a private issue: https://gitlab.freedesktop.org/poppler/poppler/-/issues/1580 2025-09-03: Created a merge request with our suggested fix: https://gitlab.freedesktop.org/poppler/poppler/-/mergerequests/1884 2025-29-09: Fixed merged https://gitlab.freedesktop.org/poppler/poppler/-/mergerequests/1884#note3114334

Summary

A use-after-free (write) vulnerability has been detected in Poppler within the StructTreeRoot class. The issue arises from the use of raw pointers to elements of a std::vector, which can lead to dangling pointers when the vector is resized.

Project

poppler

Tested Version

25.02.0

Details

Use-After-Free (write) in StructTreeRoot::parentTreeAdd (GHSL-2025-042)

The vulnerability stems from the way that refToParentMap stores references to std::vector elements using raw pointers. These pointers may become invalid when the vector is resized.

This vulnerability is a common security problem involving the use of raw pointers to std::vectors. Internally, std::vector stores its elements in a dynamically allocated array. When the array reaches its capacity and a new element is added, the vector reallocates a larger block of memory and moves all the existing elements to the new location. At this point if any pointers to elements are stored before a resize occurs, they become dangling pointers once the reallocation happens.

The affected method is StructTreeRoot::parseNumberTreeNode in the file poppler/StructTreeRoot.c, and specifically, the following code snippet:

int keyVal = key.getInt(); std::vector<Parent> &vec = parentTree[keyVal]; //Get the vector reference ... vec.resize(valueArray.arrayGetLength()); //vector resize (and posible new allocation) happens ... refToParentMap.insert(std::pair<Ref, Parent >(ref, &vec[j])); //inserts a reference to 'vec' into the std::multimap

In this code snippet, a pointer to an element of vec is inserted into refToParentMap (see line 149). However, in subsequent iterations the vector may be resized (as seen on line 143), which frees the previously allocated memory and allocates new memory. As a result, the old pointer remains in refToParentMap and becomes a dangling pointer.

Impact

It’s possible that this use-after-free bug could be exploited to achieve code execution in poppler.

CWEs

CWE-416: “Use After Free”

CVE

CVE-2025-52885

Credit

This issue was discovered and reported by GHSL team member @antonio-morales (Antonio Morales).

Contact

You can contact the GHSL team at securitylab () github com, please include a reference to GHSL-2025-042 in any communication regarding this issue. -- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Hi,

Thank you Marco and Tomášor handling this disclosure so well!

I'll add below a little piece of discussion from the distros list, which I think may be helpful to a wider audience.

On Thu, Aug 28, 2025 at 04:41:50PM +0200, Tomáš Bžatek wrote: On Wed, 2025-08-27 at 23:01 +0200, Solar Designer wrote: I looked a bit into exposure of this vulnerability for attack:

I checked a few Linux server systems, and I do not see udisks running anywhere by default, but simply running:

$ udisksctl monitor Monitoring the udisks daemon. Press Ctrl+C to exit. 22:49:43.365: The udisks-daemon is running (name-owner :1.49).

as an unprivileged user ssh'ed in remotely gets udisksd started as root e.g. on Rocky Linux 9 and on an old Fedora, so it's exposed for attack anyway. The user isn't a sudoer and isn't in group wheel. UDisks is primarily a D-Bus daemon and set for autoactivation through its well-known name and there's a D-Bus service policy file for that. It can be started via an initscript/systemd unit as well, that's up to distro discretion. The below also works to get udisksd started as root, but requires the user to be in group wheel and to re-authenticate:

$ systemctl start udisks2 ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ==== Authentication is required to start 'udisks2.service'. Authenticating as: user Password: ==== AUTHENTICATION COMPLETE ====

Trying to actually trigger the bug from the provided Python script (the crash one) as a user ssh'ed in remotely to Rocky Linux 9, I get:

gi.repository.GLib.GError: g-io-error-quark: GDBus.Error:org.freedesktop.UDisks2.Error.NotAuthorizedCanObtain: Not authorized to perform operation (36)

So maybe it's not fully exposed even if the user can start udisksd on demand. When I ran the script as root, it crashed udisksd just fine.

What are the permissions commonly required for this? Access is guarded through Polkit rules, in this case: Tomáš provided a link to latest revision, but here's one updated to point to the current revision specifically (so that it stays valid):

https://github.com/storaged-project/udisks/blob/b495ae587662747b373b5d32c284529e048aebf8/data/org.freedesktop.UDisks2.policy.in#L183-L192

<action id="org.freedesktop.udisks2.loop-setup"> <description>Manage loop devices</description> <message>Authentication is required to set up a loop device</message> <defaults> <allowany>authadmin</allowany> <allowinactive>authadmin</allowinactive> <!-- NOTE: this is not a DoS because we are using /dev/loop-control --> <allowactive>yes</allowactive> </defaults> </action> So really depends how is your session classified and yes, the attack surface is slightly lower for non-local seats. However, combine it with other CVEs, notably CVE-2025-6018, and you have a bigger problem. CVE-2025-6018: LPE from unprivileged to allowactive in SUSE 15's PAM https://www.openwall.com/lists/oss-security/2025/06/17/4 For the potential privilege escalation attack, is the negatively indexed fd located within the same heap object or a different one? Would e.g. a guard page before the allocation, such as planted by hardenedmalloc, affect the ability to mount this attack? (We're actually running with hardenedmalloc in CIQ's RLC-H product.) I'm not a security expert and this spans to the glib code (gunixfdlistget) as well. Would it be good practice to exclude udisks2 from default installs of server systems? I tried "rpm -e udisks2" on Rocky Linux 9 and it just completed, meaning there were no dependencies on this package (at least known to RPM). It's not really needed for minimal installs, it's used primarily by desktop environments and server management consoles like Cockpit. For RHEL specifically, its inclusion by default AND udisks2.service being enabled by default is mostly historic relic I guess. Thanks again,

Alexander

An issue in the pdfseparate utility of freedesktop poppler v25.04.0 allows attackers to cause an infinite recursion via supplying a crafted PDF file. This can lead to a Denial of Service (DoS).

Hi Alan,

Thanks for posting this one! I didn't send it to the list myself because I don't think it's realistically exploitable: it takes too long to trigger the integer overflow. But for anybody who's interested, the poc is here:

https://github.com/github/securitylab/tree/main/SecurityExploits/freedesktop/poppler-CVE-2025-52886

Thanks,

Kev

On Sat, Jul 12, 2025 at 12:01 AM Alan Coopersmith <alan.coopersmith () oracle com> wrote: https://securitylab.github.com/advisories/GHSL-2025-054poppler/ advises: July 1, 2025 GHSL-2025-054: Use After Free (UAF) in Poppler - CVE-2025-52886 Author Kevin Backhouse

Coordinated Disclosure Timeline

2025-04-03: Reported as a private issue: https://gitlab.freedesktop.org/poppler/poppler/-/issues/1581 2025-06-02: Fixed by limiting the maximum number of annots: https://gitlab.freedesktop.org/poppler/poppler/-/mergerequests/1828 2025-06-03: Issue made publicly visible: https://gitlab.freedesktop.org/poppler/poppler/-/issues/1581 2025-06-03: Poppler 25.06.0 released: https://gitlab.freedesktop.org/poppler/poppler/-/tree/poppler-25.06.0?reftype=tags

Summary

poppler uses std::atomicint for reference counting. Because it is only 32 bits, it is possible to overflow the reference count and trigger a use-after-free.

Project

poppler

Tested Version

25.02.0

Details

Use-after-free due to reference count integer overflow (GHSL-2025-054)

poppler uses the type std::atomicint for reference counting in four locations:

Annot.h Array.h Dict.h Stream.h

Because std::atomicint is only 32 bits, it’s possible to overflow one of these reference counts, which can lead to a use-after-free memory corruption vulnerability.

We have included a proof of concept which triggers an integer overflow on the reference count in Annot.h. The poc file is only 3.1KB in size, but contains a stream which decompresses to an array of annotations of size 0x1000000. That array is referenced by 0x100 pages, which causes the reference count on the annotation to be incremented 0x100000000 times, so it wraps around to zero and the annotation is deleted. Run the poc like this:

pdftohtml GHSL-2025-054popplerrefcount.pdf

Impact

It’s possible that this use-after-free bug could be exploited to achieve code execution in poppler. However, in our testing it took 12 hours to trigger the use-after-free, so in practice the risk of exploitation is low.

CWEs

CWE-190: “Integer Overflow or Wraparound” CWE-416: “Use After Free” CWE-911: “Improper Update of Reference Count”

CVE

CVE-2025-52886

Credit

This issue was discovered and reported by GHSL team member @kevinbackhouse (Kevin Backhouse).

Contact

You can contact the GHSL team at securitylab () github com, please include a reference to GHSL-2025-054 in any communication regarding this issue. -- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

https://securitylab.github.com/advisories/GHSL-2025-054poppler/ advises: July 1, 2025 GHSL-2025-054: Use After Free (UAF) in Poppler - CVE-2025-52886 Author Kevin Backhouse

Coordinated Disclosure Timeline

2025-04-03: Reported as a private issue: https://gitlab.freedesktop.org/poppler/poppler/-/issues/1581 2025-06-02: Fixed by limiting the maximum number of annots: https://gitlab.freedesktop.org/poppler/poppler/-/mergerequests/1828 2025-06-03: Issue made publicly visible: https://gitlab.freedesktop.org/poppler/poppler/-/issues/1581 2025-06-03: Poppler 25.06.0 released: https://gitlab.freedesktop.org/poppler/poppler/-/tree/poppler-25.06.0?reftype=tags

Summary

poppler uses std::atomicint for reference counting. Because it is only 32 bits, it is possible to overflow the reference count and trigger a use-after-free.

Project

poppler

Tested Version

25.02.0

Details

Use-after-free due to reference count integer overflow (GHSL-2025-054)

poppler uses the type std::atomicint for reference counting in four locations:

Annot.h Array.h Dict.h Stream.h

Because std::atomicint is only 32 bits, it’s possible to overflow one of these reference counts, which can lead to a use-after-free memory corruption vulnerability.

We have included a proof of concept which triggers an integer overflow on the reference count in Annot.h. The poc file is only 3.1KB in size, but contains a stream which decompresses to an array of annotations of size 0x1000000. That array is referenced by 0x100 pages, which causes the reference count on the annotation to be incremented 0x100000000 times, so it wraps around to zero and the annotation is deleted. Run the poc like this:

pdftohtml GHSL-2025-054popplerrefcount.pdf

Impact

It’s possible that this use-after-free bug could be exploited to achieve code execution in poppler. However, in our testing it took 12 hours to trigger the use-after-free, so in practice the risk of exploitation is low.

CWEs

CWE-190: “Integer Overflow or Wraparound” CWE-416: “Use After Free” CWE-911: “Improper Update of Reference Count”

CVE

CVE-2025-52886

Credit

This issue was discovered and reported by GHSL team member @kevinbackhouse (Kevin Backhouse).

Contact

You can contact the GHSL team at securitylab () github com, please include a reference to GHSL-2025-054 in any communication regarding this issue. -- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Poppler is a PDF rendering library. Versions prior to 25.06.0 use std::atomicint for reference counting. Because std::atomicint is only 32 bits, it is possible to overflow the reference count and trigger a use-after-free. Version 25.06.0 patches the issue.

Last updated 30 April 2025

A floating-point exception in the PSStack::roll function of Poppler before 25.04.0 can cause an application to crash when handling malformed inputs associated with INTMIN.

Last updated 8 April 2025

Last updated 16 January 2025

A flaw was found in the Poppler's Pdfinfo utility. This issue occurs when using -dests parameter with pdfinfo utility. By using certain malformed input files, an attacker could cause the utility to crash, leading to a denial of service.

Hi Yaron,

Thanks for taking time to look into this issue.

We appreciate the analysis you did, although, as we already shared privately, we don't think that this is a fprintd issue but rather an architectural issue of how PAM modules interact with sudo that, by design, does not permit an additional attention mechanism beyond displaying a prompt in the terminal.

It's important to note that no graphical PAM front-end (that we are aware of) is affected by this problem. For example, the PolicyKit dialog that gnome-shell integrates and also the GDM login and lock screens will properly ensure user attention. Said differently, there should be no user attention issue as long as fingerprint authentication is restricted to properly implemented graphical front-ends. This is a policy decision for administrators and distributors to ensure using the PAM configuration.

We would like to point out that similar behaviors may occur with any PAM module that uses an out-of-band authentication mechanism (whether using another device or not) that doesn't require the user to pay attention to the main device (SSO, web authentication, hardware-token based, …).

The discussed behavior completely depends on the PAM configuration (which, in most cases, needs to be enabled by the user). If this is considered an issue, then it cannot be resolved within fprintd (and pamfprintd.so in particular). Should this be considered an issue, then it needs to be addressed by modifying the PAM configuration to restrict pamfprintd.so to front-ends that implement a proper attention mechanism. This is out of scope for fprintd and must be done by administrators and possibly distributions as part of a policy decision. A policy decision that the reporter made when enabling fingerprint authentication using pam-auth-update.

As explained, this is not an fprintd issue, and it cannot be considered a security flaw in fprintd, and therefore we believe that it should not have been assigned a CVE number.

Thank you again for caring about fingerprint security.

The fprintd maintainers, Benjamin and Marco

Il giorno gio, 30/05/2024 alle 09.18 +0000, Yaron Shahrabani ha scritto: Hi everyone, I'm writing to this mailing list since I've already shared the details with Benjamin Berg and Marco Trevisan privately, and we have yet to conclude about this vulnerability. This information was also disclosed to the fprintd mailing list: https://lists.freedesktop.org/archives/fprint/2024-May/001231.html

My sudo is configured to approve access with pamfprintd; this is the config file:

#%PAM-1.0

auth            sufficient      pamfprintd.so auth            include         system-auth account         include         system-auth session         include         system-auth

So, unless I'm not already authenticated, running the following command: sudo whoami Replies with the following prompt: Place your finger on the fingerprint reader

Placing my finger on the fingerprint reader leads to the following output: root

The security concern is that this process can also happen behind the scenes, so if I'm running a script that has a sudo prompt to delete something I care about, I can accidentally place my fingerprint on the fingerprint reader for any other reasons, and my beloved files will be removed.

How do we recreate the issue? You can open your favorite console app on Linux. If it supports tabs open two tabs, if not just open another window. On the first tab, type: sudo whoami Switch to the second tab and type: echo Place your finger on the fingerprint reader;cat Place your fingerprint on the fingerprint reader Return to the first tab (You should see that the command was approved and the output is root)

Assume the user was running some background process and didn't see the fingerprint prompt from the other terminal. The second terminal may deceive the user into placing the finger on the fingerprint reader and elevating permissions without the user being fully aware.

On Ubuntu, if I want to recreate the same configuration, all I have to do is enroll my fingerprints in System Settings, then install the pam-auth-update and select the Fingerprint authentication from the selection screen (apt specific) as described in the following SO thread: https://askubuntu.com/questions/1015416/use-fingerprint-authentication-not-only-for-login .

This problem was solved in macOS by simply displaying a window; if the window is out of focus, the fingerprint won't work. Since we can't rely on any graphical window on Linux since it can be terminal only, we need to ensure that the user fingerprint is used only for the sole purpose of the request and with full attention to the specific action the fingerprint was requested for. Otherwise, the fingerprint can be hijacked (just like clickjacking).

Benjamin was kind enough to respond, and I allowed myself to summarize his reply: It can happen with fprintd as with any other external authentication method (aside from password, we have Bluetooth proximity, NFC Tag, Smart Card, etc.), so it is not unique to fprintd. Benjamin also offered mitigating ways, such as changing the configuration or using pkexec instead of sudo.

I addressed this issue with the sudo maintainer, Todd C. Miller, and again, I allowed myself to summarize his response: Although I understand the concern, I need a security attention mechanism to fix it.

CVSS 4.0 ranked this CVE as 7.3.

Thank you, PS, I'm not a security researcher, and I'm not affiliated with any organization.

Yaron Shahrabani - DevOps, Hebrew translator

Buffer Overflow vulnerability in function ID3Support::ID3v2Frame::getFrameValue in exempi 2.5.0 and earlier allows remote attackers to cause a denial of service via opening of crafted audio file with ID3V2 frame.

https://gitlab.freedesktop.org/libopenraw/exempi/issues/13 https://gitlab.freedesktop.org/libopenraw/exempi/commit/fdd4765a699f9700850098b43b9798b933acb32f

An issue was discovered in Poppler 22.07.0. There is a reachable abort which leads to denial of service because the main function in pdfunite.cc lacks a stream check before saving an embedded file.

A reachable Object::getString assertion in Poppler 22.07.0 allows attackers to cause a denial of service due to a failure in markObject.

An issue was discovered in Poppler 22.08.0. There is a reachable assertion in Object.h, will lead to denial of service because PDFDoc::replacePageDict in PDFDoc.cc lacks a stream check before saving an embedded file.

Buffer Overflow vulnerability in HtmlOutputDev::page in poppler 0.75.0 allows attackers to cause a denial of service.

Uncontrolled Recursion in pdfinfo, and pdftops in poppler 0.89.0 allows remote attackers to cause a denial of service via crafted input.

In Poppler 22.07.0, PDFDoc::savePageAs in PDFDoc.c callows attackers to cause a denial-of-service (application crashes with SIGABRT) by crafting a PDF file in which the xref data structure is mishandled in getCatalog processing. Note that this vulnerability is caused by the incomplete patch of CVE-2018-20662.

An issue was discovered in freedesktop poppler version 20.12.1, allows remote attackers to cause a denial of service (DoS) via crafted .pdf file to FoFiType1C::convertToType1 function.

References:

https://gitlab.freedesktop.org/poppler/poppler/-/issues/1016

An issue was discovered in freedesktop poppler version 20.12.1, allows remote attackers to cause a denial of service (DoS) via crafted .pdf file to FoFiType1C::cvtGlyph function.