A privilege escalation flaw was found in FreeIPA. The uniqueness constraint enforced on Kerberos principal name attributes in the 389-ds directory server does not properly account for equivalent representations of the same principal name, allowing a user with sufficient LDAP write privileges to create a service principal that impersonates an existing privileged one. This can lead to unauthorized acquisition of Kerberos service tickets for sensitive services, potentially resulting in full domain compromise.
A flaw was found in FreeIPA. The trust-fetch-domains command, used to refresh Active Directory trust topology, is gated only by the read-level ACI on the trust object (System: Read Trust Information, granted to any authenticated IPA user by default) rather than a trust-administration-level permission. Any authenticated, non-privileged IPA user can therefore invoke ipa trust-fetch-domains, which calls a root-owned oddjobd/D-Bus helper (install/oddjob/com.redhat.idm.trust-fetch-domains.in). When the caller supplies --admin/--password, the helper calls kinitpassword() against a caller-chosen --server using attacker-supplied credentials, with no cross-check that they belong to the real trusted AD forest, then accepts whatever forest-trust topology (domain names, NetBIOS names, SIDs) that attacker-controlled server returns via ipaserver/dcerpc.py's fetchdomains()/discovertrustinstance(). This fabricated data is written directly into the IPA LDAP directory as authoritative trust/ID-range topology by trust.addnewdomainsfromtrust(). The authorization gap itself (an unprivileged, non-admin user's request reaching the root-owned helper's execution with no ACI rejection) was reproduced dynamically in an isolated sandbox against ipa-server-4.13.5, confirmed against a negative control (an unrelated admin-only operation was correctly rejected in the same session). The exploiting principal holds zero delegated privilege — this is not a case of a narrow administrative delegation being used beyond its intended scope.
A flaw was found in SSSD. The extractauthtokv1() function in the PAM responder (src/responder/pam/pamsrvcmd.c) reads a 32-bit authtokenlength from the client request but does not validate it against the remaining buffer size before passing it to sssauthtoksetpassword(). When sssauthtoksetstring() processes the token, it accesses str[len-1] using the unvalidated length, resulting in a heap-buffer-overflow read. A local attacker can trigger this by connecting to the world-writable PAM responder socket (/var/lib/sss/pipes/pam) and sending a crafted protocol v1 authentication request with an oversized authtokenlength value. The stock PAM client uses protocol v3, so this is only reachable via raw socket access. Protocol v2 includes an equivalent bounds check (c+datasize > blen), which is missing from v1. Successful exploitation crashes the sssdpam responder, causing a denial of service for SSSD-mediated authentication. Reported via PSIRTSUPT-20553 by BreachX Zero Day Labs.
A flaw was found in the file-icns plugin in GIMP, affecting versions 2.99.14 and newer. When applying a decompressed mask during ICNS image processing, the plugin reads from the mask data buffer without verifying if the cursor exceeds the allocated resource size. If a crafted file contains a truncated mask resource, the icnsdecompress function continues reading past the bounds of the buffer. This out-of-bounds read vulnerability results in information disclosure of heap contents, where memory contents are leaked as alpha channel pixel values, or a crash leading to a denial of service if unmapped memory is accessed.
A flaw was found in the file-fits plugin in GIMP, affecting all versions. When processing a FITS image file, the plugin calculates memory allocation sizes using signed 32-bit integers for width and height. If a crafted file sets both values to large values, their product exceeds 2^31 and overflows, resulting in an undersized heap-based buffer allocation. This integer overflow issue results in a heap-based buffer overflow when cfitsio subsequently writes a full row of pixels in the buffer, causing memory corruption, potentially leading to arbitrary code execution or a denial of service.
A flaw was found in libsoup. The chunked transfer encoding parser uses a permissive parsing function for chunk sizes that silently accepts inputs violating RFC 9112, including leading whitespace, plus sign prefixes, and trailing invalid characters. When libsoup operates behind a strict frontend proxy, this parsing differential can be exploited to smuggle HTTP requests.
A configuration-dependent issue in rsyslog's optional imptcp input module can allow an unauthenticated remote peer to crash rsyslogd. The issue is not active in a default installation. Exploitation requires all of the following:
imptcp is explicitly loaded. An imptcp listener uses the non-default framing.delimiter.regex mode. An attacker can establish a TCP connection to that listener.
A crafted input sequence during oversize-frame recovery can cause an invalid internal message length and terminate rsyslogd. No confidentiality or integrity impact, privilege escalation, or code execution has been identified. imtcp and the default imptcp framing modes are not affected.
A flaw was found in 389 Directory Server (389-ds-base). The getruvelementfromberval() function in ldap/servers/plugins/replication/repl5ruv.c copies digit characters from a network-supplied RUV berval into a fixed 16-byte stack buffer (ridbuff[RIDSTRSIZE]) without bounds checking the loop counter. A remote unauthenticated attacker can crash the ns-slapd process by sending a crafted StartNSDS50ReplicationRequest LDAP extended operation (OID 2.16.840.1.113730.3.5.12) containing more than 16 consecutive digit characters in the replica ID field. The overflow occurs during payload decoding in decodestartreplextop(), before the replicaisupdatedn() authorization check runs, making it exploitable without credentials on default configurations where anonymous access is enabled. On production builds with stack protectors, the impact is limited to denial of service (process abort). The vulnerable code path is: decodestartreplextop() -> decoderuv() -> ruvinitfrombervals() -> getruvelementfromberval().
A flaw was found in libssh builds using the OpenSSL backend for AES-GCM. In the decrypt path in src/libcrypto.c, the return value from EVPDecryptFinal() was checked incorrectly, so authentication tag verification failures were not handled as integrity failures. This could effectively remove integrity protection for affected AES-GCM sessions and allow an in-path attacker to modify plaintext on the wire without detection.
A flaw was found in libssh channel data handling. In channelrcvdata() in src/channels.c, incoming channel DATA messages could still be processed after the channel had already been marked as remotely closed. In SFTP-backed applications and other callback-driven consumers, this creates a path where data callbacks may observe channel-associated state after it has already been torn down or freed, leading to crashes and possible use-after-free conditions.
A flaw was found in GIMP's file format plugins, including those for PSD and PAA files. A remote attacker could exploit these vulnerabilities by tricking a user into opening a specially crafted image file. This could lead to unexpected application behavior or other potential security impacts without requiring further user interaction.
A flaw was found in the GIMP image manipulation program, specifically within its Seattle Filmworks file loader. A remote attacker could exploit this vulnerability by tricking a user into opening a specially crafted Seattle Filmworks file. This could lead to a heap overflow, allowing the attacker to write several kilobytes of controlled data beyond the intended memory buffer. Such an overflow can result in memory corruption, potentially leading to arbitrary code execution or a denial of service.
A flaw was found in GIMP's PNM file format parser. When parsing a specially crafted PNM file, the pnmscannergettoken() function writes a null terminator one byte past the end of a stack-allocated buffer due to an off-by-one error in the loop boundary check. This could lead to memory corruption, potentially resulting in denial of service or arbitrary code execution.
A flaw was found in Yelp due to an overly permissive Content Security Policy (CSP) implementation provided by yelp-xsl. A malicious Flatpak application can open crafted help content through the OpenURI portal. By embedding an untrusted CSS stylesheet within a structured SVG document, attacker-controlled content can bypass Flatpak's intended sandbox isolation, allowing Yelp to evaluate local XML inclusions and disclose arbitrary user-readable host files through remote CSS resource requests. This may result in the unauthorized disclosure of sensitive information.
In the Linux kernel, the following vulnerability has been resolved:
drm/gem: Try to fix changehandle ioctl, attempt 4
[airlied: just added some comments on how to reenable] On-list because the cat is out of the bag and we're clearly not good enough to figure this out in private. The story thus far:
5e28b7b94408 ("drm: Set old handle to NULL before prime swap in changehandle") tried to fix a race condition between the gemclose and gemchangehandle ioctls, but got a few things wrong:
- There's a confusion with the local variable handle, which is actually the new handle, and so the two-stage trick was actually applied to the wrong idr slot. 7164d78559b0 ("drm/gem: fix race between changehandle and handledelete") tried to fix that by adding yet another code block, but forgot to add the error handling. Which meant we now have two paths, both kinda wrong.
- dc366607c41c ("drm: Replace old pointer to new idr") tried to apply another fix, but inconsistently, again because of the handle confusion - this would be the right fix (kinda, somewhat, it's a mess) if we'd do the two-stage approach for the new handle. Except that wasn't the intent of the original fix.
We also didn't have an igt merged for the original ioctl, which is a big no-go. This was attempted to address off-list in the original bugfix, and amd QA people claimed the bug was fixed now. Very clearly that's not the case. Here's my attempt to sort this out:
- Rename the local variable to newhandle, the old aliasing with args->handle is just too dangerously confusing.
- Merge the gem obj lookup with the two-stage idrreplace so that we avoid getting ourselves confused there.
- This means we don't have a surplus temporary reference anymore, only an inherited from the idr. A concurrent gemclose on the newhandle could steal that. Fix that with the same two-stage approach createtail uses. This is a bit overkill as documented in the comment, but I also don't trust my ability to understand this all correctly, so go with the established pattern we have from other ioctls instead for maximum paranoia.
- Adjust error paths. I've tried to make the error and success paths common, because they are identical except for which handle is removed and on which we call idrreplace to (re)install the object again. But that made things messier to read, so I've left it at the more verbose version, which unfortunately hides the symmetry in the entire code flow a bit.
- While at it, also replace the 7 space indent with 1 tab.
And finally, because I flat out don't trust my abilities here at all anymore:
- Disable the ioctl until we have the igt situation and everything else sorted out on-list and with full consensus.
v2:
Sashiko noticed that I didn't handle the error path for idrreplace correctly, it must be checked with ISERRORNULL like in gemhandledelete. So yeah, definitely should just the existing paths 1:1 because this is endless amounts of tricky.
Also add the Fixes: line for the original ioctl, I forgot that too.
A flaw was found in GLib. The D-Bus client-side implementation of the DBUSCOOKIESHA1 SASL authentication mechanism does not validate the cookiecontext parameter received from the server. A malicious D-Bus server can supply a cookiecontext containing path traversal sequences, causing the client to read an arbitrary file and exfiltrate sensitive data by verifying guessed file contents against a generated hash.
A flaw was found in GLib. An off-by-one error can occur in the gkeyfilegetlocalestringlist function in the gkeyfile.c file when loading a key file with an empty value. This flaw can cause an out-of-bounds access of 1 byte or a denial of service when the out-of-bounds access crosses a page boundary.
A flaw was found in GLib. A buffer over-read can occur in giochannelreadlinebackend() in the giochannel.c file when a custom line terminator with a length greater than one is set, causing memcmp to read past the GString buffer. This vulnerability can cause a minor information disclosure of 7 bytes or a denial of service when the buffer over-read crosses a page boundary.
A flaw was found in GLib. A buffer over-read can occur in the gregexreplace function when used with the GREGEXRAW compile flag and case-change replacement escapes because the stringappend function processes matched substrings using UTF-8 functions that assume valid UTF-8 input, even when the string is treated as raw bytes. This vulnerability can cause a minor information disclosure of 1-5 bytes and a denial of service when the buffer over-read crosses a page boundary.
A flaw was found in GLib. An out-of-bounds read of only 2 bytes can occur in the gdatetimegetymd function in the glib/gdatetime.c file when an invalid GDateTime object produced by the gdatetimeaddfull function is processed. This flaw can corrupt the date output and potentially cause logic errors that may lead to a denial of service.
ice: fix double-free of txbuf skb
A flaw was found in GLib. An off-by-one error can occur in the gvstupleisnormal function in the glib/gvariant-serialiser.c file when doing an alignment padding check because the bounds check uses > instead of >=, causing an out-of-bounds read of only 1 byte. This issue can cause a minor information disclosure of 1 byte and a denial of service when the out-of-bounds read crosses a page boundary.
A symlink following vulnerability was found in the ABRT post-create event handler scripts in /etc/libreport/events.d/abrtevent.conf. Event scripts write output files using shell redirections (e.g., "printf ... > $DUMPDIR/varlogmessages") which use open() with OWRONLY|OCREAT|OTRUNC without the ONOFOLLOW flag. If the target file is replaced with a symlink, the shell process (running as root in the abrthandleeventt SELinux domain, which is effectively unconfined) follows the symlink and writes content to the symlink target. In contrast, ddsavetext (used by SetElement) correctly uses ONOFOLLOW. An attacker who has gained filesystem control of the dump directory can replace output files with symlinks pointing to sensitive system files such as /var/spool/cron/root.
image-size through 2.0.2 contains a denial of service vulnerability that allows remote attackers to permanently block the Node.js event loop by supplying a specially crafted image buffer with a zero-valued size field in a recognized box-type. Attackers can trigger an infinite loop in the JXL or HEIF image parsers by providing a crafted image containing a box with a size of zero, causing the offset to never advance and permanently hanging the application.
A flaw was found in 389 Directory Server. The dereference control plugin does not check for allocation failure before using a BER structure, allowing an unauthenticated remote attacker to crash the LDAP server when the system is under memory pressure.
A client that requests multiple DRI2BufferBackLeft attachments and one DRI2BufferFrontLeft can trigger an out-of-bounds heap write in DRIGetBuffers/DRIGetBuffersWithFormat.
Any local X client that can connect to the server can trigger this issue. This may be used to crash the server, or for privilege escalation if the X server runs as root.
Components affected: xorg-x11-server, xorg-x11-server-Xwayland Versions affected: xorg-x11-server <= 21.1.22, xorg-x11-server-Xwayland <= 24.1.9
Fixed upstream in xorg-server-21.1.23 and xwayland-24.1.12. Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/339c279514326134b0878fc23ce6e9520440ce7f
Identified by Peter Hutterer, Red Hat. Tracking: PSIRTSUPT-16950.
A client that sets up multiple SyncCounters can trigger a use-after-free when destroying those counters via a second client connection while changing those counters in SyncChangeCounter().
Any X client that can connect to the server can trigger this issue. This may be used to crash the server, or for privilege escalation if the X server runs as root.
Components affected: xorg-x11-server, xorg-x11-server-Xwayland Versions affected: xorg-x11-server <= 21.1.22, xorg-x11-server-Xwayland <= 24.1.9
Fixed upstream in xorg-server-21.1.23 and xwayland-24.1.12. Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/bdd7bf57af208b1ddf57d4683d67104443b44812
Reported via ZDI-CAN-30164 (Trend Micro Zero Day Initiative). Tracking: PSIRTSUPT-16950.
XkbSetMapChecks() declares a fixed-size stack buffer mapWidths[256] indexed by key type index. The helper function CheckKeyTypes() writes to this buffer at a client-controlled offset, allowing a stack buffer overflow.
Any X client that can connect to the server can trigger this issue. This may be used to crash the server, or for privilege escalation if the X server runs as root.
Components affected: xorg-x11-server, xorg-x11-server-Xwayland Versions affected: xorg-x11-server <= 21.1.22, xorg-x11-server-Xwayland <= 24.1.9
Fixed upstream in xorg-server-21.1.23 and xwayland-24.1.12. Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/867b59b33bee669cb412f1314e47c52eacf6e00b
Reported via ZDI-CAN-30161 (Trend Micro Zero Day Initiative). Tracking: PSIRTSUPT-16950.
A client that sets up multiple fence triggers can trigger a use-after-free function pointer call in miSyncDestroyFence(). An attacker connects to the X server to set up a fence and awaits that fence, then a second X connection destroys the fence, causing the use-after-free.
Any X client that can connect to the server can trigger this issue. This may be used to crash the server, or for privilege escalation if the X server runs as root.
Components affected: xorg-x11-server, xorg-x11-server-Xwayland Versions affected: xorg-x11-server <= 21.1.22, xorg-x11-server-Xwayland <= 24.1.9
Fixed upstream in xorg-server-21.1.23 and xwayland-24.1.12. Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/f5abfb61994471023d8c6470428c8e30c411cc0b
Reported via ZDI-CAN-30159 (Trend Micro Zero Day Initiative). Tracking: PSIRTSUPT-16950.
A client that sets up multiple SyncCounters and awaits on those triggers can trigger a use-after-free when destroying those counters via a second client connection in FreeCounter().
Any X client that can connect to the server can trigger this issue. This may be used to crash the server, or for privilege escalation if the X server runs as root.
Components affected: xorg-x11-server, xorg-x11-server-Xwayland Versions affected: xorg-x11-server <= 21.1.22, xorg-x11-server-Xwayland <= 24.1.9
Fixed upstream in xorg-server-21.1.23 and xwayland-24.1.12. Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/f5abfb61994471023d8c6470428c8e30c411cc0b
Reported via ZDI-CAN-30163 (Trend Micro Zero Day Initiative). Tracking: PSIRTSUPT-16950.