Bug#1032082: sox: After security update, sox reports WAV file bits per sample is zero

[Helmut Grohne <helmut@subdivi.de>]

Control: tags -1 + confirmed

Hi,

On Sat, Mar 11, 2023 at 05:31:37PM +0100, Salvatore Bonaccorso wrote:
> > We encounter an error that occurs after upgrading to 14.4.2+git20190427-2+deb11u1,
> > and disappears when downgrading to version 14.4.2+git20190427-2.
> > Both sox and soxi report an error for wave files with GSM codec,
> > that were created using libsndfile.
> > 
> > $ soxi test.wav
> > soxi FAIL formats: can't open input file `test.wav': WAV file bits per sample is zero
> > 
> > After the error, it does not futher process the file.
> > Previously, it would output information about the file or process it (convert it).
> > 
> > The bits per sample in the wave file header is indeed zero.
> > The number of bits per sample is dynamic for the GSM codec.
> > Previously sox and soxi would parse and handle such files without problems.

Thanks for the report.

> Can you confirm, does that happens as well with the unstable version
> (where the patches should be identical)?

I see no reason why this issue should be specific to a particular
release.

> Is there a minimal testcase available allowed to share on the bug or a
> way to construct one?

The clues provided are already good. For compressed codecs such as GSM,
there is no reasonable wBitsPerSample value, which is why it is set to
0. When I wrote the patch, I did not see this use case nor did any test
case expose it. The actual zero-division happens in a branch specific to
uncompressed formats and this is where the check really belongs
(src/wav.c:961 in unstable). I'll update unstable by Monday.

$ sox -t raw -r 44100 -e signed-integer -b 8 /dev/null -t wav -e gsm-full-rate bug.wav
$ sox bug.wav fail.wav
sox FAIL formats: can't open input file `bug.wav': WAV file bits per sample is zero
$

Helmut