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. Regards, Salvatore
