[Bug 37669] Resetting a write watch can cause memory access violation in kernel

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=37669

--- Comment #23 from Dmitry Timoshkov <dmitry at baikal.ru> ---
(In reply to Dmitry Timoshkov from comment #21)
> > Please give it a try. Works well with your attached tests for me.
> 
> Thank you Sebastian, new patch set works quite well, and indeed my test no
> longer shows a read error. Unfortunately the real application I have here
> still dies on an exception on signal thread after 15-20 minutes of work under
> pretty heavy load. I haven't figured out yet the reason, still investigating.

Finally found time to investigate the problem. Sebastian's patch works
perfectly for recv/WSARecv/recvfrom/WSARecvFrom, now the problem has appeared
in another place: asynchronous callback of AcceptEx - WS2_async_accept.
This callback writes into the application provided buffer all over the place,
and I personally don't see a reasonable way to fix it without allowing SEH on
a signal stack. A usual approach used in Wine code of checking the application
provided buffer with IsBadWritePtr at the start of WS2_AcceptEx just postpones
the crash and creates another race between the GC thread and winsock code.

While investigating the problem with AcceptEx I have found another place
where write watches cause a race and a lead to a failure to read normal
disk file in a .net application I'm working on: it's ReadFile. While fixing
ReadFile (actually NtReadFile) was trivial (I'll attach a patch) since it's
not called on a signal stack, this shows that potentially any place of Wine
code is vulnerable to the races caused by write watches.

Just for the background: this .net application is a very simple client/server
written using .net's System.Runtime.Remoting class.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.