xmlregexp in libxml2 before 2.15.4 has a NULL pointer dereference in xmlRegNewParserCtxt after a strdup failure, i.e., it does not calculate a string length after NULL checking.

Heap out-of-bounds read in =uncompress()= in =gdk-pixbuf/io-icns.c= (function spans lines 192-246 in the current upstream tree). The function decompresses RLE-encoded ICNS icon data but is never given a bound on the source buffer; it loops until it has produced =sizesize= decoded pixels, consuming however many source bytes the RLE stream claims it needs, with no check that any of the three per-iteration reads (the tag byte at =data[0]=, the repeat-value byte at =data[1]=, or the run bytes at =data[i + 1]=) stays inside the block that =loadresources()= computed for it. =loadicon()= holds the correct block size (=isize=, derived from =loadresources()='s =plen = blocklen - sizeof(IcnsBlockHeader)= calculation) but never forwards it to =uncompress()=. A crafted =.icns= file with a truncated RLE block (e.g. an =il32= block whose declared =blocklen= only covers the header, with zero payload bytes) causes =uncompress()= to read past the end of the mapped/allocated ICNS data, an out-of-bounds heap read that can crash the process or leak adjacent heap bytes into the decoded pixel data. All four RLE-compressed ICNS block types (=is32= 16x16, =il32= 32x32, =ih32= 48x48, =it32= 128x128) are affected; the =ic08=/=ic09= (256x256) blocks use JPEG 2000, not this decompressor, and are not affected.

The chunked transfer encoding parser in libsoup uses strtoul(metabuf, NULL, 16) to parse chunk sizes without strict validation. This function silently accepts inputs that violate RFC 9112 §7.1, including leading whitespace, + prefixes, and trailing invalid characters (e.g., 0z parses as 0). When libsoup operates behind a strict frontend proxy, this parsing differential enables an attacker to smuggle HTTP requests through the backend connection. Both server-side (SoupServer) and client-side chunked response parsing are affected. This is distinct from CVE-2026-1801 which covers bare LF tolerance.

Upstream report: https://gitlab.gnome.org/GNOME/libsoup/-/workitems/533 PSIRTSUPT: https://redhat.atlassian.net/browse/PSIRTSUPT-17666

https://gitlab.gnome.org/GNOME/libsoup/-/workitems/506 https://redhat.atlassian.net/browse/PSIRTSUPT-8846

A flaw was found in Glib's content type parsing logic. This buffer underflow vulnerability occurs because the length of a header line is stored in a signed integer, which can lead to integer wraparound for very large inputs. This results in pointer underflow and out-of-bounds memory access. Exploitation requires a local user to install or process a specially crafted treemagic file, which can lead to local denial of service or application instability.

Integer Overflow vulnerability in the gbufferedinputstreampeek() function of the GLib library. The issue is caused by missing validation of the offset and count parameters, leading to an unsafe arithmetic operation during length calculation. When specially crafted values are provided, the offset + count computation may overflow, resulting in an incorrect size being passed to memcpy(). This can trigger a heap or stack buffer overflow and lead to a segmentation fault. Exploitation is subject to strict preconditions and primarily impacts availability by causing application crashes.

Glib-networking: uninitialized memory dereferences on glib-networking through glib-networking/tls/openssl/gtlsbio.c via gtlsbionewfromiostream() and gtlsbionewfromdatagrambased()

A flaw was found in glib. An integer overflow during temporary file creation leads to an out-of-bounds memory access, allowing an attacker to potentially perform path traversal or access private temporary file content by creating symbolic links. This vulnerability allows a local attacker to manipulate file paths and access unauthorized data. The core issue stems from insufficient validation of file path lengths during temporary file operations.

An integer overflow in glib's temporary directory/file creation allows an out of boundary access, which might be used by an attacker to perform path traversal or access to private content of a temporary file by creating symbolic links which an affected application would follow.

A vulnerability was found in libxml2 up to 2.14.5. It has been declared as problematic. This vulnerability affects the function xmlParseSGMLCatalog of the component xmlcatalog. The manipulation leads to uncontrolled recursion. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The real existence of this vulnerability is still doubted at the moment. The code maintainer explains, that "[t]he issue can only be triggered with untrusted SGML catalogs and it makes absolutely no sense to use untrusted catalogs. I also doubt that anyone is still using SGML catalogs at all."

A flaw was found in the GIF parser of GdkPixbuf’s LZW decoder. When an invalid symbol is encountered during decompression, the decoder sets the reported output size to the full buffer length rather than the actual number of written bytes. This logic error results in uninitialized sections of the buffer being included in the output, potentially leaking arbitrary memory contents in the processed image.

Information Disclosure via uninitialized heap memory exposure in GdkPixbuf’s GIF LZW decoder. Upon encountering an invalid LZW symbol, the decoder incorrectly returns the full buffer length instead of the number of decoded bytes written. This oversight leads to uninitialized memory regions in the output image. A crafted GIF can be used to leak memory contents by processing and then reading back the resulting pixbuf.

Stack-based buffer overflow vulnerability in the interactive shell of the xmllint tool in libxml2. The issue is caused by an unsafe use of strcpy() when processing user-supplied command-line input. When an attacker passes an overly long argument to any shell command (e.g., exit, cat, etc.), the input exceeds the fixed-size stack buffer, resulting in a crash or potentially arbitrary code execution on systems lacking stack protections. This vulnerability affects only the interactive shell and requires that an attacker can influence or control the command input to xmllint, which is uncommon in typical deployments.

An integer overflow vulnerability exists in the gstringmaybeexpand() function of the GLib library. When extremely large strings are used and more data is appended, an internal size calculation can wrap around, making the system incorrectly assume that there’s enough space in the buffer. This leads to a buffer overflow, causing memory corruption or a crash. Although difficult to exploit in practice due to the extremely large memory conditions required, this issue could be triggered remotely if an application accepts large untrusted input and uses GString for string operations.

Integer Overflow or Wraparound vulnerability in the cookie parsing logic of the libsoup HTTP client/server library. This issue potentially allows improper handling of cookie expiration dates due to an integer overflow when processing excessively large values. The vulnerability arises from insufficient validation in the conversion logic of cookie expiration timestamps, which can result in undefined behavior. This may enable an attacker to craft malicious cookies that never expire or behave unpredictably, impacting session management and security policies in applications relying on libsoup

libsoup is vulnerable to a null pointer dereference in the soupauthdigestgetprotectionspace() function. An HTTP server may crash the libsoup client by responding with a 401 Unauthorized response in combination with a crafted domain parameter in the WWW-Authenticate header.

GLib prior to 2.84.1 is vulnerable to a denial of service on Windows platforms. If an application attempts to spawn a program using an extremely long command line, it will crash.

GLib prior to 2.82.5 is vulnerable to integer overflow and buffer under-read when parsing a very long invalid ISO 8601 timestamp with gdatetimenewfromiso8601().

Rejected reason: REJECT DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: According to the code maintainer the call of the POC is invalid because the buffer pointed to by "data" must have "len" valid bytes. The docs were updated to make that clear.

GLib's GVariant deserialization code is vulnerable to a denial of service introduced by additional input validation added to resolve CVE-2023-29499. The offset table validation may be very slow. This bug does not affect any released version of GLib, but does affect GLib distributors who followed the guidance of GLib developers to backport the initial fix for CVE-2023-29499

References: https://gitlab.gnome.org/GNOME/glib/-/issues/2841

GLib's GVariant deserialization prior to GLib 2.74.4 is vulnerable to a slowdown issue where a crafted GVariant can cause excessive processing, leading to denial of service.

References: https://gitlab.gnome.org/GNOME/glib/-/issues/2797

GLib's GVariant deserialization prior to GLib 2.74.4 failed to validate the input conforms to the expected format, leading to denial of service.

Referenves: https://gitlab.gnome.org/GNOME/glib/-/issues/2794

GLib's GVariant deserialization prior to GLib 2.74.4 is vulnerable to an exponential blowup issue where a crafted GVariant can cause excessive processing, leading to denial of service.

References: https://gitlab.gnome.org/GNOME/glib/-/issues/2121

fr-archive-libarchive.c in GNOME file-roller through 3.38.0, as used by GNOME Shell and other software, allows Directory Traversal during extraction because it lacks a check of whether a file's parent is a symlink in certain complex situations. NOTE: this issue exists because of an incomplete fix for CVE-2020-11736.

autoar-extractor.c in GNOME gnome-autoar before 0.3.1, as used by GNOME Shell, Nautilus, and other software, allows Directory Traversal during extraction because it lacks a check of whether a file's parent is a symlink in certain complex situations. NOTE: this issue exists because of an incomplete fix for CVE-2020-36241.

Reference and upstream patch: https://gitlab.gnome.org/GNOME/gnome-autoar/-/commit/8109c368c6cfdb593faaf698c2bf5da32bb1ace4

autoar-extractor.c in GNOME gnome-autoar through 0.2.4, as used by GNOME Shell, Nautilus, and other software, allows Directory Traversal during extraction because it lacks a check of whether a file's parent is a symlink to a directory outside of the intended extraction location.

Reference: https://gitlab.gnome.org/GNOME/gnome-autoar/-/issues/7

Upstream patch: https://gitlab.gnome.org/GNOME/gnome-autoar/-/commit/adb067e645732fdbe7103516e506d09eb6a54429

DISPUTED GNOME Evolution through 3.38.3 produces a "Valid signature" message for an unknown identifier on a previously trusted key because Evolution does not retrieve enough information from the GnuPG API. NOTE: third parties dispute the significance of this issue, and dispute whether Evolution is the best place to change this behavior.

fr-archive-libarchive.c in GNOME file-roller through 3.36.1 allows Directory Traversal during extraction because it lacks a check of whether a file's parent is a symlink to a directory outside of the intended extraction location.

The keyfile settings backend in GNOME GLib (aka glib2.0) before 2.59.1 creates directories using gfilemakedirectorywithparents (kfsb->dir, NULL, NULL) and files using gfilereplacecontents (kfsb->file, contents, length, NULL, FALSE, GFILECREATEREPLACEDESTINATION, NULL, NULL, NULL). Consequently, it does not properly restrict directory (and file) permissions. Instead, for directories, 0777 permissions are used; for files, default file permissions are used. This is similar to CVE-2019-12450.

Reference: https://gitlab.gnome.org/GNOME/glib/issues/1658

Upstream commit: https://gitlab.gnome.org/GNOME/glib/commit/5e4da714f00f6bfb2ccd6d73d61329c6f3a08429

The tiffdocumentrender() and tiffdocumentgetthumbnail() functions in the TIFF document backend in GNOME Evince through 3.32.0 did not handle errors from TIFFReadRGBAImageOriented(), leading to uninitialized memory use when processing certain TIFF image files.

Reference: https://gitlab.gnome.org/GNOME/evince/issues/1129