Repository navigation
TarReader rejects GNU sparse 1.0 entries whose sparse map exceeds 1 KiB #134980
Description
Description
TarReader rejects valid GNU sparse format 1.0 (PAX) entries whose embedded sparse map is longer than about 1 KiB. Reading the entry's DataStream, or extracting it with TarFile.ExtractToDirectory, throws InvalidDataException: The TAR archive is corrupted or invalid.. GNU tar writes such maps for any moderately fragmented sparse file: a file with 76 data regions already produces a 1062-byte map.
Reproduction Steps
using System;
using System.Formats.Tar;
using System.IO;
// Both archives were written by tar (--format=pax --sparse --sparse-version=1.0).
foreach (string path in new[] { "sparse72.tar", "sparse76.tar" })
{
string dir = Directory.CreateTempSubdirectory().FullName;
try
{
TarFile.ExtractToDirectory(path, dir, overwriteFiles: true);
Console.WriteLine($"{path}: OK");
}
catch (Exception ex)
{
Console.WriteLine($"{path}: {ex}");
}
finally
{
Directory.Delete(dir, recursive: true);
}
}Expected behavior
Both archives are read and extracted without issues.
Actual behavior
InvalidDataException is thrown on a sparse file whose embedded sparse map is longer than about 1 KiB
Regression?
No. GNU sparse 1.0 reading is new in .NET 11
Known Workarounds
None
Configuration
.NET 11.0.0-rc.1.26425.128, linux-x64
Other information
- Other implementations read both archives correctly: GNU tar, Python
tarfile - The GNU sparse 1.0 format specification does not limit the sparse map size: https://www.gnu.org/software/tar/manual/html_node/PAX-1.html
- The exception is thrown from
GnuSparseStream.ParseSparseMapCoreAsync/ReadLineAsync. - Observed threshold: a 1006-byte sparse map (73 entries) works; a 1062-byte map (77 entries) fails.
Activity
dotnet-policy-service commentedon Sep 30, 2026
Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.
dotnet-policy-service commentedon Oct 12, 2026
Tagging subscribers to this area: @dotnet/area-system-formats-tar
See info in area-owners.md if you want to be subscribed.
rzikm commentedon Oct 12, 2026
we added some hard cap as a sort of DoS protection (loading the sparse table results in attacker-controlled allocation), I think we can make the cap a bit bigger
rzikm commentedon Oct 12, 2026
@jeffhandley is there a specific reason why you assigned this to 11.0.0 milestone? is it critical to fix there?
Fix GNU sparse 1.0 maps spanning multiple TAR records (#135626)