[Top][All Lists]

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

Re: Libidn serious bug on Windows x64

From: Evgeny Grin
Subject: Re: Libidn serious bug on Windows x64
Date: Thu, 21 Jul 2016 23:25:32 +0300
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

On 20.07.2016 20:03, Simon Josefsson wrote:
> Evgeny Grin <address@hidden> writes:
>> Hi!
>> While debugging cURL on Windows x64 crash with simple run of "curl -v
>> http://яндекс.рф";, I discovered that crash caused by calling
>> tld_check_lz(). Further investigations reveal pointer to size_t is cast
>> to pointer to long in stringprep_utf8_to_ucs4() which in invalid on
>> Win64. As result - very high number is stored in items_written and in
>> tld_get_4() dereferenced an invalid pointer.
>> I can't make a minimal example to illustrate it as in minimal example
>> initial nullifying hides the problem. Hope that invalid casting is
>> obvious problem.
> Hello.  Does this problem still exist with 1.32?  What size does
> 'size_t' and 'long' have on Windows x64?

Yes, the same bug is present in 1.32, 1.33 and in current git master.
Currently libidn keep crashing on Windows.
MinGW package includes my patches to prevent crashing:

Generally, you can't assume that sizeof(int) == sizeof(long) or
sizeof(long) == sizeof(long long) or sizeof(long) == sizeof(void*)

On Windows x64 sizeof(int) == 4, sizeof(long) == 4, sizeof(long long) ==
8, sizeof(void*) == 8.

But casting pointer to one type to pointer to other type is bad idea in
general, unless you 100% sure that such casting is ALWAYS and ANYWHERE
I sent already some patches for fixing this bug.

Additional (unrelated) fixes attached.

Best Wishes,
Evgeny Grin

Attachment: 0001-.gitattributes-Preserve-LF-line-endings-for-.gperf.patch
Description: Text document

Description: Text document

Attachment: 0003-nfkc.c-do-not-use-UTF-8-codes-longer-then-4-bytes.patch
Description: Text document

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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