Bugzilla – Bug 1219219
VUL-0: CVE-2023-52355: tiff: libtiff: TIFFRasterScanlineSize64 produce too-big size and could cause OOM
Last modified: 2024-02-27 08:59:01 UTC
An out-of-memory flaw was found in libtiff that could be triggered by passing a crafted tiff file to the TIFFRasterScanlineSize64() API. This flaw allows a remote attacker to cause a denial of service via a crafted input with a size smaller than 379 KB. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-52355 https://access.redhat.com/security/cve/CVE-2023-52355 https://bugzilla.redhat.com/show_bug.cgi?id=2251326 https://gitlab.com/libtiff/libtiff/-/issues/621 https://www.cve.org/CVERecord?id=CVE-2023-52355
I would not go and backport this memory management framework currently. We could: - ignore the problem and ask people to fix it with ulimits - hardcode limits in the code, like 64k pixels width maximum or so.
(In reply to Marcus Meissner from comment #5) > I would not go and backport this memory management framework currently. > > We could: > > - ignore the problem and ask people to fix it with ulimits I would tend to this option since the problem is only for developers who use the library, and we don't know what size of tiff files our customers might want to work with (if anybody even writes their own applications using tiff) or how much memory they have available. @Stoyan what would be the next steps in this case?
I am closing it as won't fix. In case of questions we could provide the mitigation to use ulimits.