gio/gsocks4aproxy.c in GNOME GLib before 2.82.1 has an off-by-one error and resultant buffer overflow because SOCKS4CONNMSGLEN is not sufficient for a trailing '\0' character.

An issue was discovered in GNOME GLib before 2.78.5, and 2.79.x and 2.80.x before 2.80.1. When a GDBus-based client subscribes to signals from a trusted system service such as NetworkManager on a shared computer, other users of the same computer can send spoofed D-Bus signals that the GDBus-based client will wrongly interpret as having been sent by the trusted system service. This could lead to the GDBus-based client behaving incorrectly, with an application-dependent impact.

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, which is vulnerable to an integer overflow in the gstringinsertunichar() function. When the position at which to insert the character is large, the position will overflow, leading to a buffer underwrite.

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 state confusion issue exists in gdbusnodeinfonewforxml() in the gio/gdbusintrospection.c file when processing malformed D-Bus introspection XML, specifically with a node element nested within other elements like method, signal, property or arg. This issue can cause an unsigned integer overflow and lead to an out-of-bounds read, resulting in a denial of service.

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.

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. 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 heap-based buffer overflow problem was found in glib through an incorrect calculation of buffer size in the gescapeuristring() function. If the string to escape contains a very large number of unacceptable characters (which would need escaping), the calculation of the length of the escaped string could overflow, leading to a potential write off the end of the newly allocated string.

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.

GLib prior to 2.84.2 is vulnerable to an integer overflow in the gstringinsertunichar() function. When the position at which to insert the character is large, the position will overflow, leading to buffer under-write.

A flaw was found in GLib. GVariant deserialization is vulnerable to a slowdown issue where a crafted GVariant can cause excessive processing, leading to denial of service.

A flaw was found in glib, where the 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.

A flaw was found in GLib. GVariant deserialization is vulnerable to an exponential blowup issue where a crafted GVariant can cause excessive processing, leading to denial of service.

A flaw was found in GLib. The GVariant deserialization code is vulnerable to a heap buffer overflow introduced by the fix for CVE-2023-32665. 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-32665.

A flaw was found in GLib. GVariant deserialization fails to validate that the input conforms to the expected format, leading to denial of service.

A buffer-underflow vulnerability exists in GLib’s GVariant parser, specifically within bytestringparse() and stringparse(). The parser uses signed 32-bit integers (gint) as loop indices (i and j). When extremely large strings are parsed, these counters overflow into negative values, causing the parser to write to memory before the start of the allocated buffer (str[j++]). This results in a classic out-of-bounds write condition. Because GVariant parsing is often performed on attacker-influenced data, a remote attacker can trigger heap corruption, causing a crash or potentially achieving code execution. This flaw has been confirmed by maintainers and patched upstream.

A flaw was found in glib. This vulnerability allows a heap buffer overflow and denial-of-service (DoS) via an integer overflow in GLib's GIO (GLib Input/Output) escapebytestring() function when processing malicious file or remote filesystem attribute values.

An integer wraparound was discovered in glib due to passing a 64 bit sized value to function gmemdup() which accepts a 32 bits number as argument. An attacker may abuse this flaw when an application linked against the glib library uses gbytesnew() function or possibly other functions that use gmemdup() underneath and accept a 64 bits argument as size. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

An issue was discovered in GNOME GLib before 2.66.7 and 2.67.x before 2.67.4. If gbytearraynewtake() was called with a buffer of 4GB or more on a 64-bit platform, the length would be truncated modulo 232, causing unintended length truncation.

An issue was discovered in GNOME GLib before 2.66.8. When gfilereplace() is used with GFILECREATEREPLACEDESTINATION to replace a path that is a dangling symlink, it incorrectly also creates the target of the symlink as an empty file, which could conceivably have security relevance if the symlink is attacker-controlled. (If the path is a symlink to a file that already exists, then the contents of that file correctly remain unchanged.)

gvstupleisnormal() in glib/gvariant-serialiser.c:1253 has an off-by-one error in its alignment padding check. When checking whether padding bytes are zero, the bounds check uses > instead of >=, allowing a 1-byte out-of-bounds read when offset == value.size.

A heap-buffer-overflow READ vulnerability exists in GLib's gregexreplace() function when used with GREGEXRAW compile flag and case-change replacement escapes (\U, \L, \u, \l). In GREGEXRAW mode, PCRE2 treats the subject string as raw bytes rather than UTF-8. Matched substrings can therefore contain arbitrary byte sequences that are not valid UTF-8. When the replacement string contains case-change escapes (e.g., \U\0 to uppercase the match), the internal stringappend() function processes the matched substring using UTF-8 functions (gutf8getchar(), gutf8nextchar()) which assume valid UTF-8 input. A multi-byte UTF-8 lead byte (e.g., 0xF4 indicating a 4-byte sequence) in the matched data causes these functions to read beyond the heap-allocated buffer.

This vulnerability stems from an integer overflow in GLib’s GIO escapebytestring() function, where the count of invalid characters is multiplied using a signed integer, resulting in a too-small memory allocation for escaped output. When a malicious file or remote filesystem supplies attribute values with a large number of invalid bytes, the subsequent escaping loop writes beyond the allocated buffer, triggering a heap buffer overflow and crashing the process.

An overflow problem was found in glib through an incorrect calculation of buffer size in the gescapeuristring() function. If the string to escape contains a very large number of unacceptable characters (which would need escaping), the calculation of the length of the escaped string could overflow, leading to a potential write off the end of the newly allocated string.

gio/gsocks4aproxy.c in GNOME GLib before 2.82.1 has an off-by-one error and resultant buffer overflow because SOCKS4CONNMSGLEN is not sufficient for a trailing '\0' character.

Integer Overflow leads to Buffer Underflow vulnerability in GLib’s Base64 encoding implementation. The flaw is caused by storing the output length returned by gbase64encodestep() in a signed integer (gint). When encoding very large attacker-controlled input, this value may overflow and become negative. The resulting pointer arithmetic in gbase64encodeclose() leads to a buffer underflow and out-of-bounds heap write. Exploitation requires that an application passes untrusted or excessively large input to the Base64 encoding API and may result in application crashes or potential memory corruption.

Integer Overflow vulnerability in GLib’s Unicode case conversion implementation. The flaw is caused by mixing signed and unsigned integer types when calculating output buffer lengths across outputmarks() and realtolower(). An integer overflow can result in an undersized heap allocation followed by out-of-bounds writes during UTF-8 character conversion. Exploitation requires an application to process attacker-controlled large Unicode input and may result in crashes or potential memory corruption.