Martin Guy <martinw...@gmail.com> writes: > 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".
I am somewhat weary of your entitled attitude. You don't have to do anything whatsoever. The CVE addresses the possibility of a memory allocation being smaller than expected. The result of subsequent out of bounds accesses are impossible to predict, which qualifies the bug as a vulnerability. After the fix, it aborts without doing any harm. This is not exploitable. Now get off your high horse. -- Måns Rullgård _______________________________________________ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel
