On Mon, Mar 16, 2026 at 09:03:42PM +0800, Zhihan Zheng wrote: > Hello GNU m4 Maintainer, > > I would like to report a potential security issue in m4 1.4.21. > > The issue is in substr handling in src/builtin.c. The code checks: > > ```c > if (start + length > avail) > length = avail - start; > obstack_grow (obs, ARG (1) + start, length); > ``` > > Because start, length, and avail are stored as int, start + length can > overflow. With crafted input, this can bypass the intended bounds logic and > lead to an out-of-bounds read followed by a crash.
Indeed, easy to reproduce: $ m4 substr(eval(0,2,100),80,eval(0x7fffffff)) m4: internal error detected; please report this bug to <[email protected]>: Segmentation fault Whether it can be exploited to something more severe that manipulates the heap instead of an instant SEGV is going to be harder to rule out. > > Affected area: > - src/builtin.c:1822-1847 > > 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. Already public, but something I will make sure is fixed when 1.4.22 is released. Whether a CVE is warranted is dependent on whether you think people are liable to run m4 on an untrusted script, in such a way that m4 crashing serves as a denial of service against a bigger picture. For example, if you are able to write a custom sendmail filter to cause sendmail to trip on this m4 bug and thereby prevent normal operation of sendmail filtering, then that probably does warrant a CVE. Investigating git history, the bug has been present since at least commit bd11691d (aka initial revision); which according to ChangeLog dates it back to m4 1.4 released Nov 1994 (pre-dating my involvement in the project). -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
