-
Without the fix, very large NLSF values could cause the stabilization code in silk/NLSF_stabilize.c to wrap-around and have the last value in NLSF_Q15[] to be negative, close to -32768. That value would then be used in silk_NLSF2A() to compute f_int, which would be equal to -128. Since f_int is used to look up into constant table silk_LSFCosTab_FIX_Q12[], it would cause two 16-bit reads, 256 bytes and 254 bytes before the constant table. In nornal circumstances the code will simply read from the wrong table, resulting in an unstable LPC filter. The filter would then go through the LPC stabilization code at the end of silk_NLSF2A(). Ultimately the output audio would be garbage, but no worse than with any other harmless bad packet. For this bug to cause a crash, the linker would have to put the relevant at the very beginning of the segment, with unaddressable memory just before it. Alternatively, if the code is compiled with assertions enable, then it will abort. The only way this could cause a data leak would be for the linker to put the silk_LSFCosTab_FIX_Q12[] within 256 bytes after sensitive process information, which is highly unlikely. Even in that circumstance, only 32 bits of data could be read, at location outside of the attacker's control. The output would be in the form of audio that would have to be mapped back to the original 32-bit data. This was reported as CVE-2017-0381. Contrary to that report, we do not believe that any remote code execution is possible. Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>