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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=VZffWNNSDrkytr5U8b5rwvRUiF5wmLna4Dzjw3EPN9Y6I1oPyJ6iL
	uUd5GkDByBGXT9ZKubmwhQWQhfZM9hdUVOyD9Lrsn5OQQifoaCYfVCBHcXV9CdxQ
	aVeeRxDKPX/ErWXs92G8psW296Q3DeFDLB+KQRyuGPDXPkctJpe+Is=
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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=WK7Q7/1JTrR+9fX2tlwD83zqM0U=; b=i92yDxZ/0jhl+pYHBDZWuuseHq3t
	SYU/K2dEeUuWjqxkT/EU++ZB0dT8VV9F1Sa3XAFiF7e11DhJUkK1sbxtTkZByJLR
	pi1JO105WXIo0ldqTs0dYtWLFwisN1C5dCc4mVajr7ObVaAS2rN3DbusIVCmTSMY
	QJ9DQ7MCbPZ4VuY=
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=-101.9 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=incredible, H*c:application
X-HELO:	drew.franken.de
Date:	Tue, 6 Jun 2017 21:22:34 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Bug? wcsxfrm causing memory corruption
Message-ID:	<20170606192234.GF23208@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
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>
MIME-Version:	1.0
In-Reply-To:	<20170606155739.GC23208@calimero.vinschen.de>
User-Agent:	Mutt/1.8.0 (2017-02-23)

--juZjCTNxrMaZdGZC
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 underlyi=
ng
> > >> 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 buff=
er
> > >> 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.
>=20
> 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.=20=20
>=20
> So, yeah, I think manual swaping after calling LCMapStringW without
> LCMAP_BYTEREV is the way to go.  I'll prepare a fix.
>=20
>=20
> Thanks for tracking down and the testcase,
> Corinna

Latest snapshot from https://cygwin.com/snapshots/ has the patch applied.
Please try.


Thanks,
Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--juZjCTNxrMaZdGZC
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZNwD5AAoJEPU2Bp2uRE+gR/AP/Rhv9TLVmup2YhJoB3wUFxSu
o4Xl+ZQSYG+0aWbkZ60gXTrHe1lgOt12d94J9O/eelVo3aRoqZtHdN0U/vMcDJrs
J6/Fenqvzjc2xhsu8987rj7exToabgDIz7Auvc9HfLKmUTUeLiH0L97Kq5MhE+ZO
4WpDAFhM91B34Tqk5lpeDR15RC9GjciRPKTIMrUeoB9y1XWthRwYQhJZA63+2DV3
oeGLLx+gC2MB7VCKN2j586WAa9nVnMJXC97peO66EekA7qShF+EUsGCodQrWF8jt
ZKUKMlOSD/JOfGapPRhbknF8e8PPL3+bX0XOE82j4CXvBzKi41tuUW8pIj7hyam+
F4EavJdTLQHh5gmjznFLpa2tnfhEekTE5PaqvggDa2udv0L65Zvq/d158KUz0jC4
PHQDDrRQ2/X5J9g4EW3NlwS26P8Qx7hQTliHq49L2qL3HSc/QYkAQuX+O+8cUKSZ
bWmegm0iNP+vGDe4GZPBim0GcBpBh5KtnAWTuwpNHdhLj8KXJXRZjbCjMTbxpBmg
qH/rZNrTTeMio6Hpfqrzez/B3AP7+KQcX5tPUwzXLU/MN1ZOm+i97hUNX8PFc3e+
X5y0MYYFJrhIft4waCubfR1zoSIe0P2lApVu1QAMJgO3be2lMK1ZNb1GuRggkF3l
U49qrL595PHhXtdmTzV6
=9632
-----END PGP SIGNATURE-----

--juZjCTNxrMaZdGZC--

- Raw text -