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:cc:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=gr3yOEwKdebOo0mW4VhDukCMEGwgt8DflzocjVYRwRG4aXPV2gWJH
	cohW0EpqUWLtN5xy6cNRa7oNe9eMBqcX4KOtpST82bpWSJjw75+ErxiQ7zXEwWXe
	eP7YLsPA/tzzUQ4of0JuEgy/WW0MhTnGu0ifKrPPRxCGZRDMRnPat4=
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
Date: Tue, 29 May 2018 18:31:41 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Cc: Ken Harris <Ken DOT Harris AT mathworks DOT com>
Subject: Re: winsup\cygwin\path.cc issues
Message-ID: <20180529163141.GI3501@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com, Ken Harris <Ken DOT Harris AT mathworks DOT com>
References: <DM2PR0501MB1358382033C52CD40E92634F8A860 AT DM2PR0501MB1358 DOT namprd05 DOT prod DOT outlook DOT com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="cpvLTH7QU4gwfq3S"
Content-Disposition: inline
In-Reply-To: <DM2PR0501MB1358382033C52CD40E92634F8A860@DM2PR0501MB1358.namprd05.prod.outlook.com>
User-Agent: Mutt/1.9.2 (2017-12-15)

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

Hi Ken,

On May  4 01:23, Ken Harris wrote:
> Hi Marco: Sorry for not replying to the original exchange we had. I
> wasn't subscribed to the list but now I am so it won't happen again
> (so I'm quoting our exchange below).
>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
>                 I installed and built cygwin1.dll with an added assert
>                 in path.cc to identify when the buffer underrun
>                 condition I originally described occurs:
>=20
> $ diff -b
> ./cygwin-2.10.0-1.src/newlib-cygwin/winsup/cygwin/path.cc.ORIG
> ./cygwin-2.10.0-1.src/newlib-cygwin/winsup/cygwin/path.cc 2803c2803 <
> ; ---
> >                   assert(p >=3D path);
>=20
>                 Thus, a simple:
>=20
>                 cat '\A../../../B'
>=20
>                 will result in the assert firing:
>=20
> kharris AT ah-kharris /usr/src $ cat '\A../../../B' assertion "p >=3D path"
> failed: file "../../.././winsup/cygwin/path.cc", line 2803, function:
> int symlink_info::check(char*, const suffix_info*, fs_info&,
> path_conv_handle&) Aborted (core dumped)
>=20
> Attached is a patch (in addition to the added assert) with what I
> *think* might really fix the problem. This was where the expected
> backslash got squashed which allowed symlink_info::check() to go
> "negative" with its 'p' pointer and look for a backslash in someone
> else's memory.

Thanks for your preliminary work, but as far as I can see this isn't the
entire solution.  The same problem occurs if your CWD is the root of a
drive, e.g., C:\, and you call cat A../../../B.  Even simpler, try `cat
'C:\A../../../B''

The reason is that the code in normalize_win32_path never actually
ignores drive prefixes.  There's an implicit (and oh so wrong) assumption
that any path starts with a slash or backslash one way or the other.
It's pretty weird that it took so long to find this blatant problem.

I applied a patch which hopefully fixes this problem in all code paths:
https://sourceware.org/git/?p=3Dnewlib-cygwin.git;a=3Dcommitdiff;h=3D35998f=
c2fa6c

I also left your assertion in the code for now as an additional patch
https://sourceware.org/git/?p=3Dnewlib-cygwin.git;a=3Dcommitdiff;h=3D7d00a5=
e320db
just to be sure, but I will take this out again before a release.

I uploaded new developer snapshots to https://cygwin.com/snapshots/
containing the above patches.  Please give them a try.


Thanks,
Corinna

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

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

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlsNgGwACgkQ9TYGna5E
T6AJ5hAAgTCCLL3BScHgNa3ztJ3Pi/Fqd61cM6h2AJ6sKK2ULIhuemvTPjyut8F6
PeMq3OsgoB20G4NWlsWPSJKWm2vbRFjL2sVpXomjrxj1AjgdIo1tEvn1hgICPRTf
YmpRbN8WypQvkgzZHLSAfCCVxXFKvRckls1RBmMPMl7eRFOFYjKp0vY0rlHrQ5kK
+JK8TegIADey1N9lryCZ77YDbDmAFkd6QwIHOPZzAOdUXsQerPNC/5nM+N7gyFli
DA70uPwkU2KFyurUn+EOsdpzvE3Kc7FEMEyFSTxmZBlRH8hAF7wNNcAqM1NAuatB
O7LKP33CHNZGH91iAY8O6/IhsxNKqR73uFztD5VAzfipivuXRg0EmcJs7DX1LIiQ
UbUjnYq/4kP+lXS3v2sTp9vfvcSNYoJGtvQWT4fWImSJ6hYr4hT/a52CnxbDc+Gi
IlEoaLhrD2XmAj5Kat3szdHWcbKWIf+1pw2kt2eU8R2cpfn4h2hoMjQBQOBp8GHN
3XCwXSyeTYGlMDfnUCrWQ4vkCICq3Bjc5gzElmH29B7k0QxFEpHU5t0tVv5n8Wae
3q02ys2m2nVyxNs54H/Htb5UGJIyR2DTCQR5pH/A8+nEL0kYkLNN0GVjiS5IcSLf
9CEbHApfZIn7Pp2TEsMt8eoP9SORNajpOiKsci99NMvNs3JHjTs=
=/hby
-----END PGP SIGNATURE-----

--cpvLTH7QU4gwfq3S--