http://bugs.winehq.org/show_bug.cgi?id=60130 Bug ID: 60130 Summary: GetProcAddress() crashes with a stack overflow when a DLL export forwards to its own module name Product: Wine Version: 11.14 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@list.winehq.org Reporter: realmaitreal@deadmail.lat Target Milestone: --- Created attachment 81711 --> http://bugs.winehq.org/attachment.cgi?id=81711 sources + both binaries, sha1 b5346d4acdd636eae5fd13a8a986a030f805b48e A DLL that forwards an export to its own module name makes GetProcAddress() recurse until the thread stack is exhausted, killing the process. Attached is a minimal testcase (source included, ~20 lines): selffwd.dll - one export, "test_func", a forwarder to "SELFFWD.test_func", i.e. to the DLL's own base name fwdloop.exe - LoadLibraryA("selffwd.dll") then GetProcAddress(mod, "test_func") Steps to reproduce: 1. put selffwd.dll and fwdloop.exe in the same directory 2. wine fwdloop.exe Expected (Windows 10 x64, see windows-output.txt): GetProcAddress returns NULL, GetLastError() is 193 (ERROR_BAD_EXE_FORMAT), the program exits normally. Actual (wine-11.14, clean prefix, no DLL overrides, see wine-output.txt): err:virtual:virtual_setup_exception stack overflow ... and the process dies before GetProcAddress returns. find_forwarded_export() in dlls/ntdll/loader.c resolves the forwarder's module by base name, which finds the forwarding module itself, and recurses on the same export with unchanged arguments. Nothing bounds the chain. This is not specific to the testcase. It affects the common "proxy DLL" pattern, where a stub in an application's directory forwards its exports on to the system copy of the same name. I hit it originally with a third-party plugin DLL for the Steam client. -- 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.