Red Hat Bugzilla – Bug 443589
RFE: Upgrade gm4
Last modified: 2008-04-24 08:01:52 EDT
Description of problem:
According to Eric Blake <firstname.lastname@example.org> (upstream) gm4, all versions of gm4 prior
to 1.4.11 suffer from serious bugs, which are not unlikely to break autoconf and
to cause autoconf to generate broken configure scripts.
I would recommend to upgrade m4 on all Fedora and RH releases.
Particularily delicate: The versions of m4 as being shipped with RHEL 4 and
below are such kind of old contemporary autoconf doesn't work on them.
=> Not upgrading m4 on these distros disqualifies RHEL <= 4
as development environment.
Some clarification: all versions of GNU m4 1.3 through 1.4.10 have at least one
known stack-overflow (arbitrary code execution) bug, fixed in m4 1.4.11, when
the -F option is abused. Additionally, autoconf 2.62 explicitly requires m4
1.4.5 or greater (because earlier versions can generate corrupt configure
files), but can safely use 1.4.5 (now 21 months old) without tickling the
security bugs present in those older versions, and without generating corrupt
configure files. Earlier versions of autoconf also require m4 1.4.5 or greater
to avoid corrupt configure files, although the dependency was implicit rather
Therefore, while upgrading to m4 1.4.11 would be nice, it is sufficient for
autoconf's purposes to upgrade only to m4 1.4.5 (or at least backport the
security fixes and the tracing bug fix to an earlier m4), and this should be
done whether or not you upgrade to autoconf 2.62 in the near future, since all
versions of autoconf are vulnerable to the pre-1.4.5 bug.
Meanwhile, on BSD-based platforms, m4 1.4.10 also generates corrupt configure
files; but as RHEL uses glibc and not BSD stdio, this is not an issue for RHEL.
And eventually, when m4 1.6 is released, it will be incompatible with the stock
autoconf 2.59, although the autoconf team has prepared patches that against 2.59
that will allow it to work with m4 1.6.
Ralf, thanks for report, Eric, thanks for clarification.
I updated to m4-1.4.11 in rawhide.
I will not do rebase of m4 in older Fedoras - newest Fedora with m4 version
bellow 1.4.5 is Fedora 5.
Ralf, if you're RHEL customer, please contact support to resolve this in RHEL.
(My opinion: RHEL5 - m4-1.4.5 (no changes IMHO), RHEL4 - m4-1.4.1 (maybe
backport security fixes and tracing bug fix?), RHEL3 - m4-1.4.1 (we fix only
hight priority security problems, so no changes IMHO).)
(In reply to comment #2)
> Ralf, if you're RHEL customer, please contact support to resolve this in RHEL.
I am not - I am simply co-leader and maintainer of an opensource project
(http://www.rtems.org) which has supported CentOS4 as one of their development
As our development will be based on autoconf-2.62 (which mandates using
gm4-1.4.5), not upgrading RHEL4 (and CentOS4) simply closes out CentOS4 and
RHEL4 from being used as a development platform for your works and will
force us to discontinue supporting CentOS4/RHEL4.
I had hoped to be able to avoid this step - Your decision however makes it
Ralf, I did no decision in RHEL case. Please file a bug against m4 and
particular RHEL version to let product management consider and prioritize your
request. Do the same with autoconf, if you wish new version in RHEL.