Giuseppe Scrivano <gscriv...@gnu.org> writes: > Hi Simon, > > Nikos Mavrogiannopoulos <n...@gnutls.org> writes: > >> On Sat, Mar 28, 2015 at 12:51 PM, Nikos Mavrogiannopoulos >> <n...@gnutls.org> wrote: >>> Hello Simon, >>> Robert reported some invalid memory access in gnutls, and one I traced >>> it back to libidn. A reproducer is attached. The reproducer uses strings >>> on the heap because valgrind doesn't seem to detect such accesses on the >>> stack. >>> ==623== Invalid read of size 1 >>> ==623== at 0x4E38E7F: g_utf8_to_ucs4_fast (nfkc.c:399) >>> ==623== by 0x4E38E7F: stringprep_utf8_to_ucs4 (nfkc.c:1023) >>> ==623== by 0x4E3A7DE: idna_to_ascii_8z (idna.c:578) >>> ==623== by 0x4005FD: main (in /home/nmav/cvs/gnutls/lib/a.out) >>> ==623== Address 0x541105f is 1 bytes after a block of size 30 alloc'd >>> ==623== at 0x4C28C20: malloc (vg_replace_malloc.c:296) >>> ==623== by 0x50E99D9: strdup (strdup.c:42) >>> ==623== by 0x4005E0: main (in /home/nmav/cvs/gnutls/lib/a.out) >> >> The attached patches handle the reported issue. However, all functions >> which use g_utf8_next_char() including g_utf8_strlen() are affected. > > is there anything holding this patch?
I'll add it to the next release... it is cosmetic workaround for a glibc/gcc/valgrind issue, there is no bug in libidn there. > There is a security issue reported for wget, related to this issue, I > don't think (as others on bug-wget as well) a workaround in wget is the > correct solution as it affects any libidn user. > > http://lists.gnu.org/archive/html/bug-wget/2015-06/msg00000.html > > Could this please be addressed? That's a completely separate issue. You need to pass valid UTF-8 to libidn. Libidn could help here, and probably should since nobody appears to get this right, but I haven't looked into how to do it. /Simon
signature.asc
Description: PGP signature
_______________________________________________ Help-libidn mailing list Help-libidn@gnu.org https://lists.gnu.org/mailman/listinfo/help-libidn
