A flaw was found in libsoup. When the permessage-deflate WebSocket extension compresses a very large outgoing message, truncated size calculations used for GByteArray growth could wrap, causing zlib to write past the allocated buffer and resulting in a heap buffer overflow.

A flaw was found in libsoup. When constructing a masked WebSocket client frame for a very large outgoing payload, size values passed to GByteArray allocation APIs could be truncated while the masking routine still used the full length, causing a heap buffer overflow.

A flaw was found in libsoup. When max-incoming-payload-size is unlimited (0), SoupWebsocketConnection could grow its incoming GByteArray based on an attacker-controlled frame length until the length wrapped, causing a heap buffer overflow while reading frame data.

A flaw was found in libsoup. When reassembling fragmented WebSocket messages into a GByteArray, libsoup did not adequately cap total message size against the limits of the underlying buffer type. A remote peer could send fragments that caused size truncation while the implementation still used the full length, leading to heap corruption or a crash.

A flaw was found in libsoup. When handling an incoming WebSocket Pong frame, SoupWebsocketConnection emitted the ::pong signal with a GByteArray pointer even though the signal is declared to pass a GBytes. Applications connecting a handler that follows the documented GBytes API can trigger heap corruption or a crash upon receiving a crafted Pong.

A flaw was found in libsoup. The soupuridecodedatauri() function incorrectly treated base64 data-URI payloads as NUL-terminated strings when calling gbase64decodeinplace(). If the percent-decoded payload contained embedded NUL bytes, the decoded length could remain uninitialized and be used as the size of the returned GBytes. This can lead to an out-of-bounds read or application crash when processing a crafted data URI.

A flaw was found in Foreman. This vulnerability allows an authenticated user with low-level Viewer permissions to cause unauthorized information disclosure by submitting requests to template preview endpoints. By exploiting this issue, the user can access sensitive data, such as host root passwords. Furthermore, under insecure system configurations where Safemode protections are disabled, the flaw may allow the user to execute arbitrary commands as the Foreman system account.

A flaw was found in Foreman. This vulnerability allows an authenticated remote attacker with low-level read permissions to achieve arbitrary code execution on the underlying server. By manipulating the permitted methods list within the template rendering engine, an attacker can bypass the safemode sandbox isolation and execute unauthorized commands directly on the host system.

A flaw was found in the file-psd plugin in GIMP, affecting all versions. When processing a specially crafted PSD image file, the plugin does not properly validate the channel-count parameter. This incorrect validation leads to improper memory bounds checking, resulting in both a heap out-of-bounds read and a stack out-of-bounds access. This issue can result in an application crash, leading to a denial of service or a limited information disclosure of memory contents.

A flaw was found in the file-pvr plugin in GIMP, affecting versions 3.2.0 and newer. When processing a specially crafted PVR image file, the VQ (compressed) decoder does not properly perform memory bounds checking. This missing validation results in a heap out-of-bounds read. This issue can result in an application crash, leading to a denial of service or a limited information disclosure of heap memory contents.

A flaw was found in the file-ico plugin in GIMP, affecting all versions. When processing a specially crafted ICO image file, the plugin does not properly validate the usedclrs (palette count) parameter. This incorrect validation leads to improper memory bounds checking, resulting in a heap out-of-bounds read. This issue can result in an application crash, leading to a denial of service or a limited information disclosure of heap memory contents.

A flaw was found in the file-iff (IFF/ILBM) plugin in GIMP, affecting versions 3.0.0 and newer. When processing a specially crafted IFF/ILBM image file, the plugin does not properly validate the HAM row size and improperly handles cases where the number of color planes (nPlanes) is zero. This causes a row size mismatch that bypasses memory bounds checking, resulting in heap out-of-bounds reads. This issue can result in an application crash, leading to a denial of service or a limited information disclosure of heap memory contents.

A flaw was found in the file-xwd plugin in GIMP. When processing a specially crafted XWD image file, the plugin validates the image width and bytes-per-line parameters independently rather than ensuring their combined values are consistent with the allocated buffer size. This incorrect validation leads to improper bounds checking, causing a heap out-of-bounds read. This issue can result in an application crash, leading to a denial of service or a limited information disclosure of heap memory contents into the produced image.

A flaw was found in the file-pix (ESM) plugin in GIMP, affecting versions 3.0.0 and newer. When processing a specially crafted PIX image file, the plugin allocates a Variable-Length Array (VLA) on the stack without proper bounds checking, causing an unbounded stack allocation followed by a 21-byte stack over-read. This can result in a denial of service due to stack exhaustion and a limited information disclosure of stack memory contents into an intermediate file.

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 GStreamer gst-plugins-good (avidemux). In gstavidemuxriffparsevprp(), the number of available gstriffvprpvideofielddesc entries is calculated by dividing the remaining buffer size by the attacker-controlled vprp->fields value, rather than by sizeof(gstriffvprpvideofielddesc). This can cause the parser to treat more field descriptors as available than fit in the input buffer, resulting in out-of-bounds reads. Processing a crafted AVI via playbin/decodebin can crash the application (denial of service). Fixed upstream in gst-plugins-good 1.28.6 (GStreamer-SA-2026-0072).

