### Summary
Decompressing invalid LZ4 data can leak data from uninitialized memory, or can leak content from previous decompression operations when reusing an output buffer.

### Details
The LZ4 block format defines a "match copy operation" which duplicates previously written data or data from the user-supplied dict. The position of that data is defined by an _offset_. The data is copied within the output buffer from the _offset_ to the current output position.
However, lz4_flex did not properly detect invalid and out-of-bounds _offset_ values properly, causing it to copy uninitialized data from the output buffer.

Only the block based API functions are affected: 
`lz4_flex::block::{decompress_into, decompress_into_with_dict}`

All `frame` APIs are _not_ affected.

There are two affected use cases:
- decompressing LZ4 data with the `unsafe` implementation (`safe-decode` feature flag disabled, which is enabled by default):
can leak content of uninitialized memory as decompressed result
- decompressing LZ4 data into a reused, user-supplied `output` buffer (affects the `safe-decode` feature as well):
can leak the previous contents of the output buffer as decompressed result

### Impact
Leakage of data from uninitialized memory or content from previous decompression operations, possibly revealing sensitive information and secrets.

### Mitigation
lz4_flex 0.12.1 and 0.11.6 fixes this issue without requiring changes in user code.

If you cannot upgrade, you can mitigate this vulnerability by zeroing the output buffer before calling `block::decompress_into` or  `block::decompress_into_with_dict` (only block based API is affected, frame API is not affected). Additionally the the `safe-decode` feature flag should be enabled.