Segfault if /proc/PID/maps is opened in parallel threads [CAUSE: RtlQueryProcessDebugInformation]

[Christian Franke]

Corinna Vinschen via Cygwin wrote:
> On Jul  2 18:28, Corinna Vinschen via Cygwin wrote:
>> On Jul  2 16:18, Christian Franke via Cygwin wrote:
>>> On Tue, 27 May 2025 17:44:10 +0200 Christian Franke wrote:
>>>> On Sun, 25 May 2025 16:46:49 +0200, Christian Franke wrote:
>>>>> On Sat, 24 May 2025 15:19:10 +0200, Christian Franke wrote:
>>>>>> If /proc/PID/maps is opened in parallel threads, the process PID
>>>>>> may segfault.
>>>>>>
>>>>>> Testcase:
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> Problem is not reproducible with any of the other /proc/PID/* files.
>>>>>>
>>>>> A closer look shows that the problem is unrelated to thread safety.
>>>>> The segfault also occurs when the following command is run
>>>>> simultaneously in two terminals:
>>>>>
>>>>> $ while cat /proc/1234/maps > /dev/null; do printf .; done
>>>>> .............cat: /proc/1234/maps: No such file or directory
>>>>>
>>>> The root of the problem is the call of RtlQueryProcessDebugInformation()
>>>> here:
>>>> https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/fhandler/process.cc;h=8fae9be5#l630
>>>>
>>>>
>>>> If this part is removed, the segfault does no longer occur. Then
>>>> /proc/PID/maps still work but the "[win heap ...]" information is
>>>> missing. No patch provided because I don't know whether this could
>>>> possibly be fixed without removing this functionality.
>>>>
>>>> A test with a separate test program shows that the problem is unrelated
>>>> to Cygwin: Parallel calls to RtlQueryProcessDebugInformation() with the
>>>> same PID could be used to crash this process. It also "worked" with
>>>> Notepad.exe.
>>>>
>>>> Possible Windows (Version 10.0.22631.5039) bug?
>> Looks very much like a Windows bug to me.  But the function is supposed
>> to be run under a debugger, so there's a chance multiple parallel calls
>> were never part of the picture.  And given the function is undocumented,
>> I guess we have to keep the broken pieces...
>>
>>> Testcase (attached):
>>> [...]
>>> Conclusion: Possible Windows bug in RtlQueryProcessDebugInformation().
>>> Cygwin should not use this function to provide "nice to have" types of
>>> information like "[win heap...]" if this may crash the target process.
>> RtlQueryProcessDebugInformation isn't only called to emulate maps,
>> it is also called from within dlsym().
>>
>> A valid patch might be to move the RtlQueryProcessDebugInformation
>> into its own function which adds a global lock.  But obviouly the
>> function can be called in a non-Cygwin process in parallel, so there's
>> no 100% safe way to do it.
>>
>> Any other idea?
> I just added two patches, one of them dropping RtlQueryProcessDebugInformation
> in favor of EnumProcessModules in dlsym(), the other by adding a global
> mutex to format_process_maps while accessing the debug buffer.  I could
> reproduce the crash even if RtlQueryProcessDebugInformation was serialized.
> I could only avoid the crash by serializing the entire code from
> RtlCreateQueryDebugBuffer up to and including RtlDestroyQueryDebugBuffer.
>
> This ignores native processes which have a hard time to access
> /proc anyway.

Many tests show that the problem with /proc/PID/maps does no longer 
occur, thanks. dlsym() not tested, sorry.

-- 
Thanks,
Christian