tarfile: Skip DIRTYPE normalization during GNU LONGNAME/LONGLINK handling
The "tarfile" module would still apply normalization of AREGTYPE (\x00) blocks to DIRTYPE, even while processing a multi-block member such as GNUTYPE_LONGNAME or GNUTYPE_LONGLINK. This could result in a crafted tar archive being misinterpreted by the tarfile module compared to other implementations.
02 / AFFECTED SOFTWARE
Affected packages
231 explicit affected versions
237 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
The "tarfile" module would still apply normalization of AREGTYPE (\x00) blocks to DIRTYPE, even while processing a multi-block member such as GNUTYPE_LONGNAME or GNUTYPE_LONGLINK. This could result in a crafted tar archive being misinterpreted by the tarfile module compared to other implementations.
The "tarfile" module would still apply normalization of AREGTYPE (\x00) blocks to DIRTYPE, even while processing a multi-block member such as GNUTYPE_LONGNAME or GNUTYPE_LONGLINK. This could result in a crafted tar archive being misinterpreted by the tarfile module compared to other implementations.
The "tarfile" module would still apply normalization of AREGTYPE (\x00) blocks to DIRTYPE, even while processing a multi-block member such as GNUTYPE_LONGNAME or GNUTYPE_LONGLINK. This could result in a crafted tar archive being misinterpreted by the tarfile module compared to other implementations.
The "tarfile" module would still apply normalization of AREGTYPE (\x00) blocks to DIRTYPE, even while processing a multi-block member such as GNUTYPE_LONGNAME or GNUTYPE_LONGLINK. This could result in a crafted tar archive being misinterpreted by the tarfile module compared to other implementations.
The "tarfile" module would still apply normalization of AREGTYPE (\x00) blocks to DIRTYPE, even while processing a multi-block member such as GNUTYPE_LONGNAME or GNUTYPE_LONGLINK. This could result in a crafted tar archive being misinterpreted by the tarfile module compared to other implementations.
05 / REFERENCES
Further evidence
- https://github.com/python/cpython/commit/42d754e34c06e57ad6b8e7f92f32af679912d8ab
- https://github.com/python/cpython/commit/72dde1016493c52abe857fc4a7bf6c40138b4114
- https://github.com/python/cpython/commit/7ad3093d76a748af55bdb1d2e8aad3638163b017
- https://github.com/python/cpython/commit/9a23b753552afa28e3a2f4d8863572fc66479406
- https://github.com/python/cpython/commit/ae99fe3a33b43e303a05f012815cef60b611a9c7
- https://github.com/python/cpython/commit/d10950739a78f54d0718d88fb5a868374603c084
- https://github.com/python/cpython/issues/141707
- https://github.com/python/cpython/pull/143934
- https://mail.python.org/archives/list/[email protected]/thread/EOMI5I66ZMKQ2INNFT6T7IAIKUGPZYIE/
- https://nvd.nist.gov/vuln/detail/CVE-2025-13462
- https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/13xxx/CVE-2025-13462.json
- https://github.com/python/cpython