help-libidn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libidn-1.25: Fedora release 15 (Lovelock) x86_64 failure, and workar


From: Simon Josefsson
Subject: Re: libidn-1.25: Fedora release 15 (Lovelock) x86_64 failure, and workaround
Date: Fri, 25 May 2012 07:42:08 +0200
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux)

"Nelson H. F. Beebe" <address@hidden> writes:

> When I built libidn-1.25 on Fedora release 15 (Lovelock) x86_64 with
>       gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2)

Thanks for building!

>       ==6976== Invalid read of size 4
>       ==6976==    at 0x4C116C5: idna_to_ascii_4z (idna.c:526)
>       ==6976==    by 0x4C11944: idna_to_ascii_8z (idna.c:579)
>       ==6976==    by 0x400B15: doit (tst_idna2.c:485)
>       ==6976==    by 0x40090C: main (utils.c:146)

This is a known problem with glibc (or gcc, see below), its strlen
implementation is optimized to read in 4 bytes chunks so it ends up
reading out of bounds.  I have added a libidn.supp valgrind suppressions
file to this release, however I'm considering two other solutions:

  1) disable valgrind by default (we have done this for GnuTLS)

  2) allocate slightly more than what is needed, so that glibc strlen
     can read in 4 byte chunks without triggering valgrind

I'm somewhat leaning towards 2 right now, although we may end up with 1
eventually because using valgrind requires some manual interpretation of
the outcome and this is difficult to do unattended.

> Fortunately, I've built dozens of versions of gcc on our systems, so I
> tried a fresh build with gcc (GCC) 4.4.6 20110301, and all tests then
> passed.

Interesting!  I guess this suggests the over-optimized strlen is
actually not in glibc as I previously assumed but in the compiler.

/Simon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]