fix memmove out-of-bounds access

[comicfans]

found by fuzzer + address sanitizer .

[selmf]

Great catch! I'd like some modifications before merging though:

• static inline instead of macro, use size_t
• sizeof(data) insteas of defining BUF_SIZE

~~There is some existing code in the rar parser you can reuse for this (I will check this once I'm home). I'd also like to cross-check the bug with the zip specification to make sure the solution is the best one, so you don't need to rewrite your patch right away ;)~~

Edit: After spending some more time on this I think there is an easier solution to this problem. The code only ever uses the first 4 bytes copied by memmove, everything else is overwritten when the next chunk of data is read. So to fix the problem it should be enough to change the memmove call to:

memmove(data, data + count - 4, 4);

[selmf]

@comicfans could you test if the changed memmove call fixes the problem for you? If yes I need to know if you want to update you PR or if I just should push the fix.

[comicfans]

Hi @selmf , I've tested this by previously crashed input, confirm it worked. please just push your fix