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. 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 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.

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. 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.

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.

On 5/20/26 05:51, Simon McVittie wrote: On Tue, 19 May 2026 at 19:30:42 -0400, Aaron Rainbolt wrote: I wonder if it would be worth proposing a change to whatever system component handles opening files (probably something in Glib, or xdg-utils, haven't researched that deeply yet) It's a general-purpose specification that is designed to be implemented by an unlimited number of packages, some of them desktop-specific:

GLib, and via that, gio(1), xdg-desktop-portal and flatpak-xdg-utils' xdg-open(1) reimplementation some Qt/KDE library (I'm less familiar with the KDE world, so I don't know whether this is done in the Qt layer or somewhere in kdelibs) xdg-utils' xdg-open(1) (the reference implementation of that name) Debian's mailcap package, which translates fd.o MIME handlers into traditional mailcap(5) handlers web browsers like Firefox and Chromium might reimplement it? not sure ...

so any change to how the spec is to be implemented would have to be fd.o consensus and spread across all of those. Honestly, I think the open-ended nature makes it inherently insecure.

Sandboxes should only allow allowlist of file types and make everything else fall back to a safe default. This could be a simple text editor (no IDE support!) for text files, and a hex editor (or an error) for binary files. -- Sincerely, Demi Marie Obenour (she/her/hers)

I wonder if it would be worth proposing a change to whatever system component handles opening files (probably something in Glib, or xdg-utils, haven't researched that deeply yet), so that handlers cannot be registered for certain "dangerous" file types (i.e. ELF/PE/Mach-O executables, scripts in various languages, etc.)? The only real downside I can see to that is the inability to text editors to register themselves as handlers for script MIME types, and in those instances, the editor can register itself as the handler for another applicable, more generic MIME type (i.e. text/plain), then change its behavior based on the more detailed MIME type of the file after it opens it.

(or other potentially malicious actions), can register a wrapper :

Exec=wine-prompt %F Alternatively: Exec=wine --prompt-user %F a native executable or a .desktop file.

The .desktop format could be extended with an additional entry such as:

bike-shed name: Unsafe-Exec=wine %F prompt wrapper.

A caller implementing this extension, could ask for confirmation itself and then call the unsafe command.

Gabriel

On Tue, 19 May 2026 at 19:30:42 -0400, Aaron Rainbolt wrote: I wonder if it would be worth proposing a change to whatever system component handles opening files (probably something in Glib, or xdg-utils, haven't researched that deeply yet)

GLib, and via that, gio(1), xdg-desktop-portal and flatpak-xdg-utils' xdg-open(1) reimplementation some Qt/KDE library (I'm less familiar with the KDE world, so I don't know whether this is done in the Qt layer or somewhere in kdelibs) xdg-utils' xdg-open(1) (the reference implementation of that name) Debian's mailcap package, which translates fd.o MIME handlers into traditional mailcap(5) handlers web browsers like Firefox and Chromium might reimplement it? not sure ...

so that handlers cannot be registered for certain "dangerous" file types (i.e. ELF/PE/Mach-O executables, scripts in various languages, etc.)? The only real downside I can see to that is the inability to text editors to register themselves as handlers for script MIME types, and in those instances, the editor can register itself as the handler for another applicable, more generic MIME type (i.e. text/plain), then change its behavior based on the more detailed MIME type of the file after it opens it.

smcv

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.

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.

A flaw was found in the GLib Base64 encoding routine when processing very large input data. Due to incorrect use of integer types during length calculation, the library may miscalculate buffer boundaries. This can cause memory writes outside the allocated buffer. Applications that process untrusted or extremely large Base64 input using GLib may crash or behave unpredictably.

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 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.

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.

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.

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 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.

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.

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 flaw exists in gdk‑pixbuf within the gdkpixbufjpegimageloadincrement function (io-jpeg.c) and in glib’s gbase64encodestep (glib/gbase64.c). When processing maliciously crafted JPEG images, a heap buffer overflow can occur during Base64 encoding, allowing out-of-bounds reads from heap memory, potentially causing application crashes or arbitrary code execution.

A flaw was found in how GLib’s GString manages memory when adding data to strings. If a string is already very large, combining it with more input can cause a hidden overflow in the size calculation. This makes the system think it has enough memory when it doesn’t. As a result, data may be written past the end of the allocated memory, leading to crashes or memory corruption.

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.

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.

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. A denial of service on Windows platforms may occur if an application attempts to spawn a program using long command lines.