Bug#742885: python-apt: Does not support LFS .deb packages on 32-bit systems
On Thu, Apr 03, 2014 at 02:01:08PM +0200, Julian Andres Klode wrote:
> On Fri, Mar 28, 2014 at 03:02:23PM +0100, Guillem Jover wrote:
> > Package: python-apt
> > Version: 0.9.3.4
> > Severity: normal
> > Control: block -1 by 742882
> >
> > Hi!
> >
> > python-apt also seems to have issues with LFS .deb files. Some cannot be
> > fixed until apt provides the fixed interfaces though, here's the issues
> > I've spotted by code staring, but there might be others:
>
> Short summary: While support for archives larger than 4 GiB will be added,
> there will be no support for reading members larger than 4 GiB into
> memory (the extractdata stuff) on 32 bit systems.
It should work now in git, except for items in TarFiles larger than
4 GiB, they will currently overflow and cause a crazy allocation
likely followed by a segfault.
If you have a test file for checking, it would be great if you
could check if it works correctly. I have neither the file nor
a 32-bit system.
> Similar to extractdata in ArArchive. I'll probably include the
> following fix, which simply returns None if we cannot read the
> data into memory. This will start working with the next APT
> ABI break then. It needs some adjustments for the case that
> member != NULL, though, as we need to raise an exception in
> that case (this is the extractdata() case like in ArArchive,
> so we should throw an exception for consistency).
>
> diff --git a/python/tarfile.cc b/python/tarfile.cc
> index 7f65a5c..6a1858a 100644
> --- a/python/tarfile.cc
> +++ b/python/tarfile.cc
> @@ -71,6 +71,13 @@ public:
> bool PyDirStream::DoItem(Item &Itm, int &Fd)
> {
> if (!member || strcmp(Itm.Name, member) == 0) {
> + // If the item is larger than we can read, we will not read it,
> + // but rather return None to Python.
> + if (Itm.Size > SIZE_MAX) {
> + delete[] copy;
> + copy = NULL;
> + copy_size = 0;
> + }
> // Allocate a new buffer if the old one is too small.
> if (copy == NULL || copy_size < Itm.Size) {
> delete[] copy;
This seems broken. It needs to return if Itm.Size > SIZE_MAX, otherwise
it will end up trying to allocate a new buffer.
I'll see what it needs to get tarfile fixed up.
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
Be friendly, do not top-post, and follow RFC 1855 "Netiquette".
- If you don't I might ignore you.
Reply to: