CVE-2021-33844

What it actually does

A divide-by-zero floating point exception in startread() of wav.c triggers an application crash when processing a specially crafted WAV file.

Why it matters to the business

Local users or automated media-processing workflows can be disrupted by denial-of-service crashes when handling untrusted audio files; the absence of listed fixes increases exposure for organizations still running older SoX versions.

How an attack unfolds

An attacker prepares a malformed WAV file that triggers the divide-by-zero in the WAV reader, then causes the victim to invoke SoX on that file locally, resulting in an immediate crash with no further code execution.

How to fix it

Upgrade SoX to a version that eliminates the divide-by-zero condition in wav.c; until a fixed release is available, avoid processing untrusted WAV files with SoX and consider alternative audio tools for untrusted input.

How to confirm the fix worked

Test that SoX no longer crashes when invoked against a WAV file containing the previously problematic header values; monitor process exit status and logs for floating-point exceptions during WAV handling.

Typical attack path

1. Craft a WAV file containing values that cause division by zero in startread().
2. Deliver the file to the target via email, download, or shared storage.
3. Trick or automate the target into running SoX against the file (e.g., sox malicious.wav).
4. Observe application termination due to the unhandled floating-point exception.

How to detect it

Review application and system logs for SoX processes that terminate abnormally when handling WAV files; correlate file-access events with subsequent crashes or floating-point exception signals.

What your security team should do

• Block or sandbox SoX execution against files from untrusted sources until patched.
• Inventory all systems using the sox package and schedule upgrades as soon as fixed builds are released.
• Add SoX crash signatures to endpoint monitoring to detect attempted exploitation.