summaryrefslogtreecommitdiff
path: root/cmdline/apt-internal-planner.cc
diff options
context:
space:
mode:
authorJulian Andres Klode <julian.klode@canonical.com>2020-12-05 19:55:30 +0100
committerJulian Andres Klode <julian.klode@canonical.com>2020-12-07 12:29:57 +0100
commit0e3b54db6d7ec7c7baf151c812b77042927cf44e (patch)
tree5c23e175311c76eb8f8ac2bae7c1e451d571adb2 /cmdline/apt-internal-planner.cc
parented786183bfe9813cf9bc603de0a2beed3e0d0e31 (diff)
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.
Diffstat (limited to 'cmdline/apt-internal-planner.cc')
0 files changed, 0 insertions, 0 deletions