tree 85b912211515a12c6a8d42d7bd8f3c336ead335a
parent aa32042a50f2cbe0ff9d339948cb4712f5cc3d6e
author Felicia Lim <flim@google.com> 1469712079 +0200
committer Jean-Marc Valin <jmvalin@jmvalin.ca> 1484945054 -0500
gpgsig -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iQIcBAABCAAGBQJYgncdAAoJEF5d2aNvkYnIVGkP/1Cv9tPiOvCMgW6Xcbjhoc4U
 0uVKjSSmGqUuE/Z5MbTH4Ztrwr3xfeSOW/pjGBd/lVp0dkO0MJCtiCFY/bagyvoR
 KPx6a8Um7ZsvQH9gZWoytGvUND3vIfNOwvISe+nEGMpuM8vjnnAhakPil50jiUAE
 HvYTEMUZUHBRcoKAmnQ8uOKdbTAKRxyDGIMcNhSi23Slxsm4EZ1yfEbyrsWfheGc
 W6uYAh/5VAd25vx54L4Uuxq37nm4ndnrakckW2j0BRmsBBSRv+K92zHdsOaWNrC6
 OGC1+ekVZ1DnD1ExiUdnMHCCnfo7hNvXIzQJsxdvP9dKaxwzbKwjmV0hHNe69hpQ
 JX6zSKfU7U8kiJPL6PGfcLdqZZvvEr5ox+0pg2d2OIu5Fp46ntUuKD28KuE7Z5+F
 IiKYBUHXfJASFoCcH3jibB2I7sBXX5Xkb1pGMiD3rdSRGRlt/7PQXsBZA5ZGS538
 y3CtLGMW7tkivv95gkpNZ9yGxcO1bp9ddHhQ6xREoFhcmBJpt67AhvFrD9z6f0j/
 4qDHv5nYnzkF6XZgtTT/q3GOSeJYrqfxE4sOoX4bVJ8bMVJHRVXaymAfnQJn1qtw
 TGkn1yeJ5Sbf0trcsWhoYTlJpupCq9nv1lFwdipDjU5CenLhj36JbXicgPAMRh/b
 CWHePvOt/o6lzVNIysPf
 =Heh3
 -----END PGP SIGNATURE-----

Ensure that NLSF cannot be negative when computing a min distance between them

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>