Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

A few Questions about repository #1

Closed
jmalak opened this issue Feb 15, 2020 · 1 comment
Closed

A few Questions about repository #1

jmalak opened this issue Feb 15, 2020 · 1 comment

Comments

@jmalak
Copy link

jmalak commented Feb 15, 2020

Hi,
I have a few questions only.

  • I am not sure if it is intentional, but default branch in this repository is 2.2.10-sezero branch.
    It is a little confusing for me, I expected usuall master branch.
  • What is relation to Gisle Vanen repository , I would like to submit some Watcom fixes that I am not sure to which repository it is better
sezero pushed a commit that referenced this issue Jun 14, 2020
@jmalak
Merge pull request #1 from gvanem/master
cb66535 
update from Watt-32 repository
@sezero
Copy link
Owner

sezero commented Jun 23, 2020

I am not sure if it is intentional, but default branch in this repository is 2.2.10-sezero branch.
It is a little confusing for me, I expected usuall master branch.

It is intentional. I usually use 2.2.10+fixes+some improvements in my code, that's why it's my default branch.

What is relation to Gisle Vanen repository

@gvanem did not originally have a git repo (or any repo) of watt32, so I generated one on my own, and he later forked it for mainstream development.

@sezero sezero closed this as completed Jun 23, 2020
sezero pushed a commit that referenced this issue Jun 29, 2023
@gvanem
Options for ASAN/UBSAN:
9dffd41 
  *) 'USE_ASAN=1' to enable the "Address Sanitizer"
     in clang-cl. This found several important bugs.
  *) 'USE_UBSAN=1' option for "Undefined Behavior Sanitizer (UBSan)".
     I've not tried this yet.

Some of the ASAN findings:

  ==3924==ERROR: AddressSanitizer: stack-use-after-scope on address 0x00871b77ed12 at pc 0x7ffc7988efb1 bp 0x00871b77ec30 sp 0x00871b77ec38
  READ of size 1 at 0x00871b77ed12 thread T0
    #0 0x7ffc7988efb0 in _w32_strtok_r E:\WATT\src\misc_str.c:371
    #1 0x7ffc797e26f6 in getservent E:\WATT\src\getserv.c:236
    #2 0x7ffc797e1f9a in _w32_ReadServFile E:\WATT\src\getserv.c:124
    #3 0x7ffc7981c20a in _w32_parse_config_table E:\WATT\src\pcconfig.c:447
    #4 0x7ffc7981d3c7 in tcp_inject_config_direct E:\WATT\src\pcconfig.c:892
    #5 0x7ffc7981e919 in tcp_parse_file E:\WATT\src\pcconfig.c:1148
    #6 0x7ffc7981f256 in _w32_tcp_config E:\WATT\src\pcconfig.c:1266
    #7 0x7ffc7987e708 in watt_sock_init E:\WATT\src\sock_ini.c:912
    #8 0x7ff7b94e1117  (E:\WATT\bin\country.exe+0x140001117)
    #9 0x7ff7b94e18cf  (E:\WATT\bin\country.exe+0x1400018cf)
    #10 0x7ffcd7fe7613  (C:\Windows\System32\KERNEL32.DLL+0x180017613)
    #11 0x7ffcd88026f0  (C:\Windows\SYSTEM32\ntdll.dll+0x1800526f0)

  Address 0x00871b77ed12 is located in stack of thread T0 at offset 82 in frame
      #0 0x7ffc797e231f in getservent E:\WATT\src\getserv.c:182

