On Thu, Jun 04, 2026 at 11:04:15PM +0300, Niko Tyni wrote: > Package: perl > Version: 5.40.1-6 > Severity: important > Tags: security upstream > X-Debbugs-Cc: [email protected] > Forwarded: > https://github.com/jib/archive-tar-new/commit/f9af01426038e29d9578825a0cd3626946ab08c7 > Control: found -1 5.32.1-4 > Control: found -1 5.36.0-1 > Control: found -1 5.42.2-1 > > The following vulnerability was published[0] for Archive-Tar (bundled with > perl): > > > CVE ID: CVE-2026-9538 > Distribution: Archive-Tar > Versions: before 3.10 > > MetaCPAN: https://metacpan.org/dist/Archive-Tar > VCS Repo: https://github.com/jib/archive-tar-new > > Archive::Tar versions before 3.10 for Perl allow memory exhaustion via > attacker controlled entry size field in tar header > > Description > ----------- > Archive::Tar versions before 3.10 for Perl allow memory exhaustion via > attacker controlled entry size field in tar header. > > _read_tar() reads each entry's payload with $handle->read($$data, > $block), where $block is derived from the entry's 12-byte size field in > the tar header with no upper bound on that value. > > A crafted header declaring a multi-gigabyte size causes Perl to > allocate a scalar of that size. > > [0] https://lists.security.metacpan.org/cve-announce/msg/40396448/
The upstream issue https://github.com/jib/archive-tar-new/issues/47 indicates that the current fix is not very effective. I'm not sure what Archive::Tar should do when encountering an archive with a huge entry size. But seeking forward 512 byte blocks one at a time and outputting an error message for each block until the next entry is found does not sound quite right. I'm working on a trixie update with the other two Archive-Tar fixes (CVE-2026-42496 and CVE-2026-42497, symlink / hardlink directory traversal). But I think I'll skip this one for now, although it's already in forky and sid. Guess that needs a separate bug. -- Niko Tyni [email protected]
