Re: thank you for libidn 1.34 however ...

[Dennis Clarke]

On 31/03/18 05:39 PM, Tim Rühsen wrote:
> On 31.03.2018 21:43, Dennis Clarke wrote:
> > On 31/03/18 03:22 PM, Tim Rühsen wrote:
> > > Hi Dennis,
> > >
> > >
> > > thanks for your detailed report, really appreciated !
> >
> >
> > are you sure ?   ;-)
> >
> > n0$ dbx ./fuzz/libidn_stringprep_fuzzer
> > ./time_1522524034-pid_10364-uid_16411-gid_20002-fid_libidn_stringpre.core
> > Reading libidn_stringprep_fuzzer
> > dbx: warning: core object name "libidn_stringpr" matches
> > object name "libidn_stringprep_fuzzer" within the limit of 14.
> > assuming they match
> > core file header read successfully
> > Reading ld.so.1
> > Reading libidn.so.11.6.16
> > Reading libintl.so.8.1.5
> > Reading libc.so.1
> > Reading libiconv.so.2.6.0
> > Reading libc_psr.so.1
> > program terminated by signal SEGV (no mapping at the fault address)
> > Current function is _g_utf8_normalize_wc
> >    798     while ((max_len < 0 || p < str + max_len) && *p)
> > (dbx) where
> > =>[1] _g_utf8_normalize_wc(str = (nil), max_len = -1, mode =
> > G_NORMALIZE_ALL_COMPOSE), line 798 in "nfkc.c"
> >    [2] stringprep_ucs4_nfkc_normalize(str = 0x100127b90, len = 5), line
> > 1120 in "nfkc.c"
> >    [3] stringprep_4i(ucs4 = 0x100127b90, len = 0xffffffff7fffec60,
> > maxucs4len = 17U, flags = <unknown enum member 0>, profile =
> > 0xffffffff7ef3d950), line 170 in "stringprep.c"
> >    [4] stringprep_4zi_1(ucs4 = 0x100127b90, ucs4len = 5U, maxucs4len =
> > 17U, flags = <unknown enum member 0>, profile = 0xffffffff7ef3d950),
> > line 290 in "stringprep.c"
> >    [5] stringprep_4zi(ucs4 = 0x100127b90, maxucs4len = 17U, flags =
> > <unknown enum member 0>, profile = 0xffffffff7ef3d950), line 336 in
> > "stringprep.c"
> >    [6] LLVMFuzzerTestOneInput(data = 0x100127a70 "\n", size = 68U),
> > line 94 in "libidn_stringprep_fuzzer.c"
> >    [7] test_all_from(dirname = 0xffffffff7ffff170
> > "/usr/local/build/libidn-1.34_SunOS5.10_sparcv9.001/fuzz/libidn_stringprep_fuzzer.in"),
> > line 71 in "main.c"
> >    [8] main(argc = 1, argv = 0xffffffff7ffff328), line 105 in "main.c"
> > (dbx)
>
> Looks like you have a different source code than me... there is no Line
> 1120 in nfkc.c.
> And L798 looks different here. Also, it is not possible for 'str' to
> NULL (nil) when called from stringprep_ucs4_nfkc_normalize().
> The code is
>    if (!p)
>      return NULL;
>    result_wc = _g_utf8_normalize_wc (p, -1, G_NORMALIZE_NFKC);
>
> Could you please check your source code version...

What a mess ... nothing wrong with the sources at all.

The pre-existing libs in /usr/local/lib were getting involved here as I
do not use LD_LIBRARY_PATH at all. Generally avoid it in fact. So after
setting aside ( hiding ) the previous libidn-1.33 libs and also hacking
the fuzz/main.c slightly we get :

n0$ grep -E "^\=\=\=|^Testsuite|^\#\ " 
../libidn-1.34_SunOS5.10_sparcv9.003.check.log2
============================================================================
Testsuite summary for GNU Libidn 1.34
============================================================================
# TOTAL: 87
# PASS:  85
# SKIP:  2
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================
============================================================================
Testsuite summary for GNU Libidn 1.34
============================================================================
# TOTAL: 45
# PASS:  44
# SKIP:  1
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================
============================================================================
Testsuite summary for GNU Libidn 1.34
============================================================================
# TOTAL: 3
# PASS:  3
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================
============================================================================
Testsuite summary for GNU Libidn 1.34
============================================================================
# TOTAL: 16
# PASS:  16
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================

thing of beauty.

I simply re-hacked that function in fuzz/main.c from line 79 onwards to
 get rid of the call to alloca thus :


int main(int argc, char **argv) {
    int ret_val = 0;  /* this is a return value */
    /* if VALGRIND testing is enabled, we have to call ourselves with
     * valgrind checking */
    if (argc == 1) {
        const char *valgrind = getenv("TESTS_VALGRIND");
        if (valgrind && *valgrind) {
            size_t cmdsize = strlen(valgrind) + strlen(argv[0]) + 32;
            char *cmd = malloc(cmdsize);
            snprintf(cmd, cmdsize, "TESTS_VALGRIND="" %s %s",
                                                     valgrind, argv[0]);
            ret_val = ( system(cmd) != 0 );
            free(cmd);
            return ret_val;
        }
    }
    const char *target = strrchr(argv[0], '/');
    target = target ? target + 1 : argv[0];
    char corporadir[sizeof(SRCDIR) + 1 + strlen(target) + 8];
    snprintf(corporadir, sizeof(corporadir), SRCDIR "/%s.in",
                                                              target);
    test_all_from(corporadir);
    snprintf(corporadir, sizeof(corporadir), SRCDIR "/%s.repro",
                                                              target);
    test_all_from(corporadir);
    return ret_val;
}

So that works ... geez ... what a pile of going in circles to see that
the line count in the coredump made no sense with the current sources.
Had to be from somewhere else .. and it was .. from the previous
libidn-1.33.  I think the alloca call has to go however :-)

Dennis