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>