winsup\cygwin\path.cc issues

[Ken Harris <Ken.Harris@mathworks.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 3550 bytes --]

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

                two problems appear:
                #1 –  line 2802 in https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/path.cc;h=a132a0a7e0418ba921eefab72fade9930baadff3;hb=HEAD
                pointer ‘p’ will underflow if a backslash is not found in ‘path’.
                It may be that it finds an (unrelated) backslash in someone else’s buffer and fails benignly…but in MSYS2, I’ve see it bump up against unmapped address space a fail very cryptically (as an access violation early in dcrt0.cc initialization before the signal handler is installed).

                #2 – The reason it fails to find its expected backslash appears within path.cc again beginning on line 1381, when a drive-letter is inserted into destination path. Later in normalize_win32_path(), when “../” expressions are applied (i.e. lines 1421 and 1441), these calculations don’t take into account the size of the inserted drive letter (plus colon) and results in overwriting the top-most slash with pathname characters – which then exercises issue #1.

                If echo doesn’t crash, there doesn’t appear to be any obvious evidence of this error. In fact, from debugging a recent version of Cygwin’s “echo.exe”, it looked like the environment block occupying memory at a lower address than ‘path’ contained plenty of backslashes to break line 2802’s loop. In MSYS2, it seems occasionally  (though not always), memory below ‘path’ pointer will _not_ contain a backslash. The result seems to be just C0000005 returned by the echo.exe process.

                I’m not familiar with how to build Cygwin so I haven’t verified this with putting an assert in code. I did debug echo.exe with WinDBG and following how the caller of NtCreateFile handles C0000034 return value (which least to the ‘p’ underflow), watched the disassembly for line 2802:

cygwin1!setpassent+0x22a3:
00000001`800de563 8078ff5c        cmp     byte ptr [rax-1],5Ch ds:00000006`0000ffee=00

                march down lower than the path string:

00000006`0000fff0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ..................
00000006`00010002 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ..................
00000006`00010014 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ..................
00000006`00010026 00 00 13 80 00 00 00 00 00 00 43 3a 43 6d 79 2e 6c 6f  ..........C:Cmy.lo
00000006`00010038 67 00 20 46 69 6c 65 73 5c 4d 41 54 4c 41 42 00 52 32  g. Files\MATLAB.R2
00000006`0001004a 30 31 38 62 00 6c 6e 6b 00 00 00 00 00 00 00 00 00 00  018b.lnk..........
00000006`0001005c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ..................
00000006`0001006e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ..................

                Hope you find this of use.

                Thanks,
                -ken

\0ТÒÐÐ¥\a&ö&ÆVÒ\a&W\x06÷'G3¢\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒ÷\a&ö&ÆV×2æ‡FÖÀФd\x15\x13¢\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöf\x17\x12ðФFö7VÖVçF\x17F–öã¢\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöFö72æ‡FÖÀÐ¥Vç7V'67&–&R\x06–æfó¢\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöÖÂò7Vç7V'67&–&R×6–×\x06ÆPРÐ