Possible stack-based buffer overrun about wsock-trace HOT 17 CLOSED

Is this in _DEBUG-mode?

In common.c on line 580.

That is in get_guid_ole32_str(). Maybe some problem with alloca() or the result_size. I've never seen this. But then again, I don't build for (and use) x64 so much.

Maybe you can force using get_guid_internal_str() instead by setting use_ole32 = 0 in the wsock_trace config-file?

I guess the crash happens from a call to dump_wsaprotocol_info(). Can you check with e.g. installing CDB as the Postmortem debugger; cdb -iae, then run by cdb -c g test.exe.

from wsock-trace.

Also, try adding -Ge (force stack checking for all funcs) to the CFLAGS and rebuild everything.

from wsock-trace.

Thanks for the advice on using CDB.
In the case of the error I had with apps I linked with wsock_trace: I was using close() instead of closesocket() 😕

test.exe is unfortunately still chocking. I played a little with CDB but it will take some time for me to figure out what's causing this.
To be honest, I suspect it has something to do with my VS installation. I have been using a debug build for a while and maybe there's something left behind.
I'll try the cflag -Ge and see if this does the trick.

from wsock-trace.

Hehe

cl : Command line warning D9035 : option 'Ge' has been deprecated and will be removed in a future release
cl : Command line warning D9025 : overriding '/Ge' with '/Gs'

from wsock-trace.

after replacing -Gs in with -GS- (to completely disable buffer security checks) CDB reports:

(2464.1998): Access violation - code c0000005 (!!! second chance !!!)
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Windows\System32\KERNELBASE.dll -
*** WARNING: Unable to verify checksum for C:\Users\Ali\projects\wsock-trace\src\wsock_trace_x64.dll
KERNELBASE!WideCharToMultiByte+0x195:
00007ff8`7b381bd5 66413936        cmp     word ptr [r14],si ds:00340046`00350030=????

pretty useless for now I suppose. I keep looking...

from wsock-trace.

The call-stack could give a clue; command -kp I think.

from wsock-trace.

Did you try setting use_ole32 = 0 in wsock_trace config-file?
If it's not a Ole32 bug, it could be a buffer-overrun in dump.c somewhere. Try increasing the buffer in dump_aliases().

from wsock-trace.

I was caught up with work the past two days.

After my last comment, I did a stack-walk (kb). I am not good at this still, but it seems to show that the problem is related to the result_size.

0:000> kb
RetAddr           : Args to Child                                                           : Call Site
00007ff8`4ada35b6 : 00007ff8`7b3269f8 00007ff8`7b326a08 000000e3`00000001 00000000`00000000 : KERNELBASE!WideCharToMultiByte+0x195
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Windows\SYSTEM32\ntdll.dll -
00000000`007d0032 : 000000e3`cf8ffb44 00007ff8`4b025918 00000000`00000028 00007ff8`7b326a08 : wsock_trace_x64!get_guid_ole32_str+0xa6
000000e3`cf8ffb44 : 00007ff8`4b025918 00000000`00000028 00007ff8`7b326a08 00000000`00000000 : 0x7d0032
00007ff8`4b025918 : 00000000`00000028 00007ff8`7b326a08 00000000`00000000 00007ff8`4ada5b10 : 0x000000e3`cf8ffb44
00000000`00000028 : 00007ff8`7b326a08 00000000`00000000 00007ff8`4ada5b10 000000e3`cf8ffb44 : wsock_trace_x64!result
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Windows\System32\ucrtbase.dll -
00007ff8`7b326a08 : 00000000`00000000 00007ff8`4ada5b10 000000e3`cf8ffb44 00000000`000000ff : 0x28
00000000`00000000 : 00007ff8`4ada5b10 000000e3`cf8ffb44 00000000`000000ff 000000e3`cf8ffba4 : ucrtbase!wctype+0x33048

As you suggested correctly, setting use_ole32 to 0 in the wsock_trace config file helps. No crash at the end.
I am wondering:
Is that good idea? Will I be loosing functionality/features when I set use_ole32 to 0? Can you explain the difference?

from wsock-trace.

I created a debug build and wanted to use that for another trace. The test application got stuck much earlier here:

• 66.413 sec: c:/Users/Ali/projects/wsock-trace/src/test.c(371) (test_select+476):
  select (n=0, rd, wr, ex, {tv=1.000001s}) --> (rc=-1) WSAENOTSOCK (10038).
  fd_input -> rd: 528
  wr: 336,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29
  ex:

And this box showed up:

Not sure if this is related or not, but this seems to confirm the suspicion you had with dump.c.

from wsock-trace.

My mistake with the char / wchar_t mess. Try this patch:

--- a/src/common.c
+++ b/src/common.c
@@ -571,7 +571,7 @@ char *fix_path (const char *path)

 static const char *get_guid_ole32_str (const GUID *guid, char *result, size_t result_size)
 {
-  wchar_t *str = alloca (result_size);
+  wchar_t *str = alloca (2*result_size);
   DWORD    len;

   strcpy (result, "{??}");

Can you explain the difference?

use_ole32 = 0 simply means not to use StringFromGUID2() to get a string from a GUID. But to do it internally using get_guid_internal_str(). Look in common.c.

from wsock-trace.

the patch works perfectly. Thanks

from wsock-trace.

Any clue regarding the heap corruption in dump.c when build in debug mode?

from wsock-trace.

It seems only 64-bit / debug-mode shows a bug in dump_select(). Try this:

--- a/src/dump.c
+++ b/src/dump.c
@@ -1495,7 +1495,7 @@ void dump_addrinfo (const struct addrinfo *ai)
 fd_set *copy_fd_set (const fd_set *fd)
 {
   fd_set *copy;
-  size_t  size;
+  size_t  size, count;
   u_int   i;

   if (!fd)
@@ -1507,12 +1507,14 @@ fd_set *copy_fd_set (const fd_set *fd)
    * typedef struct fd_set {
    *         u_int  fd_count;
    *         SOCKET fd_array[FD_SETSIZE];
-   *      } fd_set;
+   *       } fd_set;
    *
+   * 'FD_SETSIZE' is defined to 64 in <winsock.h> by default.
    * But we cannot assume a certain 'FD_SETSIZE'.
-   * Just allocate according to 'fd_count'.
+   * Just allocate according to the maximum of 64 and 'fd_count'.
    */
-  size = fd->fd_count * sizeof(SOCKET) + sizeof(u_int);
+  count = max (64, fd->fd_count);
+  size = count * sizeof(SOCKET) + sizeof(u_int);
   copy = malloc (size);

   copy->fd_count = fd->fd_count;

Which allocates a new fd_set of minimum 64 sockets.

from wsock-trace.

The get_guid_ole32_str() bug is now fixed by 67b0058
But I'll keep this issue open until the copy_fd_set() bug is resolved.

from wsock-trace.

👍 👍
all good

from wsock-trace.

Hopefully fixed in 7299508. Closing.

from wsock-trace.

Is this in _DEBUG-mode?

In common.c on line 580.

That is in get_guid_ole32_str(). Maybe some problem with alloca() or the result_size. I've never seen this. But then again, I don't build for (and use) x64 so much.

Maybe you can force using get_guid_internal_str() instead by setting use_ole32 = 0 in the wsock_trace config-file?

I guess the crash happens from a call to dump_wsaprotocol_info(). Can you check with e.g. installing CDB as the Postmortem debugger; cdb -iae, then run by cdb -c g test.exe.

Changing it from Debug-mode, removed the error for me

from wsock-trace.