winsup\cygwin\path.cc issues

[Ken Harris]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: path.cc.patch
Type: application/octet-stream
Size: 1745 bytes
Desc: path.cc.patch
URL: <http://cygwin.com/pipermail/cygwin/attachments/20180504/5f6a3fba/attachment.obj>
-------------- next part --------------

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