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:from:date:message-id:subject:to
	:content-type; q=dns; s=default; b=yZ1NWMDwLuFYHWMusWOTcI2Rf73+t
	pFjmiVnabZM8lWXuHikkeoICYKetsFui/bH/Sl6fQn6YXjY/F49cP1umy/Zu5t0N
	4NU7HHCBcWLvxwxpt4tyuvDwAGXwKZxXTThV8a7f25wT3BrIC+AM7xIe6V5Or7ZX
	mxU5fBZOuAKEgc=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
MIME-Version: 1.0
From: Erik Bray <erik DOT m DOT bray AT gmail DOT com>
Date: Wed, 10 May 2017 11:30:46 +0200
Message-ID: <CAOTD34aCROSAQojYvV4rjwiWOfiALFP+P2wODoMV1dcaOhKPFQ@mail.gmail.com>
Subject: Bug? wcsxfrm causing memory corruption
To: cygwin AT cygwin DOT com
Content-Type: multipart/mixed; boundary=001a114dc1fe93c5e5054f282037

--001a114dc1fe93c5e5054f282037
Content-Type: text/plain; charset=UTF-8

Greetings--

In the process of fixing the Python test suite on Cygwin I ran across
one test that was consistently causing segfaults later on, not
directly local to that test.  The test involves wcsxfrm so that's
where I focused my attention.

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...

Thanks,
Erik


[1] https://msdn.microsoft.com/en-us/library/windows/desktop/dd318700(v=vs.85).aspx

--001a114dc1fe93c5e5054f282037
Content-Type: text/x-csrc; charset=US-ASCII; name="LCMapStringW.c"
Content-Disposition: attachment; filename="LCMapStringW.c"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_j2is5un80

I2luY2x1ZGUgPHN0ZGxpYi5oPgojaW5jbHVkZSA8c3RkaW8uaD4KI2luY2x1
ZGUgPGxvY2FsZS5oPgojaW5jbHVkZSA8d2NoYXIuaD4KI2luY2x1ZGUgPHN0
cmluZy5oPgojaW5jbHVkZSA8d2luZG93cy5oPgoKI2RlZmluZSBTSVpFIDMy
CgoKdm9pZCBmaWxsX2J5dGVzKHVpbnQ4X3QgKmEsIGludCBuKSB7CiAgICBp
bnQgaWR4OwogICAgZm9yIChpZHg9MDsgaWR4PG47IGlkeCsrKSB7CiAgICAg
ICAgYVtpZHhdID0gaWR4OwogICAgfQp9CgoKdm9pZCBwcmludF9ieXRlcyh1
aW50OF90ICphLCBpbnQgbikgewogICAgaW50IGlkeDsKICAgIGZvciAoaWR4
PTA7IGlkeDxuOyBpZHgrKykgewogICAgICAgIHByaW50ZigiMHglMDJ4ICIs
ICgodWludDhfdCopYSlbaWR4XSk7CiAgICAgICAgaWYgKChpZHggKyAxKSAl
IDggPT0gMCkgcHJpbnRmKCJcbiIpOwogICAgfQp9CgppbnQgbWFpbih2b2lk
KSB7CiAgICB3Y2hhcl90ICphLCAqYjsKICAgIHVpbnQ4X3QgKmFhOwogICAg
c2l6ZV90IHJldDsKICAgIExDSUQgY29sbGF0ZV9sY2lkOwogICAgaW50IGlk
eDsKICAgIGNvbGxhdGVfbGNpZCA9IDEwMzM7CiAgICBiID0gTCJiIjsKICAg
IGEgPSAod2NoYXJfdCopIG1hbGxvYyhTSVpFKTsKICAgIGFhID0gKHVpbnQ4
X3QqKSBhOwoKICAgIHNldGxvY2FsZShMQ19BTEwsICJlbl9VUy5VVEYtOCIp
OwoKICAgIHByaW50ZigidXNpbmcgd2NzeGZybTpcbiIpOwogICAgZmlsbF9i
eXRlcyhhYSwgU0laRSk7CiAgICBwcmludGYoImJlZm9yZTpcbiIpOwogICAg
cHJpbnRfYnl0ZXMoYWEsIFNJWkUpOwogICAgcmV0ID0gd2NzeGZybShhLCBi
LCA0KTsKICAgIHByaW50ZigiYWZ0ZXIgKCVkKTpcbiIsIHJldCk7CiAgICBw
cmludF9ieXRlcyhhYSwgU0laRSk7CgogICAgcHJpbnRmKCJcbnVzaW5nIExD
TWFwU3RyaW5nVyBkaXJlY3RseTpcbiIpOwogICAgZmlsbF9ieXRlcyhhYSwg
U0laRSk7CiAgICBwcmludGYoImJlZm9yZTpcbiIpOwogICAgcHJpbnRfYnl0
ZXMoYWEsIFNJWkUpOwogICAgCiAgICByZXQgPSBMQ01hcFN0cmluZ1coY29s
bGF0ZV9sY2lkLCBMQ01BUF9TT1JUS0VZIHwgTENNQVBfQllURVJFViwgYiwg
LTEsIGEsIDgpOwogICAgcHJpbnRmKCJhZnRlciAoJWQpOlxuIiwgcmV0KTsK
ICAgIHByaW50X2J5dGVzKGFhLCBTSVpFKTsKCiAgICBwcmludGYoIlxud2l0
aG91dCBMQ01BUF9CWVRFUkVWOlxuIik7CiAgICBmaWxsX2J5dGVzKGFhLCBT
SVpFKTsKICAgIHByaW50ZigiYmVmb3JlOlxuIik7CiAgICBwcmludF9ieXRl
cyhhYSwgU0laRSk7CiAgICAKICAgIHJldCA9IExDTWFwU3RyaW5nVyhjb2xs
YXRlX2xjaWQsIExDTUFQX1NPUlRLRVksIGIsIC0xLCBhLCA4KTsKICAgIHBy
aW50ZigiYWZ0ZXIgKCVkKTpcbiIsIHJldCk7CiAgICBwcmludF9ieXRlcyhh
YSwgU0laRSk7CiAgICBmcmVlKGEpOwogICAgCiAgICByZXR1cm4gMDsKfQo=


--001a114dc1fe93c5e5054f282037
Content-Type: text/plain; charset=us-ascii


--
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
--001a114dc1fe93c5e5054f282037--