[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: security update for libpng1.6



Hi Tobias,

On Sun, Nov 30, 2025 at 06:44:41PM +0100, Tobias Frost wrote:
> On Fri, Nov 28, 2025 at 02:22:18PM +0100, Salvatore Bonaccorso wrote:
> > Hi Tobias,
> >
> > On Tue, Nov 25, 2025 at 09:15:21PM +0100, Tobias Frost wrote:
> > > Hi Salvatore,
> > >
> > > attached is the libpng debdiff for trixie.
> > > The diff is also available on salsa: https://salsa.debian.org/debian/libpng1.6/-/compare/debian%2F1.6.48-1...debian%2Ftrixie?from_project_id=26504
> >
> > Thanks for attaching the debdiff.
> >
> > > Salsa-CI is currently busy rebuilding all r-deps, I'll
> > > check the results tomorrow (there will be builds running into timeouts,
> > > I'll compile those locally as well.)
> > >
> > > (I'll also start working on bookworm asap, but didn't want to delay
> > > sharing the trixie debdiff)
> >
> > Ok, please come back to us as well once you have it. We should release
> > both updates at the same time for trixie-security and
> > bookworm-security.
> >
> >
> > > diff -Nru libpng1.6-1.6.48/debian/changelog libpng1.6-1.6.48/debian/changelog
> > > --- libpng1.6-1.6.48/debian/changelog	2025-05-05 21:11:18.000000000 +0200
> > > +++ libpng1.6-1.6.48/debian/changelog	2025-11-23 18:21:02.000000000 +0100
> > > @@ -1,3 +1,15 @@
> > > +libpng1.6 (1.6.48-1+deb13u1) trixie; urgency=medium
> >
> > This should be targetting trixie-security. The rest is ok, although
> > for I prefer to make explitily a urgency=high (but it is not
> > technically needed).
>
> fixed the suite.

Thanks.

> > > +  * Security upload targeting trixie.
> > > +  * Backport fixes for:
> > > +    - CVE-2025-64505 - Heap buffer over-read (Closes: #1121219)
> >
> > I think we should have applied here first the upstream commit
> > ea094764f343 ("Fix a memory leak in function `png_set_quantize`;
> > refactor"). This affect directly the code which we are fixing and
> > fixes a memory leak in png_set_quantize. It does not have a CVE
> > afaict, but it might be worth applying before the CVE-2025-64505 fix
> > as done in the upstream code, in particular because it is the same
> > Samsung-PENTEST reporter discovering the issues with CVE assigned.
>
> Well, https://github.com/pnggroup/libpng/security/advisories/GHSA-4952-h5wq-4m42
> tells commit 6a528eb is the fix for the CVE, which is what I've applied.
>
> The memory leak is not related to the CVE. As the discusison in the
> upstream PR #748 shows, png_quantitize *should* only be called once
> anyways; only subsequent calls will leak 256 bytes of memory.
>
> On top of the memory-leak-fix, ea094764f343 has additional refactoring,
> namely eliminating the struct member png_structrp->quantize_sort, so the
> effective fix is adding this line:
>       png_free(png_ptr, png_ptr->quantize_index);
> All other lines in this commit are refactoring.
>
> So certainly we can have this commit in the update, if you prefer
> that; I'd prefer at least not to have the refactoring bits, even if the
> code is straight forward.

Yes I'm aware it is not part of the respective CVE fix, but it was
directly related to another (diffrent), rather more negligible
security issue, and it makes the other fix directly applicaple, so I
was aksing about your opinion.

If you feel more conformtable without, then let's to that (I in fact
tried to cross check what other did, but apparently e.g. Ubuntu did
not yet update, and other neither. So let's keep your oginal propsed
one.

> > Can you clarify on the above question surrounding CVE-2025-64505?
> > Or is it too intrusive to backport to the 1.6.48 version in trixie?
> >
> > Additionally were you able the update against the published verfiers
> > form the GHSAs?
>
> I was able to check against the pocs for 505 and 506 (as attached to
> upstream issues 688 and 691) and after the updateI couldn't trigger them
> anymore. I was not able to get the poc for 65018 compiled.

Ok perfect, thank you. Please go ahead with the uploads to
security-master, both built with -sa and have fixed target suite.

I will then take care of the DSA release once things are ready.

Regards,
Salvatore


Reply to: