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
