Hi Carlos, On Sun, May 25, 2025 at 05:03:59PM +0200, Salvatore Bonaccorso wrote: > Hi, > > On Sun, May 25, 2025 at 07:24:00AM +0200, Salvatore Bonaccorso wrote: > > On Sat, May 24, 2025 at 12:20:00AM -0300, Carlos Henrique Lima Melara wrote: > > > Hi Salvatore and Boyuan, > > > > > > I saw libavif is marked in dsa-needed and Salvatore is working on it. > > > I'm also working on it (started today) as part of (E)LTS work sponsored > > > by Freexian and would like to offer help here. > > > > > > The upload to unstable was on 17th and there wasn't a DSA so far, so I'm > > > assuming other stuff got in the way and/or it's not an easy backport. > > > I'll work more on it tomorrow but I'd like to provide what I've > > > accomplished so far in case any of you wants to start before me > > > (timezone differences are hard!). > > > > > > CVE-2025-48174 was easier to fix, though the proper apparatus to handle > > > AVIF_RESULT_INVALID_ARGUMENT was introduced later and is a big change, > > > so I've decided to not backport and just exit on overflow. > > > > > > CVE-2025-48175 is a bit more tricky because the code is different. > > > [1b4ce5ca24a] introduces the local variables to make the code easier to > > > read and the CVE was identified on them. Changing some of them to size_t > > > is the fix so multiplication is conduced in size_t. On bookworm, the > > > variable used for calculations in also uint32_t, but it encapsulated on > > > avifRGBImage which is a public exposed struct. So changing it can break > > > the ABI and I assume is a no go for a stable update. This is the point > > > where I stopped today (need to sleep now!). I was thinking about either > > > cherry-picking [1b4ce5ca24a] or trying to cast the size_t in the > > > multiplication to avoid the overflow. Will think harder about it > > > tomorrow. > > > > > > Anyway, I'll send what I have now in the hope it can be helpfull to you. > > > > Charles, thanks for the offer. I'm indeed on it and I'm in contact > > with upstream to see if we can get vetted/blessed patches for the > > older version in bookworm. We should try hard to avoid breakage. > > We have now wetted/blessed upstream changes, and I'm going to pick > those. They are referenced as well in the upstream issues as repsonse > to your questions as well so we should be ready to go (unless we spot > some problems while testing).
Attached are the patches we aim to use for bookworm. The first one, is very similar to your backported one, but it uses abort() instead of exit(1), as upstream suggested to be consistent with avifAlloc(). I put an explanation in the patch. The second was handled after all in public as you asked there as well, so it is identical to what Wan-Teh Chang posted on the issue. Hope this helps. Regards, Salvatore
From: DanisJiang <43723722+danisji...@users.noreply.github.com> Subject: Add integer overflow checks to makeRoom (CVE-2025-48174) Origin: backport, https://github.com/AOMediaCodec/libavif/commit/e5fdefe7d1776e6c4cf1703c163a8c053559902, https://github.com/AOMediaCodec/libavif/commit/50a743062938a3828581d725facc9c2b92a1d109, https://github.com/AOMediaCodec/libavif/commit/c9f1bea437f21cb78f9919c332922a3b0ba65e11 Bug: https://github.com/AOMediaCodec/libavif/pull/2768 Bug-Debian: https://bugs.debian.org/1105885 Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2025-48174 Instead of backporting requsites for the patches from https://github.com/AOMediaCodec/libavif/pull/2768 make the overflow check and abort() instead. Use abort() to be consistent with avifAlloc() in libavif v0.11.1 (in src/mem.c): void * avifAlloc(size_t size) { void * out = malloc(size); if (out == NULL) { abort(); } return out; } Include <stdlib.h> for abort(). Thanks: Wan-Teh Chang <w...@google.com> --- src/stream.c | 3 +++ 1 file changed, 3 insertions(+) --- a/src/stream.c +++ b/src/stream.c @@ -6,6 +6,7 @@ #include <assert.h> #include <inttypes.h> #include <stdint.h> +#include <stdlib.h> #include <string.h> // --------------------------------------------------------------------------- @@ -234,6 +235,9 @@ avifBool avifROStreamReadAndEnforceVersi #define AVIF_STREAM_BUFFER_INCREMENT (1024 * 1024) static void makeRoom(avifRWStream * stream, size_t size) { + if (size > SIZE_MAX - stream->offset) { + abort(); + } size_t neededSize = stream->offset + size; size_t newSize = stream->raw->size; while (newSize < neededSize) { -- 2.49.0
From: Wan-Teh Chang <w...@google.com> Subject: Avoid integer overflow in (32-bit) int or unsigned int arithmetic operations Origin: https://github.com/AOMediaCodec/libavif/pull/2769#issuecomment-2907860473 Bug: https://github.com/AOMediaCodec/libavif/pull/2769 Bug-Debian: https://bugs.debian.org/1105883 Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2025-48175 The idea of this patch is to assume the existence of integer overflow in the code in avifImageRGBToYUV() and only enter the function when the image width and height are not too big. We have a similar protection in avifDecoder. Since avifImageRGBToYUV() is typically used to prepare the input to avifEncoder, I didn't add this protection to avifImageRGBToYUV(). 2ded15b09 has some context for the image size (area) and dimension limits. For this avifImageRGBToYUV() issue, the image size (area) limit is sufficient. The image dimension limit is intended to avoid spending a very long time decoding an image. Link: https://github.com/AOMediaCodec/libavif/pull/2769#issuecomment-2907860473 --- src/reformat.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/reformat.c b/src/reformat.c index 951c46b56ffb..9f760396da5a 100644 --- a/src/reformat.c +++ b/src/reformat.c @@ -196,6 +196,11 @@ static int avifReformatStateUVToUNorm(avifReformatState * state, float v) avifResult avifImageRGBToYUV(avifImage * image, const avifRGBImage * rgb) { + // Avoid integer overflow in (32-bit) int or unsigned int arithmetic operations. + if ((uint64_t)rgb->width * rgb->height > AVIF_DEFAULT_IMAGE_SIZE_LIMIT) { + return AVIF_RESULT_REFORMAT_FAILED; + } + if (!rgb->pixels || rgb->format == AVIF_RGB_FORMAT_RGB_565) { return AVIF_RESULT_REFORMAT_FAILED; } -- 2.49.0
