Reading and writing from/to the windows::stream_handle will cause blind stack writes

[smueller@…]

ReadFile and WriteFile are being called with LPOVERLAPPED arguments. The handle involved is attached to an iocompletionport so the I/O calls are handled asynchronously. The parameters that receive the number of bytes received and sent in the start_read_op and start_write_op functions respectively must be NULL if the operation is to be completed asynchronously.

The problem is that the parameters are not set to NULL, and are set to locations on the stack adjacent to the I/O call. This results in writing the number of bytes sent or received into that location sometime after the call was made. The stack involved in that operation may be off doing other things, hence the blind write.

This problem exists in 1.54 as well.

[smueller@…]

Suggested fix (untested at time of post)

[smueller@…]

patch from SVN head

[smueller@…]

This is a problem for most of the I/O calls used by the Windows implementation: WriteFile ReadFile WSASend WSARecv WSASendTo WSARecvFrom

Interestingly enough, AcceptEx does not have this problem. MSDN explicitly states that if AcceptEx returns ERROR_PENDING to indicate asynchronous completion, the bytes received parameter is not written to at all.

[smueller@…]

Patch for SVN head of win_iocp_socket_service_base.ipp

[smueller@…]

Note that the first attachment, win_iocp_handle_service.ipp.patch, had the arguments reversed for diff. It's a rookie mistake, and for that I apologize. Please disregard that patch. The other two are good, though.

This is an important fix, as the cross-thread stack write is a notoriously evil bug to track down. I had this same bug in server code I am currently maintaining, and I managed by some massive luck to track it down. It can cause all manner of craziness that you'd never expect. In the best case, stack data after (before) the current frame on the thread is written. In the best fault case, you get a crash. In the worst case, you get completely unexpected program flow.

[chris_kohlhoff]

This was followed up in private emails. It is not an issue.