[tex-live] omfonts one-byte heap overflow

Thu Sep 27 00:55:45 CEST 2018

Tom,

Which compiler are you using?  I have seen crashes due to optimizer bugs,
but that was years ago.  Just so I am on the right page with respect to
the build environment you have.

The other Tom

> On Sep 26, 2018, at 18:20:27, Tom Kacvinsky <tom.kacvinsky at suse.com> wrote:
> 
> I'll poke at this in my free time.  Would be interesting to see if it also happens
> on openSUSE/SUSE distributions (though 32-bit development support was dropped from
> SLES 12).
> 
>> On Sep 26, 2018, at 16:52:06, Johannes Hielscher <jhielscher at posteo.de> wrote:
>> 
>> So finally, someone else has run into (presumably) the same problem as
>> me, as I reported in the tlbuild list on 2018-04-08:
>> https://tug.org/pipermail/tlbuild/2018q2/004207.html
>> 
>> Back then, I didn't find a solution there, so I cannot give some clever
>> advice here )-:
>> 
>> (Even worse, my tests did succeed when called explicitly from the shell,
>> instead of by the test suite.)
>> 
>> Am Fri, 21 Sep 2018 14:42:37 -0400
>> schrieb Tom Callaway <tcallawa at redhat.com>:
>> 
>>> 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=$srcdir/../../kpathsea
>>> + TEXMFCNF=../../../../texk/web2c/omegafonts/../../kpathsea
>>> OFMFONTS=".;./tests"
>>> + OFMFONTS='.;./tests'
>>> export TEXMFCNF OFMFONTS
>>> + export TEXMFCNF OFMFONTS
>>> 
>>> 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
>>> tests/xcheck
>>> 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
>>> tests/xcheck
>>> + 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
>>> ../sysdeps/unix/sysv/linux/internal-signals.h:84
>>> #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 ../../../../texk/web2c/omegafonts/char_routines.c:837 #10
>>> 0x56562ce7 in ofm_read_rest ()
>>> at ../../../../texk/web2c/omegafonts/parse_ofm.c:371 #11 parse_ofm
>>> (read_ovf=0) at ../../../../texk/web2c/omegafonts/parse_ofm.c:99
>>> #12 0x565579e1 in main (argc=<optimized out>, argv=<optimized out>) at
>>> ../../../../texk/web2c/omegafonts/omfonts.c:286
>>> 
>>> 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==
>>> ==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)
>>> ==20225==
>>> 
>>> 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,
>>> 
>>> ~tom
>>> 
>> 
> 
> 
> 