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
Content-Type: text/plain; charset="UTF-8"
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