If you create tar files using GNU Tar with --sparse and a file shrinks
while GNU Tar is reading it and writing it out, tar can loop endlessly
(writing a stream of 0s). GNU Tar will only break out of this endless
loop if the file grows again to or beyond its original end of file.
The specific code problem is that sparse_dump_region() in src/sparse.c
doesn't check for end of file as one of the return results from
safe_read(); it only checks for 'bytes_read == SAFE_READ_ERROR'. Because
sparse_dump_region() is used even on non-sparse files when you use
--sparse, this bug can happen with both sparse and non-sparse files.
I'm not sure what the best fix for this is.
The easiest reproduction for this is under GDB (or the debugger of
your choice), backing up a directory with only a single non-sparse file
in it. Set a breakpoint on sparse_dump_region(), start creating a tar
file with --sparse, and after the breakpoint triggers, use truncate(1)
to shorten the file. sparse_dump_region() will now loop endlessly.
If you re-enlarge the file, sparse_dump_region() will recover.
(Reproduction without GDB requires a way to slow tar down enough that
you can truncate the file after it starts writing it but before it
finishes.)
This bug has happened in our usage of Amanda with GNU tar, when backing
up mailbox files. It has been present in a number of GNU Tar versions
and (from code inspection) is still in git head.
So you know and are not caught by surprise, this has been reported (by
someone else) as CVE-2018-20482 (on the grounds that it is a denial of
service possibility), based on my initial blog post. See:
https://nvd.nist.gov/vuln/detail/CVE-2018-20482
- cks