A flaw was found in GStreamer gst-plugins-good (avidemux). When parsing FUJIFILM metadata in an AVI strd chunk, gstavidemuxparsestrd() decrements a remaining-length counter by fixed offsets (98 and 10 bytes) without verifying sufficient data remains. For crafted strd payloads of exactly 106 or 107 bytes, the counter underflows to a very large unsigned value, causing subsequent null-terminated string scanning to read far beyond the allocated heap buffer. Date-format normalization may also write beyond the buffer end. Confirmed impacts include heap out-of-bounds read, out-of-bounds write, heap information disclosure (adjacent data appearing in parsed metadata), and application crash/denial of service. The avidemux element is auto-plugged by playbin, decodebin, and gst-discoverer, so opening or previewing a crafted AVI is sufficient to trigger the issue. Fixed upstream in gst-plugins-good 1.28.6 (GStreamer-SA-2026-0072).

A flaw was found in libdm. A local attacker could craft a malicious Logical Volume Manager (LVM) metadata configuration with deeply nested structures. This could lead to uncontrolled recursion in the libdm configuration file parser, exhausting the stack and causing any LVM command reading the metadata to crash. This vulnerability results in a Denial of Service (DoS) for affected systems.

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 gfs2-utils. In the gfs2edit tool, the metapathtolblock() function in extended.c uses the diheight field from on-disk inode metadata as an array index into a fixed-size stack array factor[GFS2MAXMETAHEIGHT] (10 elements) without bounds validation. An attacker can craft a GFS2 filesystem image with diheight exceeding 10 (up to 65535) to write past the end of the array, corrupting adjacent stack memory including saved registers and the return address. The subsequent loop (factor[h] = factor[h+1] sbd.sdinptrs) amplifies the corruption by writing additional entries past the array boundary. This is a classic stack buffer overflow that may allow arbitrary code execution when gfs2edit processes the crafted image. The Linux kernel GFS2 driver validates diheight against sdmaxheight in gfs2dinodein(), but the userspace gfs2-utils performs no equivalent validation.

A flaw was found in gfs2-utils. The eanumptrs field from on-disk extended attribute metadata is used as a loop count in savemeta.c and metawalk.c without bounds validation. The eanumptrs field is a u8 (max 255). Each iteration reads a pointer (8 bytes) plus name data. With eanumptrs=255 and a 512-byte block buffer, the loop reads up to 1384 bytes past the buffer boundary, causing a heap out-of-bounds read. This may disclose sensitive heap memory contents through tool output or error messages, and the significant over-read (2.7x the allocation) has a non-trivial probability of crossing a page boundary into unmapped memory, causing a crash.

A flaw was found in gfs2-utils. In the savemeta function in savemeta.c, the height value from on-disk inode metadata controls a loop over a fixed-size stack array (10 elements) without bounds validation. An attacker can craft a GFS2 filesystem image with a height value exceeding 10 to write past the end of the array, corrupting adjacent stack memory. This is the same vulnerability class as the diheight OOB write in gfs2edit (extended.c) but in a different code path. The stack buffer overflow may allow arbitrary code execution when savemeta processes the crafted image. The Linux kernel GFS2 driver validates iheight against sdmaxheight in gfs2dinodein(), but the userspace gfs2-utils performs no equivalent validation.

A flaw was found in gfs2-utils. The metadata walk code in metawalk.c uses alloca((height + 1) sizeof(metalist)) where height is the iheight field from the on-disk inode (uint16, max 65535, valid range 0-10). No bounds validation is performed before the alloca call. An attacker can craft a GFS2 filesystem image with a large iheight value to cause excessive stack allocation (~1MB for iheight=65535 with sizeof(osilistt)=16), leading to stack exhaustion and a denial of service (SIGSEGV). The metadata walk in metawalk.c involves recursive traversal, and each level could invoke this alloca, compounding the stack usage. The Linux kernel GFS2 driver validates iheight against sdmaxheight in gfs2dinodein() and stores it as u8, but the userspace gfs2-utils performs no equivalent validation.

A flaw was found in 389 Directory Server (389-ds-base). In idssaslcheckbind(), on a successful SASLOK from the underlying Cyrus SASL library, the connection is marked SASL-complete and bind credentials are installed via bindcredentialssetnolock() before the account-lock check (slapicheckaccountlock()) is performed for non-root binds. If the subsequent lock check determines the account is locked (nsAccountLock: true), the bind is failed and reported to the client, but the already-installed SASL-complete flag and bind credentials are not reverted. A client that already knows the correct password for an account that has since been administratively locked can bind via SASL PLAIN, receive an "account locked" failure response, and continue using the same, already-authenticated TCP connection to perform further LDAP operations as that account -- defeating account lock as an access-revocation control. Setting nsslapd-close-on-failed-bind does not mitigate this. This finding was independently reported by two unrelated parties (OpenAI Security Research and Andrew Rukin of Arenadata) who converged on the identical root cause.

