Per https://gitlab.com/libtiff/libtiff/commit/1b5e3b6a23827c33acf19ad50ce5ce78f12b3773 :
_TIFFCheckMalloc()/_TIFFCheckRealloc() used a unsafe way to detect overflow
in the multiplication of nmemb and elem_size (which are of type tmsize_t, thus
signed), which was especially easily triggered on 32-bit builds (with recent
enough compilers that assume that signed multiplication cannot overflow, since
this is undefined behaviour by the C standard). The original issue which lead to
this fix was trigged from tif_fax3.c
There were also unsafe (implementation defied), and broken in practice on 64bit
builds, ways of checking that a uint64 fits of a (signed) tmsize_t by doing
(uint64)(tmsize_t)uint64_var != uint64_var comparisons. Those have no known
at that time exploits, but are better to fix in a more bullet-proof way.
Or similarly use of (int64)uint64_var <= 0.
The bug has been referenced in the following commit(s):
Author: Mattias Nissler <email@example.com>
AuthorDate: 2019-09-03 10:25:18 +0000
Commit: Aaron Bauman <firstname.lastname@example.org>
CommitDate: 2019-09-03 19:45:36 +0000
media-libs/tiff: Pull in patch for CVE-2019-14973
Signed-off-by: Mattias Nissler <email@example.com>
Signed-off-by: Aaron Bauman <firstname.lastname@example.org>
....0.10-CVE-2019-14973-fix-integer-overflow.patch | 395 +++++++++++++++++++++
media-libs/tiff/tiff-4.0.10-r2.ebuild | 85 +++++
2 files changed, 480 insertions(+)
@arches, please stabilize.
What kind of runtime testing is required here?