Bug 2492247 (CVE-2026-58012)

Summary: CVE-2026-58012 glib: buffer over-read in g_regex_replace() via glib/gregex.c:string_append() and g_utf8_next_char()
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: kshier, rhel-process-autobot, stcannon, teagle, watson-tool-maintainers, yguenane
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in GLib. A buffer over-read can occur in the g_regex_replace function when used with the `G_REGEX_RAW` compile flag and case-change replacement escapes because the string_append 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.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2494874, 2494875, 2494873    
Bug Blocks:    

Description OSIDB Bzimport 2026-06-24 16:49:19 UTC 
A heap-buffer-overflow READ vulnerability exists in GLib's g_regex_replace() function when used with G_REGEX_RAW compile flag and case-change replacement escapes (\U, \L, \u, \l).
In G_REGEX_RAW 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 string_append() function processes the matched substring using UTF-8 functions (g_utf8_get_char(), g_utf8_next_char()) 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.