Re: [Security] Integer overflow in src/freeze.c frozen-state reload path
Zhihan Zheng <[email protected]> Wed, 25 Mar 2026 20:05:10 +0800
| Newsgroups | gmane.comp.gnu.m4.bugs |
|---|---|
| Message-ID | <TYRP301MB1427AB0744CF8E2236871ACFD149A@TYRP301MB1427.JPNP301.PROD.OUTLOOK.COM> |
--------------NSZvAj1B5HOZ1KDrLBCBlslr
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Hi Eric and Collin,
Thank you both for the continuous follow-up and the deep dive into these
reports. I really appreciate your time and your valuable feedback on
m4's threat model.
To answer the earlier question about AI: yes, these reports are the
result of an automated vulnerability discovery framework I am currently
experimenting with. My research focuses on applying Large Language
Models and intelligent agents to software security analysis. I apologize
for any noise or errors this generated, and I am very grateful for your
patience with this process.
Regarding the specific issues:
1. format (PoC): For the format abort issue, here is a minimal example
triggering the EOVERFLOW :
/format(%*d,-2147483648,1)/
2. freeze & substr: I am glad the substr issue was confirmed and will be
fixed in future. I also want to sincerely apologize for unintentionally
making these issue public on the bug-m4 list. That was a procedural
oversight on my part, and I will make sure to use proper private
channels for any future reports.
3. eval: I completely agree with your assessment. Relying on the OS to
handle stack exhaustion makes perfect sense for this tool, rather than
placing arbitrary limits.
As a student invested in software analysis, I have immense respect for
the decades of robust engineering behind m4. Thank you again for your
time and for maintaining such a crucial piece of our infrastructure.
On 3/25/26 12:31 AM, Eric Blake wrote:
> On Mon, Mar 16, 2026 at 09:03:58PM +0800, Zhihan Zheng wrote:
>> Hello GNU m4 Maintainer,
>>
>> I would like to report a potential security issue in m4 1.4.21.
> Thank you for the report.
>
>> The issue is in frozen-state reload handling in src/freeze.c. The affected
>> logic is:
>>
>> ```c
>> if (number[(i)] + 1 > allocated[(i)])
>> {
>> allocated[(i)] = number[(i)] + 1;
>> string[(i)] = xcharalloc ((size_t) allocated[(i)]);
>> }
>> ```
>>
>> The parsed length is kept in int. A crafted frozen file can supply a large
>> value such as 2147483647, causing number[i] + 1 to overflow and leading to
>> abnormal allocation behavior. On my test build this produces a deterministic
>> denial of service during m4 -R processing.
> Most users don't experiment with m4 -R; autoconf does use frozen
> files, but assumes that the frozen file is not malicious. You are
> right that hardening this code to do more input validation and reject
> invalid frozen files is worth doing; however, it is low enough in
> urgency that I am not dropping everything to work on it right away.
>
>
>> Affected area:
>> - src/freeze.c:205-217
>> - src/freeze.c:245-259
>> - src/freeze.c:323-325
>>
>> If useful, I can provide a minimal PoC and sanitizer output.
>>
>> If you believe this is a valid security issue, please let me know your
>> preferred remediation or coordinated disclosure process. If needed, I can
>> also assist with CVE coordination after triage.
> You already made it public by posting to the bug-m4 list. There's
> nothing that coordinated disclosure will help now.
>
--
Best regards,
Zhihan Zheng
Beijing Institute of Technology
--------------NSZvAj1B5HOZ1KDrLBCBlslr
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p data-path-to-node="4">Hi Eric and Collin,</p>
<p data-path-to-node="5">Thank you both for the continuous follow-up
and the deep dive into these reports. I really appreciate your
time and your valuable feedback on m4's threat model.</p>
<p data-path-to-node="6">To answer the earlier question about AI:
yes, these reports are the result of an automated vulnerability
discovery framework I am currently experimenting with. My research
focuses on applying Large Language Models and intelligent agents
to software security analysis. I apologize for any noise or errors
this generated, and I am very grateful for your patience with this
process.</p>
<p data-path-to-node="7">Regarding the specific issues:</p>
1. format (PoC): For the format abort issue, here is a minimal
example triggering the EOVERFLOW :<br>
<br>
<i>format(%*d,-2147483648,1)</i><br>
<br>
2. freeze & substr: I am glad the substr issue was confirmed and
will be fixed in future. I also want to sincerely apologize for
unintentionally making these issue public on the bug-m4 list. That
was a procedural oversight on my part, and I will make sure to use
proper private channels for any future reports.<br>
<br>
3. eval: I completely agree with your assessment. Relying on the OS
to handle stack exhaustion makes perfect sense for this tool, rather
than placing arbitrary limits.<br>
<br>
As a student invested in software analysis, I have immense respect
for the decades of robust engineering behind m4. Thank you again for
your time and for maintaining such a crucial piece of our
infrastructure.<br>
<br>
<br>
<div class="moz-cite-prefix">On 3/25/26 12:31 AM, Eric Blake wrote:<br>
</div>
<blockquote type="cite" cite="mid:[email protected]">
<pre wrap="" class="moz-quote-pre">On Mon, Mar 16, 2026 at 09:03:58PM +0800, Zhihan Zheng wrote:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">Hello GNU m4 Maintainer,
I would like to report a potential security issue in m4 1.4.21.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
Thank you for the report.
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">
The issue is in frozen-state reload handling in src/freeze.c. The affected
logic is:
```c
if (number[(i)] + 1 > allocated[(i)])
{
allocated[(i)] = number[(i)] + 1;
string[(i)] = xcharalloc ((size_t) allocated[(i)]);
}
```
The parsed length is kept in int. A crafted frozen file can supply a large
value such as 2147483647, causing number[i] + 1 to overflow and leading to
abnormal allocation behavior. On my test build this produces a deterministic
denial of service during m4 -R processing.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
Most users don't experiment with m4 -R; autoconf does use frozen
files, but assumes that the frozen file is not malicious. You are
right that hardening this code to do more input validation and reject
invalid frozen files is worth doing; however, it is low enough in
urgency that I am not dropping everything to work on it right away.
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">
Affected area:
- src/freeze.c:205-217
- src/freeze.c:245-259
- src/freeze.c:323-325
If useful, I can provide a minimal PoC and sanitizer output.
If you believe this is a valid security issue, please let me know your
preferred remediation or coordinated disclosure process. If needed, I can
also assist with CVE coordination after triage.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
You already made it public by posting to the bug-m4 list. There's
nothing that coordinated disclosure will help now.
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Best regards,
Zhihan Zheng
Beijing Institute of Technology</pre>
<br>
</body>
</html>
--------------NSZvAj1B5HOZ1KDrLBCBlslr--