On Mon, Mar 16, 2026 at 11:55:03AM -0700, Collin Funk wrote:
> Zhihan Zheng <[email protected]> writes:
>
> > Hello GNU m4 Maintainer,
> >
> > I would like to report a potential security issue in m4 1.4.21.
> >
> > The issue is in the format builtin path. User-controlled width and
> > precision values are forwarded into xasprintf in src/format.c:
> >
> > ```c
> > str = xasprintf (fstart, width, prec, ARG_INT (argc, argv));
> > ```
> >
> > That eventually reaches lib/xvasprintf.c, where a failure path prints
> > an error and aborts:
> >
> > ```c
> > fprintf (stderr, "vasprintf failed! format=\"%s\", errno=%s\n",
> > format, errname);
> > abort ();
> > ```
Along with this comment in that file:
if (errno == ENOMEM)
xalloc_die ();
else
{
/* The programmer ought to have ensured that none of the other errors
can occur. */
so the fact that m4 is passing user-controlled data to xvasprintf in
such a manner that it can trigger EOVERFLOW borders on m4 having a
programming error. There has been work in gnulib to move towards a
*printf variant that can return ssize_t rather than being forced by
the C interface to report overflow at INT_MAX; maybe it is time to
write a patch to have m4 update to those newer gnulib interfaces. M4
already has other problems with inputs larger than 2G; it will take a
much bigger audit of the source code to safely handle user macro names
and definitions that are larger than what fit in a signed int, so this
is yet another instance of something to check during such an audit.
format() is a GNU extension. Unlike your report about substr()
failing, I'm less worried about format() failing. That said, I do see
that Autoconf uses format(), although usually in a manner where the
format string is under Autoconf control rather than under user
control.
> >
> > Passing INT_MIN as a width can trigger an EOVERFLOW path and terminate
> > the process.
> >
> > Affected area:
> > - src/format.c:246-270
> > - src/format.c:365-367
> > - lib/xvasprintf.c:97-127
> >
> > If useful, I can provide a minimal PoC and reproduction output.
Having a PoC on hand would be nice; I could not quickly derive one in
my attempts.
> >
> > 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.
>
> I am confused by this report.
>
> If you allow someone to run their m4 scripts on your system, you allow
> them to execute whatever shell commands they would like on your system.
> This "user-controlled input" causing an abort should be the least of
> your concerns.
Indeed - to be a CVE, you need to show that the usage pattern can be
exploited across a privilege boundary. Most people do not run random
m4 scripts; and even if you do, the existence of the syscmd() builtin
means that m4 is usually NOT a security boundary (anything you can do
to crash m4 is something you could have already done at the local
shell - you didn't need m4 to make shell access easier). But since
there are some programs, like sendmail, that run m4 under the hood -
if you can cause sendmail to misbehave because a custom rule written
by a user crashes m4, then I could buy the argument that a CVE
assignment against m4 could be warranted due to a privilege escalation
against sendmail, where it is easier to fix m4 than to force sendmail
into figuring out how to rework its usage of m4 to avoid that
user-triggered pattern.
>
> Are these AI generated?
The original poster would have to answer that, but given the similar
tone of four reports issued at once, I would not be surprised to learn
that AI was involved in trying to identify the issues and write them
up.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization: qemu.org | libguestfs.org
