Bound nested metadata counts and coder properties by their backing data, validate file and stream consistency, and buffer decoded headers incrementally instead of reserving attacker-declared output sizes.
Add synchronous and asynchronous allocation regressions for GHSA-vwpg-q8vc-g6fg, including external metadata and valid bit-packed empty entries.
Combine the decoder and padding size bounds from advisory PR #1 with the checked seek offsets and sync/async regression coverage in PR #2.
Co-authored-by: 4nonym0us <2701409+4nonym0us@users.noreply.github.com>
string.StartsWith(char) is not available on netstandard2.0 or net48,
so those targets failed to compile after 990186ac.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
TarHeader searched for the split point between the prefix and name
fields using Path.DirectorySeparatorChar, but TarWriter has already
normalized the name to use '/'. On Windows Path.DirectorySeparatorChar
is '\', so no separator was ever found and every name longer than 100
bytes threw InvalidFormatException ("Directory separator not found!"),
even though it could be stored using the prefix field. Linux and macOS
were not affected.
Search for '/' instead, in both WriteUstar and WriteUstarAsync. The
tests added in the previous commit now pass on Windows too.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
When an entry name is longer than the 100 byte USTAR name field,
TarHeader splits it into the 155 byte prefix field and the name field
at a directory separator. The existing tests only covered short paths
and long names without any separator.
Add sync and async tests that write a 186 byte path (with '/' and
'\' separators as input) using the USTAR format and read it back.
On Windows these tests fail with InvalidFormatException ("Directory
separator not found!"), which the next commit fixes. They pass on
Linux and macOS.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
An LZMA2 chunk header properties byte of 225 or more cannot occur in
valid data, but it reached Decoder.SetDecoderProperties and surfaced as
InvalidParamException. EncryptedDecoderStream only maps DataErrorException
to CryptographicException, so a wrong 7z password occasionally leaked the
internal codec exception, making
SevenZipWriter_Encrypted_WrongPasswordFails flaky.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>