Suggested advisory:
========================

The updated packages fix security vulnerabilities:

Heap-buffer-overflow in TIFFReadRawDataStriped() in tiffinfo.c. (CVE-2022-1354)

Stack-buffer-overflow in tiffcp.c in main(). (CVE-2022-1355)

Out-of-bounds read in LZWDecode. (CVE-2022-1622, CVE-2022-1623)

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1354
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1355
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1622
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1623
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/UXAFOP6QQRNZD3HPZ6BMCEZZOM4YIZMK/
========================

Updated packages in core/updates_testing:
========================
lib(64)tiff5-4.2.0-1.5.mga8
lib(64)tiff-devel-4.2.0-1.5.mga8
lib(64)tiff-static-devel-4.2.0-1.5.mga8
libtiff-progs-4.2.0-1.5.mga8

from SRPM:
libtiff-4.2.0-1.5.mga8.src.rpm

Status comment: Fixed upstream in 4.4.0 => (none)
Assignee: nicolas.salguero => qa-bugs
CC: (none) => nicolas.salguero
Status: NEW => ASSIGNED

mga8, x64
No proper PoC for these CVEs.  The investigation reported elsewhere for CVE-2022-162{2,3} involve recompiling tiffcp with asan support, which in principle diverges from QA's requirement to test the candidate  packages as they are.  Using tiffcp with poc1 and poc2 returns a list of complaints which match before and after the updates, which suggests that the problems might have already been fixed.

It has been noted before that a lot of packages and applications require the main library, such as okular, darktable, gwenview and scribus, presumably for TIFF specific operations.

 $ strace -o gwenview.trace gwenview MartianCrater.tif 
org.kde.kdegraphics.gwenview.lib: Unresolved raw mime type  "image/x-nikon-nrw"
org.kde.kdegraphics.gwenview.lib: Unresolved raw mime type  "image/x-samsung-srw"
Couldn't start kuiserver from org.kde.kuiserver.service: QDBusError("org.freedesktop.DBus.Error.ServiceUnknown", "The name org.kde.kuiserver was not provided by any .service files")
$ grep tiff5 gwenview.trace
openat(AT_FDCWD, "/lib64/libtiff.so.5", O_RDONLY|O_CLOEXEC) = 3okular displays the same file

Running something similar  using the tiffgt utility does not show the KDE complaints - this is the Mate desktop.
$ grep tiff tiffgt.trace
openat(AT_FDCWD, "/lib64/libtiff.so.5", O_RDONLY|O_CLOEXEC) = 3
which is only to be expected.

okular displays the same file as a PDF with a thumbnail as well and the trace shows:
openat(AT_FDCWD, "/usr/lib64/libtiff.so.5.6.0", O_RDONLY) = 22.

This looks OK for 64 bits.

CC: (none) => tarazed25

Validating. Advisory in Comment 1.

Keywords: (none) => validated_update
CC: (none) => andrewsfarm, sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2022-0240.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED