On 5/30/24 15:48, Måns Rullgård wrote:
Martin Guy <martinw...@gmail.com> writes:-------- Forwarded Message -------- Subject: CVE-2019-8354 claims to have been fixed in SoX, but isn't Date: Thu, 30 May 2024 12:49:17 +0200 From: Martin Guy <martinw...@gmail.com> To: n...@nist.gov https://nvd.nist.gov/vuln/detail/CVE-2019-8354 claims to have been fixed on Apr 24 14:57:34 2019 +0100 in the SoX commit logs: fix possible buffer size overflow in lsx_make_lpf() (CVE-2019-8354) The multiplication in the size argument malloc() might overflow, resulting in a small buffer being allocated. Use calloc() instead. but the segmentation fault (core dumped) persists both immediately after this commit and in all subsequent versions:
This crash has nothing to do with the multiplication overflow described
> in the CVE. Still it's a bug, so I've fixed it. Thanks but-static void dft_stage_init( +static int dft_stage_init( unsigned instance, double Fp, double Fs, double Fn, double att, double phase, stage_t * stage, int L, int M) { @@ -229,6 +229,12 @@ static void dft_stage_init( else f->post_peak = num_taps / 2; dft_length = lsx_set_dft_length(num_taps); + + if (L > dft_length) { + lsx_fail("invalid DFT parameters"); + return SOX_EINVAL; + } + f->coefs = calloc(dft_length, sizeof(*f->coefs)); for (i = 0; i < num_taps; ++i) f->coefs[(i + dft_length - num_taps + 1) & (dft_length - 1)]
What if argument L, an int, whose value in the test case is 1,073,741,824, overflows and goes negative?
Remember, we are talking about deliberately and maliciously-crafted audio files (the test piece has a sample rate of 3.28294e-06 and, though only 328 samples long, has a duration of 3 years and 2 months). I'd rather it were fixed against this eventuality than have to force the issue by trying to invent an audio file that causes this behavior. I have more time-consuming things to do, like verifying manually that all of the 25 CVEs open against SoX since the last release really were fixed, as I can no longer trust the commit logs; you evidently never tested this "fix" because the exact same SEGV happens in the same place before and after the 2019 commit tagged "CVE-2019-8354".
M
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel
