An issue was discovered in SoX 14.4.2. One of the arguments to bitrv2 in fft4g.c is not guarded, such that it can lead to write access outside of the statically declared array, aka a stack-based buffer overflow. Reference: https://sourceforge.net/p/sox/bugs/321
Created sox tracking bugs for this issue: Affects: fedora-all [bug 1678296]
``` Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7b54a8d in bitrv2 (n=1048576, ip0=0x615a68, a=0x7ffff650a010) at fft4g.c:807 807 } (gdb) bt #0 0x00007ffff7b54a8d in bitrv2 (n=1048576, ip0=0x615a68, a=0x7ffff650a010) at fft4g.c:807 ```
Eventually, below, we generate a m that is 256 when n is 1048576. ``` │709 static void bitrv2(int n, int *ip0, double *a) │ │710 { │ │711 int j, j1, k, k1, l, m, m2, ip[256]; │ │712 double xr, xi, yr, yi; │ │713 │ │714 (void)ip0; │ B+ │715 ip[0] = 0; │ │716 l = n; │ │717 m = 1; │ >│718 while ((m << 3) < l) { │ │719 l >>= 1; │ │720 for (j = 0; j < m; j++) { │ │721 ip[m + j] = ip[j] + l; │ │722 } │ B+ │723 m <<= 1; │ │724 } ``` m << 3 in this case is 2048, which is less than l, which is 4096 at this point in time. ip[m+j] starts at ip[256 + 0], which is already out of bounds. We continue writing past that, hence a classic stack buffer overflow. ``` (gdb) print ip[256] $51 = -9040 (gdb) n (gdb) print ip[256] $52 = 2048 ```
I don't believe Red Hat Enterprise Linux 6 is affected. Only the 7 build of sox seems to have the hardcoded ip[256] array. Strange.
Also, the same file has this: ```c static void bitrv2conj(int n, int *ip0, double *a) { int j, j1, k, k1, l, m, m2, ip[256]; ``` Looks like the same flaw. Unclear if it is trigger-able, but I'll let upstream know just in case. Presumably the same fix.