A flaw was found in GNU tar. The --one-top-level option is intended to confine extraction under a designated directory, but hardlink targets from the archive are not confined the same way and are resolved relative to the extraction working directory (or the directory given with -C). A crafted archive can create hardlinks inside the --one-top-level directory that point to files outside it. If a suitable symbolic link already exists under the extraction working directory, hardlinking to that symlink can bypass tar's usual symlink-based path protections and allow writing outside the intended top-level directory during a single extraction. Users who rely on --one-top-level as a security boundary when extracting untrusted archives may be affected.

A flaw was found in SSSD. The sssnssprotocolparseaddr() function in the NSS responder (src/responder/nss/nssprotocol.c) extracts a 32-bit addrlen value from the client request but only validates that the body is at least 8 bytes, without checking that addrlen fits within the remaining packet body. This unvalidated length is passed through to tallocmemdup() in cachereqdatacreate(), which copies addrlen bytes from the small request buffer, causing a heap-buffer-overflow read. A local attacker can trigger this by connecting to the world-writable NSS responder socket (/var/lib/sss/pipes/nss) and sending a SSSNSSGETHOSTBYADDR (0x0053) request with a large addrlen value and a valid address family payload so that inetntop() succeeds. Successful exploitation crashes the sssdnss responder, causing a denial of service for NSS name resolution. Reported via PSIRTSUPT-20553 by BreachX Zero Day Labs.

A flaw was found in SSSD. The sssnssprotocolfillinitgr() function in the NSS responder (src/responder/nss/nssprotocolgrent.c) pre-allocates the reply packet for all group entries using ssspacketgrow() but does not shrink the packet when groups are skipped (non-POSIX, incomplete, or filtered groups). ssspacketgrow() uses tallocreallocsize(), which does not zero-fill newly allocated memory. The trailing unwritten bytes therefore contain uninitialized heap data from the sssdnss process and are transmitted to the client at the grown packet length. A local attacker can exploit this by sending SSSNSSINITGR (0x0026) requests to the world-writable NSS responder socket (/var/lib/sss/pipes/nss), receiving uninitialized heap content in the reply tail. Through heap grooming (for example, a preceding getpwnam query), the leak can disclose other users' cached directory records and process heap pointers. The leaked data is limited to the sssdnss heap (directory-level information); credentials reside in separate sssdpam and sssdbe processes. Reported via PSIRTSUPT-20553 by BreachX Zero Day Labs.

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 TOCTOU (Time-of-Check Time-of-Use) vulnerability in GNU tar's incremental dumpdir 'X' rename handling allows a local attacker with write access to a directory being backed up to influence the restore process if the attacker has access to the system where the restore is being performed. During restoration, files or directories may be created, renamed or overwritten outside the intended extraction directory. This could lead to unauthorized file modification or, in some cases, privilege escalation. Exploitation does not require the attacker to modify or craft the archive, and standard backup and restore workflows—including extracting into a newly created directory without using the -P option do not mitigate the issue.

This is a vulnerability report sent to us through https://issues.redhat.com/browse/PSIRTSUPT-17918 and was created using the PoC auto-triage agents. It contains hints on the vulnerability extracted by the IA and the full report. ALWAYS review it before any action. Once working on this, don't forget to also update the JSM ticket.

Multiple Use-After-Free vulnerabilities were found in the addarchiveelement function in ld/ldmain.c of the GNU linker (ld), a component of binutils. The root cause is that pluginmaybeclaim() in ld/plugin.c frees the original BFD object via bfdclose/bfddeletebfd when entry->thebfd->myarchive == NULL, but the caller retains both the original abfd parameter and a shallow copy (originput.thebfd) as dangling pointers. These dangling pointers are subsequently dereferenced at three distinct locations in addarchiveelement:

1. Line ~1442: accessing abfd->myarchive via bfdusrdata(abfd->myarchive) 2. Line ~1493: multiple accesses to abfd and abfd->myarchive in a conditional check and bfdgetfilename call 3. Line ~1525: dereferencing the shallow copy originput.thebfd->myarchive in trace/verbose logging

The vulnerability is triggered when LTO plugins are active (linkinfo.ltopluginactive is true) and the input object has abfd->myarchive == NULL, which is a valid state for standalone object files. Red Hat builds binutils with --enable-plugins and --enable-lto, confirming the vulnerable code path is compiled in and reachable.

An attacker who can supply a crafted object or archive file to a build process using LTO-enabled linking could exploit this flaw to cause a denial of service (linker crash via segmentation fault). Arbitrary code execution is theoretically possible through heap manipulation but is substantially mitigated by hardening measures including stack protector, FORTIFYSOURCE, ASLR, and PIE.

The attack surface is limited to build-time environments — the linker is a development tool not exposed in production runtime. The most realistic exploitation scenario is a supply chain attack introducing a crafted object file as a build dependency in CI/CD pipelines or development environments.