X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; q=dns; s=default; b=p6Ww2v+
	h6QJbvYJMGd/ztlPk+O8leeBlmliEZ/E1+7RU0pUoWzkTXo8GGS6qw0MRMBRIII1
	t071C9uymeWaZBCtWTo7/LTPIPFECbyaxjFHLaXOVMB/zM/7+uJJJ5fBA1AJGZ97
	QBT4NwM0lFzCyP22GWjfPn/c/Op4JUz7g6fU=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; s=default; bh=XXds6TlNNGQC8
	xGOZ/oDzsjVPmw=; b=Y0hBtlTW+785deNABLEOno1oTk3TzfXHXldx4V59shrsw
	9ibIMLtrLm5AgaYoHIoHtyDWrYuDHg3MYguAKLBQVk++A4TN3GRKmXoJRXJaozWh
	rIQhXd4MgmtefnLdduFxuYUPSJQWAorCbqVDXPSMM9haErc0+7Yxy5dVEfYisE=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=incredible
X-HELO:	mail-yb0-f170.google.com
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ZQl7qXAbE7JW0qs/l35khiXTXLGfwnPSRQNvAFk6ztM=; b=J9kWIXAuToKy4H1FWExVTDQC8gFKqhX18zkzuvxxN/prrllXHehFYQf9s9TVTlnqS7 uCvgJUUixnGNpvtuRmBPqWmw8EeJgx/TPLLI4UsukjZ6NASmGBE8gUPkMzUuIonTwYj8 pGDsSyN4UuRrbAas7xrx86d4BGRG7Prd1CE/j+Awib9FcNDxyXrecju7P/O27PSDBeM0 tBsaumFcKULYbfr+jixmJbs0pWw9onQWIUbjdJRfFmqsVeywjD0i7GD+uCikyk63xJEB h6l/6UeES5/KktXxQqdwY4mr3sQ5zu5c8eQ4xnqhQPUz47qXgtOz5k6boh/pAjpqLDGp JFLQ==
X-Gm-Message-State:	AODbwcDRkC9GsiYPoYDTWcSHq0BR5SK/90m/Pdf1tYat1b1Fh1QARPWr 60DatmoK/r0F2uibi8higL0xOBKrIwXx
X-Received:	by 10.37.13.194 with SMTP id 185mr15468888ybn.37.1497013391377; Fri, 09 Jun 2017 06:03:11 -0700 (PDT)
MIME-Version:	1.0
In-Reply-To:	<20170606192234.GF23208@calimero.vinschen.de>
References:	<CAOTD34aCROSAQojYvV4rjwiWOfiALFP+P2wODoMV1dcaOhKPFQ AT mail DOT gmail DOT com> <20170521042352 DOT GA4045 AT dimstar DOT local DOT net> <CAOTD34buK86Xdd-XV5DGtfD_xyMYT++-O6y+gpg7YC4YNLXLsQ AT mail DOT gmail DOT com> <20170606155739 DOT GC23208 AT calimero DOT vinschen DOT de> <20170606192234 DOT GF23208 AT calimero DOT vinschen DOT de>
From:	Erik Bray <erik DOT m DOT bray AT gmail DOT com>
Date:	Fri, 9 Jun 2017 15:03:10 +0200
Message-ID:	<CAOTD34b2F4c1-eUtFB9c1WDubbJPaZkz5iu1jEM6dmJ-PiOREA@mail.gmail.com>
Subject:	Re: Bug? wcsxfrm causing memory corruption
To:	cygwin AT cygwin DOT com
X-IsSubscribed:	yes

On Tue, Jun 6, 2017 at 9:22 PM, Corinna Vinschen wrote:
> On Jun  6 17:57, Corinna Vinschen wrote:
>> > > On Wed, May 10, 2017 at 11:30:46AM +0200, Erik Bray wrote:
>> > >> [...]
>> > >> The attached test demonstrates the bug.  Given an output buffer of N
>> > >> wide characters, wcsxfrm will cause bytes beyond the destination size
>> > >> to be reversed. I believe it might actually be a bug in the underlying
>> > >> LCMapStringW workhorse (this is on Windows 10; have not tested other
>> > >> versions).
>> > >>
>> > >> According to its docs [1], the cchDest argument (size of the
>> > >> destination buffer) is treated as a *byte* count when using
>> > >> LCMAP_SORTKEY.  However, for the purposes of applying the
>> > >> LCMAP_BYTEREV transformation it seems to be treating the output size
>> > >> (in bytes) as character count.  So in the example I give, where the
>> > >> output sort key is 7 bytes (including the null terminator), it swaps
>> > >> *14* bytes--the bytes including the sort key as well as the next 7
>> > >> adjacent bytes.  This is obviously a problem if the destination buffer
>> > >> is allocated out of some larger memory pool.
>> > >>
>> > >> This definitely has to be a bug, right?  Or at least very poorly
>> > >> documented on MS's part.  A workaround would either be to not use
>> > >> LCMAP_BYTEREV and just swap the bytes manually, or in a second call to
>> > >> LCMapStringW with LCMAP_BYTEREV and the correct character count...
>> > >> [...]
>> Incredible piece of detective work.  Yeah, this looks very much like a
>> bug in LCMapStringW, embarrassingly one I didn't notice at the time of
>> writing the code.  I just tested this on W7 and the problem was already
>> present.
>>
>> I don't know if this could be fixed by documentation.  There's just no
>> safe way to combine LCMAP_SORTKEY with LCMAP_BYTEREV it seems, unless
>> you always allocate a buffer at least twice as big as actually required
>> for the sort key.
>>
>> So, yeah, I think manual swaping after calling LCMapStringW without
>> LCMAP_BYTEREV is the way to go.  I'll prepare a fix.
>>
>>
>> Thanks for tracking down and the testcase,
>> Corinna
>
> Latest snapshot from https://cygwin.com/snapshots/ has the patch applied.
> Please try.

I had a look at the fix and it looks good to me; thanks!

Erik

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -