Re: winsup\cygwin\path.cc issues

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).
I installed and built cygwin1.dll with an added assert in path.cc to identify when the buffer underrun condition I originally described occurs:
$ 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 >= path);
Thus, a simple:
cat '\A../../../B'
will result in the assert firing:
kharris@ah-kharris /usr/src
$ cat '\A../../../B'
assertion "p >= 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)
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.
I've applied this "correction" in our MSYS2 code. I hope to get some flight-time with it soon (long duration, automated processing) and if it causes unexpected problems, I'll report back on that. Otherwise, I just hope it might be helpful to anyone who might run into similar puzzling circumstances (the puzzle is when the errant 'p' pointer _doesn't_ find a stray backslash in someone else's memory. It segv-s and _that_ was the nasty part of the puzzle).
Thanks,
-Ken
On 5/2/2018 3:49 PM, Ken Harris wrote:
Hi:
While originally investigating a sporadic failure in MSYS2, I believe I found that its origin may actually be within Cygwin.
Given the following command sequence on cygwin64 in a CMD.EXE command prompt (on Windows 10 x64 if it matters).
cd C:\Cygwin64\bin
echo.exe running \"test\" logging to ../../../my.log
Not clear to me what is the exact command line to replicate
In addition "C:\Cygwin64\bin" is "/bin" so where do you expect
/bin/../../../my.log to be ?
Regards
Marco