Fixed by:
  diff --git a/src/getserv.c b/src/getserv.c
  index cdd1edf..18a5c40 100644
  --- a/src/getserv.c
  +++ b/src/getserv.c
  @@ -182,6 +182,7 @@ struct servent * W32_CALL getservent (void)
   {
     static struct _servent s;
     char  *name, *proto, *alias, *tok_buf = NULL;
  +  char   buf [2*MAX_NAMELEN], *tok;
     WORD   port;
     int    i;

  @@ -193,9 +194,7 @@ struct servent * W32_CALL getservent (void)

     while (1)
     {
  -    char buf[2*MAX_NAMELEN], *tok;
  -

--------------------------------------------------------------------------------

  ==11548==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7ffc79d55b00 at pc 0x7ffc7981c766 bp 0x0019c918f320 sp 0x0019c918f328
  WRITE of size 4 at 0x7ffc79d55b00 thread T0
    #0 0x7ffc7981c765 in set_value E:\WATT\src\pcconfig.c:362
    #1 0x7ffc7981bf2b in _w32_parse_config_table E:\WATT\src\pcconfig.c:439
    #2 0x7ffc797cd9d4 in echo_config E:\WATT\src\echo.c:88
    #3 0x7ffc7981e7e9 in tcp_parse_file E:\WATT\src\pcconfig.c:1148
    #4 0x7ffc7981f126 in _w32_tcp_config E:\WATT\src\pcconfig.c:1266
    #5 0x7ffc7987e5d8 in watt_sock_init E:\WATT\src\sock_ini.c:912
    #6 0x7ff640c515ce  (F:\gv\net\watt\bin\tcpinfo.EXE+0x1400015ce)
    #7 0x7ff640c51c0f  (F:\gv\net\watt\bin\tcpinfo.EXE+0x140001c0f)
    #8 0x7ffcd7fe7613  (C:\Windows\System32\KERNEL32.DLL+0x180017613)
    #9 0x7ffcd88026f0  (C:\Windows\SYSTEM32\ntdll.dll+0x1800526f0)

  0x7ffc79d55b00 is located 32 bytes to the left of global variable 'disc_port' defined in 'echo.c' (0x7ffc79d55b20) of size 2
    'disc_port' is ascii string ' '
  0x7ffc79d55b02 is located 0 bytes to the right of global variable 'echo_port' defined in 'echo.c' (0x7ffc79d55b00) of size 2
    'echo_port' is ascii string ''

Fixed by:
  diff --git a/src/echo.c b/src/echo.c
  index 68b95a1..c50f7c6 100644
  --- a/src/echo.c
  +++ b/src/echo.c
  @@ -75,13 +75,13 @@ static void W32_CALL echo_config (const char *name, const char *value)
     static const struct config_table echo_cfg[] = {
               { "DAEMON", ARG_ATOI,    (void*)&do_echo   },
               { "HOST",   ARG_RESOLVE, (void*)&echo_host },
  -            { "PORT",   ARG_ATOI,    (void*)&echo_port },
  +            { "PORT",   ARG_ATOW,    (void*)&echo_port },
               { NULL,     0,           NULL              }
             };
     static const struct config_table disc_cfg[] = {
               { "DAEMON", ARG_ATOI,    (void*)&do_disc   },
               { "HOST",   ARG_RESOLVE, (void*)&disc_host },
  -            { "PORT",   ARG_ATOI,    (void*)&disc_port },
  +            { "PORT",   ARG_ATOW,    (void*)&disc_port },
               { NULL,     0,           NULL              }
             };

--------------------------------------------------------------------------------
With 'winpkt.trace = 1', this code:

  if (winpkt_trace_level > 0 && dump_fname[0])
  {
    const char *file = expand_var_str (dump_fname);

    _strlcpy (dump_fname, file, sizeof(dump_fname));

Causes this ASAN issue:
  ==2160==ERROR: AddressSanitizer: strcpy-param-overlap: memory ranges [0x7ffc79d59f60,0x7ffc79d59f73) and
   [0x7ffc79d59f60, 0x7ffc79d59f73) overlap
    #0 0x7ffc6b41177f in __asan_wrap_strcpy D:\a\_work\1\s\src\vctools\asan\llvm\compiler-rt\lib\asan\asan_interceptors.cpp:424
    #1 0x7ffc7988e583 in _strlcpy E:\WATT\src\misc_str.c:237
    #2 0x7ffc79904f46 in _w32_pkt_eth_init E:\WATT\src\winpkt.c:418

Fixed by:
  if (winpkt_trace_level > 0 && dump_fname[0])
  {
    const char *file = expand_var_str (dump_fname);

    if (file != dump_fname)  /* not overlapping data */
       _strlcpy (dump_fname, file, sizeof(dump_fname));

etc., etc.
sezero pushed a commit that referenced this issue Dec 18, 2023
@gvanem
Fixed an issue with a "0 bytes" (!) overflow in 'version.c'.
98b3af6 
Found by ASAN:
  ==4348==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7ffc9de62d95 at pc 0x7ffc9dc87635 bp 0x0013906ff8f0 sp 0x0013906ff8f8
  READ of size 1 at 0x7ffc9de62d95 thread T0
      #0 0x7ffc9dc87634 in strtrim E:\WATT\src\misc_str.c:283
      #1 0x7ffc9dc925a8 in wattcpBuildCflags E:\WATT\src\version.c:599
      #2 0x7ff7168c1a31 in main E:\WATT\bin\tcpinfo.c:460
      #3 0x7ff7168c20e3 in invoke_main D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
      #4 0x7ff7168c20e3 in __scrt_common_main_seh D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
      #5 0x7ffcbcfe7343  (C:\Windows\System32\KERNEL32.DLL+0x180017343)
      #6 0x7ffcbd1226b0  (C:\Windows\SYSTEM32\ntdll.dll+0x1800526b0)

  0x7ffc9de62d95 is located 0 bytes to the right of global variable 'w32_cflags2' defined in 'version.c:569:7' (0x7ffc9de62d40) of size 85
  SUMMARY: AddressSanitizer: global-buffer-overflow E:\WATT\src\misc_str.c:283 in strtrim
sezero pushed a commit that referenced this issue Dec 20, 2023
@gvanem
Compiling 'Watt-32*.dll' with 'clang-cl -fsanitize=undefined'
69e0939 
(i.e. 'USE_UBSAN=1'), showed a bunch of issues. This is the
UBSAN ("Undefined Behavior Sanitizer") feature.

It showed issues like these:
  winpkt.c:470:7: runtime error: call to function get_descr_pcap through pointer to incorrect function type
  'int (*)(const void *, char *, unsigned int)'
  E:\WATT\src\winpkt.c:1280: note: get_descr_pcap defined here
      #0 0x6be2858f in _w32_pkt_eth_init E:\WATT\src\winpkt.c:469
      #1 0x6bcfd631 in _w32__eth_init E:\WATT\src\pcsed.c:641
      #2 0x6e1be6  (F:\gv\net\watt\bin\tracert.exe+0x401be6)
      #3 0x6eef2c  (F:\gv\net\watt\bin\tracert.exe+0x40ef2c)
      #4 0x7770fcc8  (C:\Windows\System32\KERNEL32.DLL+0x6b81fcc8)
      #5 0x77b37c6d  (C:\Windows\SYSTEM32\ntdll.dll+0x4b2e7c6d)
      #6 0x77b37c3d  (C:\Windows\SYSTEM32\ntdll.dll+0x4b2e7c3d)

  SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior winpkt.c:470:7 in
  winpkt.c:474:8: runtime error: call to function get_if_type_pcap through pointer to incorrect function type
  'int (*)(const void *, unsigned short *)'
  E:\WATT\src\winpkt.c:1254: note: get_if_type_pcap defined here
      #0 0x6be285a4 in _w32_pkt_eth_init E:\WATT\src\winpkt.c:473

The same cause for *all* "incorrect" use of func-pointers.

But turn some off for now using '__attribute__((no_sanitize("undefined")))'.
sezero pushed a commit that referenced this issue Jan 16, 2024
@gvanem
Fix for this UBSAN issue:
b553908 
  pcarp.c:1146:23: runtime error: index -1 out of bounds for type 'struct route_entry[32]'
      #0 0x7ff8e39d6349 in route_check_timeouts E:\WATT\src\pcarp.c:1150
      #1 0x7ff8e39d6349 in arp_daemon E:\WATT\src\pcarp.c:1499
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jmalak @sezero