Bug 1678295 (CVE-2019-8356)

Summary:	CVE-2019-8356 sox: stack-based buffer overflow in bitrv2 in fft4g.c
Product:	[Other] Security Response	Reporter:	Dhananjay Arunesh <darunesh>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	felix, hhorak, hobbes1069, jkucera
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-10-27 03:25:21 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1678296, 1680176
Bug Blocks:	1678305

Description Dhananjay Arunesh 2019-02-18 12:55:53 UTC

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

Comment 1 Dhananjay Arunesh 2019-02-18 12:56:06 UTC

Created sox tracking bugs for this issue:

Affects: fedora-all [bug 1678296]

Comment 2 Scott Gayou 2019-02-22 21:31:19 UTC

```
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
```

Comment 3 Scott Gayou 2019-02-22 21:38:01 UTC

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
```

Comment 4 Scott Gayou 2019-02-22 21:45:13 UTC

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.

Comment 5 Scott Gayou 2019-02-22 21:47:17 UTC

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.