[LZ4_compress_destSize] Fix rare data corruption bug #756
Conversation
| @@ -1038,6 +1066,8 @@ LZ4_FORCE_INLINE int LZ4_compress_generic( | |||
| } else | |||
| *token += (BYTE)(matchCode); | |||
| } | |||
| /* Ensure we have enough space for the last literals. */ | |||
| assert(!(outputDirective == fillOutput && op + 1 + LASTLITERALS > olimit)); | |||
There was a problem hiding this comment.
This assert isn't quite correct (or is exposing a bug) so I'll look into it.
There was a problem hiding this comment.
I believe it is triggered because the condition on line 1030 isn't quite right. As I understand it matchCode>>8 has an off by one error in the division. Also, we could need one extra zero byte.
I think we need something like (matchCode+240)/255.
There was a problem hiding this comment.
This assert was failing when matchCode == 7665. matchCode >> 8 == 29, but it actually needs 31 bytes since (matchCode + 240) / 255 == 31 (the extra byte is needed because 7665 - 15 is a multiple of 255).
Cyan4973
changed the title
|
Looks good to me ! |
terrelln
changed the title
When we had to shorten the match to fit in the output buffer, and the new match is before the
ipwhere we found the match because of the "catch up" there will be positions in the table that are beyond the newip. We must zero those positions so we don't corrupt the hash table.Credit to OSS-Fuzz