AZL-113345: CVE-2026-100290 affecting package glibc 2.38-21
The regcomp and regexec functions in the GNU C Library version 2.3 to version 2.44 may read freed memory and free the same heap block twice when a memory allocation fails while a regular expression is compiled or matched. The redfaaddnode (the NFA node table) and buildrangeexp (bracket ranges) grow several arrays with consecutive realloc calls and store the new pointers only after all of them succeed. When a later call fails, the pattern buffer keeps pointers to blocks that were already freed, and the error cleanup frees them again. In regexec, the back-reference cache (matchctxaddentry) frees its array when a realloc fails but keeps the pointer, which is freed again on the error path.
An attacker does not need to supply a crafted regular expression: patterns large enough to grow these arrays are common. The failure has to hit a specific allocation, though, so the issue can only be reached when the system is already under memory pressure. An attacker who supplies the pattern or the subject string has little control over which allocation fails, so the expected impact is a crash of the process. This issue affects all architectures and ABIs supported by the GNU C Library.
Affected Software
Event History
Frequently Asked Questions
Under what conditions is exploitation realistically reachable?
The vulnerable error paths require a memory allocation to fail at a specific point while a regular expression is compiled or matched. This makes the issue reachable when the system is already under memory pressure, including when an attacker can provide the pattern or subject string.
Does an attacker need to provide a specially crafted regular expression?
No. Patterns large enough to cause the relevant internal arrays to grow are described as common. However, an attacker has little control over which allocation fails.
What impact should be expected?
The expected impact is a crash of the affected process due to use of freed memory and a double free during error handling. The provided information does not establish a more severe impact.
Are any platforms excluded?
No. The issue affects all architectures and ABIs supported by the GNU C Library.