Fix buffer overflow in decompression fast path

[lilu5458]

This fix addresses a buffer overflow vulnerability in the snappy decompression fast path. The issue was that several functions were unconditionally writing kSlopBytes (64 bytes) regardless of the actual copy length, which could lead to writing beyond the buffer boundary when the buffer had insufficient space.

Changes made:

1. Modified SnappyArrayWriter::AppendFromSelf to use len instead of kSlopBytes in memmove
2. Fixed MemCopy64 non-AVX path to copy only size bytes
3. Added boundary checks in DecompressBranchless before MemCopy64 calls
4. Removed unconditional deferred copy at DecompressBranchless exit

Impact:

• Prevents buffer overflow when decompressing malicious or malformed snappy streams
• Maintains backward compatibility with valid snappy streams
• Normal compression/decompression functionality is not affected

Testing:

• Verified that the vulnerability is fixed using a proof-of-concept test
• Verified that normal compression/decompression still works correctly

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[danilak-G]

deferred_length is always <= 64, that's why op + deferred_length > op_limit_min_slop + kSlopBytes means that op > op_limit_min_slop which is a contradiction of if condition and while loop.

I am not convinced there is a buffer overflow. If there is, can you provide a test which fails under sanitizer or some meaningful condition fails, i.e. it touches unallocated memory?