CVE-2016-3189

What it actually does

Use-after-free condition in bzip2recover triggered when block-end metadata points before block start in a crafted bzip2 archive, resulting in memory corruption that manifests as a crash.

Why it matters to the business

Processing of untrusted compressed files in affected Python or bzip2 environments can cause abrupt application or service termination, leading to availability loss and potential operational disruption for data-handling workflows.

How an attack unfolds

An attacker prepares a specially malformed bzip2 archive containing invalid block metadata and supplies it to any process invoking the vulnerable bzip2recover logic; when the archive is processed, the use-after-free is triggered and the target crashes.

How to fix it

Upgrade python/cpython to the commit 000593c0f97ac9b75b56064a957b84a3aaa60674 or apply an equivalent patch that eliminates the use-after-free in bzip2recover handling.

How to confirm the fix worked

Verify the presence of commit 000593c0f97ac9b75b56064a957b84a3aaa60674 in the codebase; re-test with a crafted bzip2 file that previously triggered the crash and confirm the process no longer terminates unexpectedly.

Typical attack path

1. Create or obtain a bzip2 file with block-end pointers set before block start
2. Deliver the file to a target that invokes bzip2recover (e.g., via Python archive handling)
3. Trigger archive processing or recovery operation
4. Induce crash via use-after-free

How to detect it

Review application and system logs for unexpected terminations of bzip2recover or Python processes that handle .bz2 files; correlate crash reports with recent receipt of untrusted archive files.

What your security team should do

• Apply the referenced cpython commit or equivalent bzip2 patch immediately on all systems that process external bzip2 archives
• Disable or sandbox bzip2recover usage for untrusted input until patched
• Add file-type validation and size limits before invoking bzip2 recovery routines