[tex-live] omfonts one-byte heap overflow

Tom Callaway tcallawa at redhat.com
Fri Sep 21 20:42:37 CEST 2018

I noticed that the omegafonts test suite from tl2018 was failing in
Fedora rawhide, despite no code changes since the last build.

Testsuite summary for Web2C 2018
# TOTAL: 16
# PASS:  15
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
See omegafonts/test-suite.log
Please report to tex-k at tug.org

This only seemed to happen on i686 and armv7hl builds. I reproduced it
locally in an i686 chroot. The test-suite.log says:

FAIL: check

#! /bin/sh -vx
# $Id: check.test 45809 2017-11-15 00:36:56Z karl $
# Copyright 2017 Karl Berry <tex-live at tug.org>
# Copyright 2014, 2015 Peter Breitenlohner <tex-live at tug.org>
# You may freely use, modify and/or distribute this file.

test -d tests || mkdir -p tests
+ test -d tests

+ TEXMFCNF=../../../../texk/web2c/omegafonts/../../kpathsea
+ OFMFONTS='.;./tests'

echo && echo "*** ofm2opl check xcheck"
+ echo

+ echo '*** ofm2opl check xcheck'
*** ofm2opl check xcheck
./omfonts -ofm2opl $srcdir/tests/check tests/xcheck || exit 1
+ ./omfonts -ofm2opl ../../../../texk/web2c/omegafonts/tests/check
Bad OFM file: Ligature/kern step 2 skips too far;
I made it stop.
Bad OFM file: Kern index too large.
malloc(): invalid next size (unsorted)
../../../../texk/web2c/omegafonts/check.test: line 14:  9396 Aborted
            (core dumped) ./omfonts -ofm2opl $srcdir/tests/check
+ exit 1
FAIL check.test (exit status: 1)


The gdb backtrace looks like this:

Program received signal SIGABRT, Aborted.
0xf7fd2079 in __kernel_vsyscall ()
(gdb) bt
#0  0xf7fd2079 in __kernel_vsyscall ()
#1  0xf7e29b36 in __libc_signal_restore_set (set=0xffffcdcc) at
#2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#3  0xf7e13374 in __GI_abort () at abort.c:79
#4  0xf7e6e37c in __libc_message (action=<optimized out>, fmt=<optimized
out>) at ../sysdeps/posix/libc_fatal.c:181
#5  0xf7e753bf in malloc_printerr (str=str at entry=0xf7f52850 "malloc():
invalid next size (unsorted)") at malloc.c:5354
#6  0xf7e7802b in _int_malloc (av=av at entry=0xf7f9f7a0 <main_arena>,
bytes=bytes at entry=4) at malloc.c:3727
#7  0xf7e797dd in __GI___libc_malloc (bytes=4) at malloc.c:3041
#8  0xf7fbd9e8 in xmalloc (size=4) at ../../../texk/kpathsea/xmalloc.c:25
#9  0x56559e55 in retrieve_exten_table (table=0x565d5f20 "") at
#10 0x56562ce7 in ofm_read_rest () at
#11 parse_ofm (read_ovf=0) at
#12 0x565579e1 in main (argc=<optimized out>, argv=<optimized out>) at

I thought it might be a malloc bug in the latest glibc, but the glibc
maintainers advised me to run valgrind. When I did that, it showed:

=20225== Memcheck, a memory error detector
==20225== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==20225== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for
copyright info
==20225== Command: .libs/omfonts -ofm2opl
../../../../texk/web2c/omegafonts/tests/check tests/xcheck
==20225== Invalid write of size 1
==20225==    at 0x10CA60: adjust_labels (char_routines.c:695)
==20225==    by 0x115CC1: ofm_read_rest (parse_ofm.c:368)
==20225==    by 0x115CC1: parse_ofm (parse_ofm.c:99)
==20225==    by 0x10A9E0: main (omfonts.c:286)
==20225==  Address 0x4b13ecc is 0 bytes after a block of size 12 alloc'd
==20225==    at 0x4837717: calloc (vg_replace_malloc.c:752)
==20225==    by 0x48555E4: xcalloc (xcalloc.c:25)
==20225==    by 0x1137C9: retrieve_ligkern_table (ligkern_routines.c:652)
==20225==    by 0x115CB5: ofm_read_rest (parse_ofm.c:367)
==20225==    by 0x115CB5: parse_ofm (parse_ofm.c:99)
==20225==    by 0x10A9E0: main (omfonts.c:286)

Turns out that the latest glibc code (as found in the latest revisions
of Fedora) is much better at catching malloc heap corruption. I thought
at first it was a glibc issue, but the Fedora glibc maintainers helped
me to confirm that it was not.

It looks like there is a one-byte heap overflow, maybe in the
FOR_ALL_CHARACTERS macro in char_routines.c?

I'm learning a lot as I go on this one, but I think I've gone as far as
I can. Any and all help in fixing this would be greatly appreciated.

Thanks in advance,


More information about the tex-live mailing list