FYI, rawhide makes /usr/bin/install (matchpathcon) segfault

Jim Meyering jim at meyering.net
Wed Sep 7 08:01:44 UTC 2011


I was getting ready to release coreutils-8.13, after two pre-release snapshots,

    http://thread.gmane.org/gmane.comp.gnu.coreutils.general/1554
    http://thread.gmane.org/gmane.comp.gnu.coreutils.general/1631

when I went to make sure its tests all pass also on rawhide.
I test that regularly, and they've all been passing (of course), so I
didn't expect any surprises.  I certainly didn't expect 7 failures,
and never something as basic as this:

    $ touch a
    $ env -i /usr/bin/install a b
    zsh: segmentation fault  env -i /usr/bin/install a b
    [Exit 139 (SEGV)]

[the "env -i " prefix is just to ensure that none of my MALLOC_DEBUG_
 or MALLOC_PERTURB_ settings (or any other envvar) is causing trouble. ]

gdb shows that it's officially a NULL-deref, but says there's a
"Corrupted DWARF expression", probably discovered in read_sleb128:

    $ env -i gdb -q --args /usr/bin/install a b
    Reading symbols from /usr/bin/install...Reading symbols from /usr/lib/debug/usr/bin/install.debug...done.
    done.
    (gdb) r
    Starting program: /usr/bin/install a b
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib64/libthread_db.so.1".

    Program received signal SIGSEGV, Segmentation fault.
    __strtok_r_1c (__nextp=read_sleb128: Corrupted DWARF expression.
    ) at /usr/include/bits/string2.h:1179
    1179      while (*__s == __sep)
    (gdb) p __s
    $1 = 0x0
    (gdb) bt
    #0  __strtok_r_1c (__nextp=read_sleb128: Corrupted DWARF expression.
    ) at /usr/include/bits/string2.h:1179
    #1  init (rec=0x626930, opts=0x7ffff7fe2718, n=<optimized out>)
        at label_file.c:440
    #2  0x00007ffff7bc4b3d in selabel_open (backend=0, opts=0x7ffff7fe2718,
        nopts=5) at label.c:165
    #3  0x00007ffff7bc3e16 in matchpathcon_init_prefix_internal (path=0x0,
        subset=0x0) at matchpathcon.c:321
    #4  0x00007ffff7bc40a9 in matchpathcon (path=0x7fffffffefbf "b", mode=33261,
        con=0x7fffffffeb98) at matchpathcon.c:406
    #5  0x000000000040452f in setdefaultfilecon (file=0x7fffffffefbf "b")
        at install.c:345
    #6  change_attributes (name=0x7fffffffefbf "b") at install.c:471
    #7  install_file_in_file (from=<optimized out>, to=0x7fffffffefbf "b",
        x=<optimized out>) at install.c:672
    #8  0x0000000000403cd6 in main (argc=<optimized out>, argv=<optimized out>)
        at install.c:978
    (gdb)

So install is just the messenger, since it's calling libselinux's
matchpathcon function, in which all of this is happening.
Given the dwarf corruption, libselinux may be a messenger, too,
but for now, I've just put all this in a BZ:

  http://bugzilla.redhat.com/736259

This seems so fundamental that I have to wonder if it's
something specific to my own set-up...


More information about the devel mailing list