Buffer overflow in match_hash_tokens(), when checking filename with 20 characters Mac OS stack protection aborts the program

[akda5id]

I've got an odd one here. When I check a .sfv that contains a filename with 20 characters in the stem of the filename (before the first '.'), RHash v1.4.6 will error out at that line with "zsh: abort".

Edit: ignore the following testing notes, and see the first comment below, there is a off by one buffer overflow in match_hash_tokens().

If I change the filename but check the same file, it completes as expected, so it doesn't seem to be a problem with the file. In fact I can repro this with any filename, existing or not, with 20 characters in the base part of the name. But of course this doesn't happen on a linux box built from source. I have verified on osx built from head of this repo, and also installed from homebrew.

I would suspect that it is trying to check if it is a valid hash instead of a filename, and hitting some error there and dumping out. This is despite me specifying crc32 on the command line (rhash -cC problem.sfv).

Some testing:
01234567890123456789.anything errors
01234567890123456789A.anything is fine, as is 0123456789012345678.anything
anydir/01234567890123456789.anything is fine, but:
01234567890123456789/anything.anything errors.
note that I am using the string 01234567890123456789, but any 20 character string works, including strings that have non base64 characters in it.

[akda5id]

Looks like there is a buffer overflow in match_hash_tokens()
The buffer is declared as char buf[20], but I guess the check if (len >= 20) happens after writing buf[len]. When the filename has exactly 20 characters, the loop writes to buf[20] before checking? I could have that wrong, I don't really speak c.

In any case changing it to char buf[21] fixes the crash. Probably better to get the check before the write, but I can't quite decipher the loop logic, so better for you to figure that out.

* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00000001817f2a60 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x000000018182ac20 libsystem_pthread.dylib`pthread_kill + 288
    frame #2: 0x0000000181737ab4 libsystem_c.dylib`__abort + 136
    frame #3: 0x0000000181728694 libsystem_c.dylib`__stack_chk_fail + 96
    frame #4: 0x000000010000b7b4 rhash`match_hash_tokens + 2064
    frame #5: 0x000000010000a2dc rhash`process_hash_file + 912
    frame #6: 0x000000010000ff4c rhash`scan_files_callback + 572
    frame #7: 0x0000000100009310 rhash`scan_files + 148
    frame #8: 0x000000010000fadc rhash`main + 988
    frame #9: 0x00000001814a20e0 dyld`start + 2360

MacOS has stack protection on by default so this bug was caught there, but as far as I can see, this would have been writing out of bounds on linux also.