Limit metadata block size when reading TAR archives

[iremyux]

Limits the maximum allowed size of PAX extended attribute blocks and GNU LongPath/LongLink data sections to 1 MB when reading TAR archives by introducing a MaxMetadataBlockSize constant (1 MB).

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-formats-tar
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR tightens TAR archive parsing by limiting the maximum size of metadata data sections (PAX extended attributes and GNU LongPath/LongLink payloads) to 1 MB, reducing risk of excessive allocations/DoS when reading malformed archives.

Changes:

• Introduced a MaxMetadataBlockSize constant (1 MB) on TarHeader.
• Updated the metadata ValidateSize() check to enforce the new maximum when reading PAX/GNU metadata blocks.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarHeader.Read.cs	Enforces the new 1 MB maximum via ValidateSize() before renting/reading metadata buffers.
src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarHeader.cs	Adds the MaxMetadataBlockSize constant used by the reader.

[rzikm]

LGTM in principle, are we sure 1MB is large enough to not break legitimate uses?

[iremyux]

@rzikm , I believe 1 MB is generous in this case, legitimate metada blocks are typically in the low KB range.
PAX extended attributes store values like path, linkpath, uid etc. There is the Linux's PATH_MAX = 4906 bytes limit, which is long away from 1MB.
GNU LongPath/LogLink stores a path string, I am not sure if path names anywhere near 1MB is supported.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (1)

src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarHeader.Read.cs:730

• Read-side validation of malformed archives elsewhere in this file generally uses InvalidDataException, but this path throws InvalidOperationException. Since this is triggered by archive contents (oversized metadata blocks), consider throwing InvalidDataException here as well for consistency and clearer signaling to callers.

            if ((uint)_size > (uint)MaxMetadataBlockSize)
            {
                ThrowSizeFieldTooLarge();
            }

            [DoesNotReturn]
            void ThrowSizeFieldTooLarge() =>
                throw new InvalidOperationException(SR.Format(SR.TarSizeFieldTooLargeForEntryType, _typeFlag.ToString()));
        }

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarHeader.Read.cs:729

• The exception thrown from ValidateSize uses TarSizeFieldTooLargeForEntryType ("greater than the expected length"), but with the new 1 MB cap this will now be hit for relatively small inputs and the message doesn’t indicate the limit or actual size. Consider using a dedicated SR that includes the max allowed metadata size (and ideally the offending size) so failures are actionable when diagnosing malformed/hostile archives.

            if ((ulong)_size > (ulong)MaxMetadataBlockSize)
            {
                ThrowSizeFieldTooLarge();
            }

            [DoesNotReturn]
            void ThrowSizeFieldTooLarge() =>
                throw new InvalidOperationException(SR.Format(SR.TarSizeFieldTooLargeForEntryType, _typeFlag.ToString()));

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 6 comments.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.