Skip to content

Reject phar entries and archives beyond the 32-bit format limits - #25197

Open
lazerg wants to merge 2 commits into
php:masterfrom
lazerg:fix/gh-25053-phar-format-limits
Open

lazerg wants to merge 2 commits into
php:masterfrom
lazerg:fix/gh-25053-phar-format-limits

Conversation

@lazerg

@lazerg lazerg commented Nov 5, 2026

Copy link
Copy Markdown
Contributor

Follow-up to #25054, split out so the PHP-8.4 fix stays small. Phar keeps sizes and offsets in 32-bit fields, and a few writers narrowed larger values without a check:

  • Phar::mount() stored a file of 4 GiB or more with a truncated size, so reads returned only the low 32 bits worth of data.
  • The tar writer accepted entries the tar reader rejects (sizes above UINT32_MAX - 511, since GHSA-j3wh-g957-2m85), so the archive could not be opened again.
  • The zip writer cast the central directory offset and size to 32 bits. Without zip64, an archive past 4 GiB was written with a wrapped offset and reported as corrupted on reopen.
  • Compressing an entry whose compressed size passes 4 GiB stored the narrowed size, in both phar and zip.

These now fail (mount fails, flush throws a PharException) instead of writing an archive that can't be read back. The tests need 4 GiB temp files, so they only run with RUN_RESOURCE_HEAVY_TESTS.

Refs #25053

Phar::mount() truncated the size of files of 4 GiB or more. The tar
writer accepted sizes the tar reader rejects, the zip writer wrapped the
central directory offset and size, and compressed sizes above 4 GiB were
narrowed. These now fail instead of writing archives that can't be read
back.

Follow-up to phpGH-25053.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant