Fix a race between sending data and closing the service client port

[manzaltu]

According to documentation, FltCloseClientPort and FltSendMessage are synchronized by both receiving a pointer to the same location that holds the opaque port handle.

This fix passes the global client port to both function calls.

Please note that I removed the unnecessary comparison between the context and the global port. If the connection was successful, the global service client port and the client port in the provided context both have to be the same.

[jessk-msft]

Is this code change a fix for a Windows blue-screen crash that occurred? Can you provide any information about any problem that occurred because of existing code?

[manzaltu]

I’ll try to provide more context to this PR.

I’m not a user of this driver. I’m doing some work that involves modeling the safety constrains of some Windows kernel APIs. As part of this work I looked for usage examples, came across your code and saw the aforementioned issue, which violates synchronization between API calls FltSendMessage and FltCloseClientPort.
These two API calls are not thread-safe when called concurrency. Therefore, they have a mechanism to synchronize their port access, but this requires that they both get a pointer to the same location where the opaque port handle resides. You can see this mentioned in the Remarks section of FltCloseClientPort documentation.

Since this is a race condition type of bug, failing to do so may not be an obvious error, but with enough time and luck, eventually it should lead to a BSOD.

You can find additional info here https://community.osr.com/t/fltsendmessage-clientport-use/58204/4 and here https://community.osr.com/t/reference-by-pointer-bsod-windows-8/47574/3.