{"id":"CVE-2026-100290","kind":"vulnerability","aliases":["CVE-2026-100290"],"related":[],"title":"GNU C Library: regex allocation failure can double-free memory and crash","description":"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 re_dfa_add_node (the NFA node table) and build_range_exp (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 (match_ctx_add_entry) frees its array when a realloc fails but keeps the pointer, which is freed again on the error path.\n\nAn 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.","summary":"When memory runs out during regex compilation or matching, the GNU C Library (glibc) can read freed memory and free the same heap block twice. The expected result for an attacker is a crash of the process that uses the regex, since control over which allocation fails is limited.","severity":"low","cvss":3.7,"epss":null,"exploited":false,"exploited_at":null,"products":[],"ecosystems":[],"tags":["c-runtime","glibc","infrastructure","linux"],"not_affected_if":["glibc-outside-2.3-to-2.44","no-regex-processing"],"how_to_check":"- Check the glibc version with `ldd --version` and compare it against the affected range 2.3 through 2.44.\n- Identify services that compile or match regular expressions from untrusted input while under memory pressure.","fix":null,"status":"open","published_at":"2026-11-11T16:17:24+00:00","first_seen_at":"2026-11-11T16:28:06+00:00","triaged_at":"2026-11-11T16:30:03+00:00","updated_at":"2026-11-11T16:30:03+00:00","category":"infrastructure","confidence":0.6,"triage":{"at":"2026-11-11T16:30:03Z","model":"claude-haiku-5-5","output":{"fix":"unknown","reach":"unknown","title":"GNU C Library: regex allocation failure can double-free memory and crash","impact":"low","summary":"When memory runs out during regex compilation or matching, the GNU C Library (glibc) can read freed memory and free the same heap block twice. The expected result for an attacker is a crash of the process that uses the regex, since control over which allocation fails is limited.","audience":"businesses","category":"infrastructure","nicknames":[],"who_cares":["glibc","linux","c-runtime"],"confidence":0.6,"fix_status":"unknown","needs_auth":"unknown","worst_case":"process crashes after heap corruption during failed allocation","analyst_note":"Check the GNU C Library project advisory or the NVD page for a fixed glibc version and confirm the affected range; the sources given here state no fix.","how_to_check":"- Check the glibc version with `ldd --version` and compare it against the affected range 2.3 through 2.44.\n- Identify services that compile or match regular expressions from untrusted input while under memory pressure.","plain_action":"","product_name":"","needs_analyst":true,"not_affected_if":["glibc-outside-2.3-to-2.44","no-regex-processing"],"who_is_affected":"Any Linux system or application linked against glibc versions 2.3 through 2.44 is potentially affected, since the flaw is in the core C library's regex functions. The issue only triggers when a memory allocation fails during regex compilation or matching, so it matters most on systems under memory pressure. Systems on glibc outside this range, or where no regex work runs, can skip it.","user_interaction":"unknown","product_ecosystem":"","needs_special_setup":"no","severity_if_unknown":"low"},"cost_usd":0.000773,"input_tokens":4833,"output_tokens":580,"severity_before":"low"},"analyst_status":null,"analyst_note":null,"search":"'-100290':16A,19A '-2026':15A,18A '2.3':86C '2.44':89C 'abi':277C 'add':117C,179C 'affect':273C 'alloc':5A,71B,104C,227C,259C 'alreadi':161C,240C 'architectur':275C 'array':131C,183C,217C 'attack':56B,201C,245C 'back':174C 'back-refer':173C 'block':49B,99C,158C 'bracket':127C 'buffer':154C 'build':124C 'c':2A,21B,37B,83C,282C 'c-runtim':20B 'cach':176C 'call':135C,150C 'cleanup':166C 'common':219C 'compil':32B,111C 'consecut':133C 'control':68B,256C 'craft':208C 'crash':13A,59B,267C 'ctx':178C 'cve':14A,17A 'dfa':116C 'doubl':9A 'double-fre':8A 'enough':213C 'entri':180C 'error':165C,198C 'exp':126C 'expect':52B,263C 'express':109C,210C 'fail':72B,105C,151C,187C,260C 'failur':6A,221C 'free':10A,45B,95C,167C,181C 'freed':42B,92C,162C,194C 'function':79C 'glibc':23B,39B 'gnu':1A,36B,82C,281C 'grow':129C,215C 'heap':48B,98C 'hit':224C 'impact':264C 'infrastructur':24B 'issu':231C,272C 'keep':155C,189C 'larg':212C 'later':149C 'librari':3A,38B,84C,283C 'limit':74B 'linux':25B 'littl':255C 'match':34B,113C,177C 'may':90C 'memori':11A,27B,43B,93C,103C,242C 'need':204C 'new':139C 'nfa':120C 'node':118C,121C 'path':199C 'pattern':153C,211C,249C 'pointer':140C,156C,191C 'pressur':243C 'process':62B,270C 'rang':125C,128C 're':115C 'reach':235C 'read':41B,91C 'realloc':134C,186C 'refer':175C 'regcomp':76C 'regex':4A,31B,66B 'regexec':78C,171C 'regular':108C,209C 'result':53B 'run':28B 'runtim':22B 'sever':130C 'sinc':67B 'specif':226C 'store':137C 'string':253C 'subject':252C 'succeed':146C 'suppli':206C,247C 'support':278C 'system':238C 'tabl':122C 'though':228C 'twice':50B,100C 'use':64B 'version':85C,88C","nicknames":[],"mitigations":[],"who_affected":"Any Linux system or application linked against glibc versions 2.3 through 2.44 is potentially affected, since the flaw is in the core C library's regex functions. The issue only triggers when a memory allocation fails during regex compilation or matching, so it matters most on systems under memory pressure. Systems on glibc outside this range, or where no regex work runs, can skip it.","tier":"C","verified":{},"analyst_revisit_at":null,"fix_status":"none","audience":"businesses","plain_action":null,"pkeys":[],"ptokens":[],"labels":["cruntime","glibc","infrastructure","linux","low"],"campaign_type":null,"search_a":"'-100290':16A,19A '-2026':15A,18A 'alloc':5A 'c':2A 'crash':13A 'cve':14A,17A 'doubl':9A 'double-fre':8A 'failur':6A 'free':10A 'gnu':1A 'librari':3A 'memori':11A 'regex':4A","search_b":"'alloc':71B 'attack':56B 'block':49B 'c':21B,37B 'c-runtim':20B 'compil':32B 'control':68B 'crash':59B 'expect':52B 'fail':72B 'free':45B 'freed':42B 'glibc':23B,39B 'gnu':36B 'heap':48B 'infrastructur':24B 'librari':38B 'limit':74B 'linux':25B 'match':34B 'memori':27B,43B 'process':62B 'read':41B 'regex':31B,66B 'result':53B 'run':28B 'runtim':22B 'sinc':67B 'twice':50B 'use':64B","search_c":"'2.3':86C '2.44':89C 'abi':277C 'add':117C,179C 'affect':273C 'alloc':104C,227C,259C 'alreadi':161C,240C 'architectur':275C 'array':131C,183C,217C 'attack':201C,245C 'back':174C 'back-refer':173C 'block':99C,158C 'bracket':127C 'buffer':154C 'build':124C 'c':83C,282C 'cach':176C 'call':135C,150C 'cleanup':166C 'common':219C 'compil':111C 'consecut':133C 'control':256C 'craft':208C 'crash':267C 'ctx':178C 'dfa':116C 'enough':213C 'entri':180C 'error':165C,198C 'exp':126C 'expect':263C 'express':109C,210C 'fail':105C,151C,187C,260C 'failur':221C 'free':95C,167C,181C 'freed':92C,162C,194C 'function':79C 'gnu':82C,281C 'grow':129C,215C 'heap':98C 'hit':224C 'impact':264C 'issu':231C,272C 'keep':155C,189C 'larg':212C 'later':149C 'librari':84C,283C 'littl':255C 'match':113C,177C 'may':90C 'memori':93C,103C,242C 'need':204C 'new':139C 'nfa':120C 'node':118C,121C 'path':199C 'pattern':153C,211C,249C 'pointer':140C,156C,191C 'pressur':243C 'process':270C 'rang':125C,128C 're':115C 'reach':235C 'read':91C 'realloc':134C,186C 'refer':175C 'regcomp':76C 'regexec':78C,171C 'regular':108C,209C 'sever':130C 'specif':226C 'store':137C 'string':253C 'subject':252C 'succeed':146C 'suppli':206C,247C 'support':278C 'system':238C 'tabl':122C 'though':228C 'twice':100C 'version':85C,88C","cause_entry":null,"cause_path":null,"disclosures_checked_at":null,"first_public_at":"2026-11-11T16:17:24+00:00","kev":null,"cvss_vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L","cvss_by":"3ff69d7a-14f2-4f67-a097-88dee7810d18","poc_count":0,"sources":[{"source":"nvd","external_id":"CVE-2026-100290","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-100290","severity":null,"published_at":"2026-11-11T16:17:24+00:00","modified_at":"2026-11-11T16:17:24+00:00","first_seen_at":"2026-11-11T16:28:06+00:00","fetched_at":"2026-11-11T16:28:06+00:00","note":null}],"documents":[],"disclosures":[],"exploit_sources":[],"notice":"Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai"}