CVE-2020-27350: tarfile: integer overflow: Limit tar items to 128 GiB

The integer overflow was detected by DonKult who added a check like this:

(std::numeric_limits<decltype(Itm.Size)>::max() - (2 * sizeof(Block)))

Which deals with the code as is, but also still is a fairly big limit,
and could become fragile if we change the code. Let's limit our file
sizes to 128 GiB, which should be sufficient for everyone.

Original comment by DonKult:

The code assumes that it can add sizeof(Block)-1 to the size of the item
later on, but if we are close to a 64bit overflow this is not possible.
Fixing this seems too complex compared to just ensuring there is enough
room left given that we will have a lot more problems the moment we will
be acting on files that large as if the item is that large, the (valid)
tar including it probably doesn't fit in 64bit either.

1 files changed, 3 insertions, 0 deletions

diff --git a/test/integration/test-cve-2020-27350 b/test/integration/test-cve-2020-27350
index f4bb79bcb..a32bf95e5 100755
--- a/test/integration/test-cve-2020-27350
+++ b/test/integration/test-cve-2020-27350
@@ -20,3 +20,6 @@ testequal "E: Long name to large: 67108865 bytes > 1048576 bytes" runapt ${APTTE
 
 ${APTTESTHELPERSBINDIR}/createdeb-cve-2020-27350 long-control long-control.deb
 testequal "E: Control file too large: 67108865 > 67108864 bytes" runapt ${APTTESTHELPERSBINDIR}/extract-control long-control.deb control
+
+${APTTESTHELPERSBINDIR}/createdeb-cve-2020-27350 too-long-control too-long-control.deb
+testequal "E: Tar member too large: $((128 * 1024 * 1024 * 1024 + 1)) > $((128 * 1024 * 1024 * 1024)) bytes" runapt ${APTTESTHELPERSBINDIR}/extract-control too-long-control.deb control