On 1/15/21 4:20 PM, Paul Gofman wrote:
The structure introduced by these patches appears to be more vulnerable to fatal destruction by app's out of bound and use after free accesses. I've tracked several memory corruption bugs in the past which were reproducible with these patches but not on Windows and not with Wine's current heap implementation. Do you think it really worth it, given it doesn't bring the heap structure closer to that on Windows, and doesn't solve many heap related performance degradation issues? I thought your LFH implementation is better both for compatibility and performance.
Ah, I wasn't aware of such issues, and I didn't see any myself so far.
I'm not entirely sure what to do about use-after free in general, and it could be an issue, even with the current simpler linked list-only struct.
There is already a pending_free buffer that is supposed to mitigate such issues, and it should handle these patches in the same way. Maybe it's just not big enough.
About the LFH implementation:
It should solve the performance problem, but it wasn't specifically designed to be compatible with whatever Windows is doing at the moment.
It may not be worse than the current Wine heap though, as AFAICS, Windows implementation already varies quite a bit between Windows versions, and none apparently match what Wine is doing (for instance looking at block headers magic and fields).
What's probably more or less compatible already is the tagHEAP fields, at least for the flags and such, which are still used for the returned heap pointers.
Cheers,