Skip to content

Fix GNU sparse 1.0 maps spanning multiple TAR records - #135626

Open
rzikm wants to merge 1 commit into
mainfrom
rzikm/gnu-sparse-map-parsing
Open

rzikm wants to merge 1 commit into
mainfrom
rzikm/gnu-sparse-map-parsing

Conversation

@rzikm

@rzikm rzikm commented Oct 12, 2026

Copy link
Copy Markdown
Member

Valid GNU sparse 1.0 PAX entries can throw InvalidDataException when their embedded sparse map exceeds approximately 1 KiB. The refill-capacity check includes already-consumed bytes that the next refill would discard during compaction.

Calculate capacity using only unread bytes. This preserves the fixed 1 KiB buffer, the 1,000,000-segment allocation limit, numeric-line bounds, and record-aligned packed-data positioning.

Regression coverage checks exact record boundaries, the reported 1,006-byte and 1,062-byte map sizes, and an 8,193-byte map. It covers sync/async reads and extraction, copied/non-copied data, non-seekable inputs, next-entry alignment, and malformed maps.

Validation

Commands ran through a short subst path on Windows x64:

  • .\build.cmd clr+libs -rc Release - passed.
  • .\dotnet.cmd build src\libraries\System.Formats.Tar\src\System.Formats.Tar.csproj - passed for the Windows and Unix target assemblies.
  • .\dotnet.cmd build /t:test src\libraries\System.Formats.Tar\tests\System.Formats.Tar.Tests.csproj '/p:XUnitOptions=-class System.Formats.Tar.Tests.TarReader_SparseFileTests' - 159 cases executed; 32 valid-map cases failed before the fix, and all 159 passed afterward.
  • .\dotnet.cmd build /t:test src\libraries\System.Formats.Tar\tests\System.Formats.Tar.Tests.csproj - all 7,084 standard tests passed, with zero skips.

Both original issue archives passed sync/async reading and directory extraction after the fix, with expanded lengths and SHA-256 hashes matching Python tarfile. Non-Windows test execution and the multi-gigabyte manual stress project were not run.

Fixes: #134980

Resolves #134980

Note

This description was generated by GitHub Copilot.

Check refill capacity after excluding consumed bytes so valid GNU sparse 1.0 maps can span multiple TAR records. Preserve the existing buffer and segment-count limits, and cover boundary-sized maps, extraction, archive advancement, and malformed inputs.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 9b3e8fbb-f56a-48da-9df9-8c67a81584d0
@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

@dotnet-policy-service

Copy link
Copy Markdown
Contributor

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

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

TarReader rejects GNU sparse 1.0 entries whose sparse map exceeds 1 KiB

2 participants