Upgrade to libxml2-2.15.4 in F45

zbyszek commented

2026-09-15 14:39:04 +00:00

Member

The current libxml2 version has a bunch of vulnerabilities and updating to the latest version is recommended. As the first step, I performed the upgrade in rawhide. It went through without breaking things. I'd like to do the same in F45 before the final freeze, so that F45 final carries the fixed builds. This has the additional advantage that once we're past the SONAME bump, if subsequent point releases are made, we can update more easily.

A handful of packages FTBFS. A compat package is provided, so they should continue to install and work. The compat package has a -devel package, so if something FTBFS with the new libxml2, it can use the old version.

When doing builds for rawhide, the builds took a few days because the test build in copr didn't properly discover all the issues. I expect that the secound round in F45 should be much faster.

(approximate CVE list, I didn't verify if they all actually are relevant to our builds)
CVE-2025-8732 2.15.2 Uncontrolled recursion / stack overflow in SGML catalog parsing
CVE-2026-0989 2.15.2 Stack exhaustion from recursive RelaxNG directives
CVE-2026-0990 2.15.2 Infinite recursion in XML catalog URI resolution
CVE-2026-0992 2.15.2 Excessive resource consumption from XML catalog processing
CVE-2026-1757 2.15.2 Memory leak in the xmllint interactive shell
CVE-2026-6732 2.15.3 Type confusion when processing an XSD with an internal entity
CVE-2026-11979 2.15.4 Stack-based buffer overflows in xmlcatalog --shell
CVE-2026-86137 2.15.4 Out-of-bounds read in xmlregexp NXT macro
CVE-2026-86138 2.15.4 Integer overflow in xmlDictAddQString
CVE-2026-86139 2.15.4 Integer overflow in xmlURIEscapeStr
CVE-2026-86140 2.15.4 Stack-based buffer overflow in xmlSnprintfElements
CVE-2026-86141 2.15.4 NULL-pointer dereference in xmlregexp
CVE-2026-86142 2.15.4 Heap-based buffer overflow
CVE-2026-86143 2.15.4 Integer overflow in xmlOutputWrite
CVE-2026-86144 2.15.4 XInclude parsing issue due to incorrect propagation of parse flags

The current libxml2 version has a bunch of vulnerabilities and updating to the latest version is recommended. As the first step, I performed the upgrade in rawhide. It went through without breaking things. I'd like to **do the same in F45 before the final freeze**, so that F45 final carries the fixed builds. This has the additional advantage that once we're past the SONAME bump, if subsequent point releases are made, we can update more easily. A handful of packages FTBFS. A compat package is provided, so they should continue to install and work. The compat package has a -devel package, so if something FTBFS with the new libxml2, it can use the old version. When doing builds for rawhide, the builds took a few days because the test build in copr didn't properly discover all the issues. I expect that the secound round in F45 should be much faster. (approximate CVE list, I didn't verify if they all actually are relevant to our builds) CVE-2025-8732 2.15.2 Uncontrolled recursion / stack overflow in SGML catalog parsing CVE-2026-0989 2.15.2 Stack exhaustion from recursive RelaxNG <include> directives CVE-2026-0990 2.15.2 Infinite recursion in XML catalog URI resolution CVE-2026-0992 2.15.2 Excessive resource consumption from XML catalog processing CVE-2026-1757 2.15.2 Memory leak in the xmllint interactive shell CVE-2026-6732 2.15.3 Type confusion when processing an XSD with an internal entity CVE-2026-11979 2.15.4 Stack-based buffer overflows in xmlcatalog --shell CVE-2026-86137 2.15.4 Out-of-bounds read in xmlregexp NXT macro CVE-2026-86138 2.15.4 Integer overflow in xmlDictAddQString CVE-2026-86139 2.15.4 Integer overflow in xmlURIEscapeStr CVE-2026-86140 2.15.4 Stack-based buffer overflow in xmlSnprintfElements CVE-2026-86141 2.15.4 NULL-pointer dereference in xmlregexp CVE-2026-86142 2.15.4 Heap-based buffer overflow CVE-2026-86143 2.15.4 Integer overflow in xmlOutputWrite CVE-2026-86144 2.15.4 XInclude parsing issue due to incorrect propagation of parse flags

zbyszek added this to the Fedora Linux 45 milestone

2026-09-15 14:39:04 +00:00

zbyszek added the

meeting

label

2026-09-15 14:39:04 +00:00

decathorpe commented

2026-09-15 14:44:55 +00:00

Member

I think it's now much too late in the F45 cycle to push an update that requires rebuilding almost 500 packages. -1

I think it's now much too late in the F45 cycle to push an update that requires rebuilding almost 500 packages. **-1**

gotmax23 commented

2026-09-15 16:32:57 +00:00

Member

I am also hesitant. +0 for now. This will be on the meeting agenda today. Some questions:

@zbyszek, how do you plan to perform this rebuild in f45 which has already diverged from rawhide? Overall, how severe/reasonably exploitable are these CVEs? Can any of the fixes be backported without breaking ABI/API? Can we consult Fedora Quality here given the timing (CC @adamwill @kparal)?

I am also hesitant. +0 for now. This will be on the meeting agenda today. Some questions: @zbyszek, how do you plan to perform this rebuild in `f45` which has already diverged from rawhide? Overall, how severe/reasonably exploitable are these CVEs? Can any of the fixes be backported without breaking ABI/API? Can we consult Fedora Quality here given the timing (CC @adamwill @kparal)?

zbyszek commented

2026-09-15 17:06:23 +00:00

Author

Member

how do you plan to perform this rebuild in f45 which has already diverged from rawhide?

For packages where the branch hasn't diverged, fast-forward the f45 branch and build. Where it has diverged, make a new commit. I haven't seen much significant diversion though. There was one package (IIRC) which built in f45 but not in rawhide, and maybe one the other way around.

Overall, how severe/reasonably exploitable are these CVEs?

Considering the number of packages that link to this library, it's very hard to estimate impact. This might potentially affect processing of untrusted xml in many different places. As for backports, there's a bunch of changes and I don't want to do that.

> how do you plan to perform this rebuild in f45 which has already diverged from rawhide? For packages where the branch hasn't diverged, fast-forward the f45 branch and build. Where it has diverged, make a new commit. I haven't seen much significant diversion though. There was one package (IIRC) which built in f45 but not in rawhide, and maybe one the other way around. > Overall, how severe/reasonably exploitable are these CVEs? Considering the number of packages that link to this library, it's very hard to estimate impact. This might potentially affect processing of untrusted xml in many different places. As for backports, there's a bunch of changes and I don't want to do that.

ngompa commented

2026-09-15 18:06:44 +00:00

Member

I'm a little squirrelly about this, but realistically this is a hyper-critical library. It is very likely we might be forced to do a mega-update later as a policy exception anyway. We use libxml2 even in our core package management, so having it updated matters a fair bit.

I don't like it, but I would allow it through since it should be a straightforward merge back from rawhide. +1

I'm a little squirrelly about this, but realistically this is a hyper-critical library. It is very likely we might be forced to do a mega-update later as a policy exception anyway. We use libxml2 even in our core package management, so having it updated matters a fair bit. I don't like it, but I would allow it through since it should be a straightforward merge back from rawhide. +1

gotmax23 commented

2026-09-15 18:24:41 +00:00

Member

I'm +1 to allowing this rebuild as an Update Policy Exception due to the security issues if we really can't solve it any other way. I don't think we necessarily need to re-target the Change back to F45. It's already way past the appropriate deadlines.

I would suggest that you announce the rebuild on the devel list and wait a week, so in cases where rawhide already diverges from f45, maintainers have the option to ask to merge back the new commits from rawhide to f45 and keep the branches in sync. Some maintainers (e.g., for leaf packages with frequent updates) feel strongly about keeping Fedora branches in sync so git merge --ff-only still works.

I'm +1 to allowing this rebuild as an Update Policy Exception due to the security issues if we really can't solve it any other way. I don't think we necessarily need to re-target the Change back to F45. It's already way past the appropriate deadlines. I would suggest that you announce the rebuild on the devel list and wait a week, so in cases where `rawhide` already diverges from `f45`, maintainers have the option to ask to merge back the new commits from rawhide to f45 and keep the branches in sync. Some maintainers (e.g., for leaf packages with frequent updates) feel strongly about keeping Fedora branches in sync so `git merge --ff-only` still works.

supakeen commented

2026-09-15 18:42:25 +00:00

Member

I just feel like we can't ship 45 with this many CVEs in such a widely used library so I'm +1. Do note that a lot more divergence might have happened now/after freeze lifted.

adamwill commented

2026-09-15 19:08:42 +00:00

So, since you wanted QA thoughts: the fact that this resolves significant CVEs changes the picture significantly. With my QA hat on I am generally against Changes landing late; we have a Change process for a reason. But in this case I think the existence of the Change obscures the picture a bit. If we pretend there had never been a Change proposed for F45 at all, we are left with the problem that we have a libxml2 package that's subject to apparently major security issues (I didn't read them all, but anything that says "overflow" or "out of bounds" in relation to a library for reading untrusted input scares me).

Unless we actually decide all these CVEs are minor, we really ought to address them somehow, no matter where we are in the release cycle and regardless of the Change process. We're just on the update policy now.

As that says, ideally fixes should be backported without breaking API/ABI and requiring rebuilds. But if that's not practical, then I think doing the bump and rebuilds is better than doing nothing. And if we're going to do it we should do it now before Final freeze.

So, since you wanted QA thoughts: the fact that this resolves significant CVEs changes the picture significantly. With my QA hat on I am generally against Changes landing late; we have a Change process for a reason. But in this case I think the existence of the Change obscures the picture a bit. If we pretend there had never been a Change proposed for F45 at all, we are left with the problem that we have a libxml2 package that's subject to apparently major security issues (I didn't read them all, but anything that says "overflow" or "out of bounds" in relation to a library for reading untrusted input scares me). Unless we actually decide all these CVEs are minor, we really ought to address them *somehow*, no matter where we are in the release cycle and regardless of the Change process. We're just on the [update policy](https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/) now. As that says, ideally fixes should be backported without breaking API/ABI and requiring rebuilds. But if that's not practical, then I think doing the bump and rebuilds is better than doing nothing. And if we're going to do it we should do it *now* before Final freeze.

❤️ 1

kevin commented

2026-09-15 20:23:36 +00:00

Owner

I'm a weak +1
I dislike this curn post beta, but the security issues need to be dealt with.

I'm a weak +1 I dislike this curn post beta, but the security issues need to be dealt with.

zbyszek commented

2026-09-15 21:16:16 +00:00

Author

Member

Packages in the build list where f45 is not an ancestor of rawhide: anaconda dnf5 epiphany evolution-data-server flatpak gnome-app-list gnome-calculator gnome-connections gnome-control-center gnome-maps gnote gvfs librepo llvm22 localsearch nfs-utils php rygel tinysparql wireshark yelp.
But in almost all cases, the same commits appear on both branches. flatpak and php have version divergence, wireshark has some chaos.

In the remaining packages open-vm-tools mstflint liblangtag labwc ffmpeg ddccontrol have nontrivial changes in rawhide that are not in f45.

So overall, great majority of packages can be just fast-forwarded in f45. A handful needs custom handling.

Packages in the build list where `f45` is not an ancestor of `rawhide`: anaconda dnf5 epiphany evolution-data-server flatpak gnome-app-list gnome-calculator gnome-connections gnome-control-center gnome-maps gnote gvfs librepo llvm22 localsearch nfs-utils php rygel tinysparql wireshark yelp. But in almost all cases, the same commits appear on both branches. flatpak and php have version divergence, wireshark has some chaos. In the remaining packages open-vm-tools mstflint liblangtag labwc ffmpeg ddccontrol have nontrivial changes in rawhide that are not in f45. So overall, great majority of packages can be just fast-forwarded in f45. A handful needs custom handling.

zbyszek commented

2026-09-15 21:20:29 +00:00

Author

Member

FTR, after looking at this now, I still think it's reasonable to do this. Still +1 ;)

decathorpe commented

2026-09-16 11:02:00 +00:00

Member

Alright. I'll grumble and mumble and change my -1 vote to a ±0 when viewing this as an "Updates Policy Exception" ticket.

zbyszek commented

2026-09-16 11:44:47 +00:00

Author

Member

The llvm23 update for f45 was pushed to stable, so now this could be done too. @siosm, @duffy, @salimma?

zbyszek commented

2026-09-16 13:07:07 +00:00

Author

Member

I think it makes sense to mark this for FastTrack. Otherwise, we'd most likely wait until next Tuesday.

zbyszek added

fast track

and removed

meeting

labels

2026-09-16 13:07:17 +00:00

zbyszek changed title from ~~Upgrade to libxml2-2.15.4 in F45~~ to [FastTrack] Upgrade to libxml2-2.15.4 in F45

2026-09-16 13:07:24 +00:00

gotmax23 added the

updates policy exception

label

2026-09-16 13:46:01 +00:00

gotmax23 commented

2026-09-16 13:57:56 +00:00

Member

I'm fine with fast track, but please give some notice on the devel list and wait before starting to push commits and builds to avoid any conflicts with other updates. Also, I tagged the issue as an updates policy exception.

zbyszek commented

2026-09-16 15:41:43 +00:00

Author

Member

I sent a mail: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/V56QVLVZMMPA3TOKNU6MPUPSMNFPGO5Q/

salimma commented

2026-09-22 10:24:08 +00:00

Member

I guess the fast track did not seem to really work since none of us sent a reminder after 48 hours ...

I'm also getting quite concerned that some FESCo members are basically effectively ... non-responsive. Given we need +7 and Fabio was +0, basically if I vote +0 as I did in the meeting you need everyone else to vote in favor

I guess the fast track did not seem to really work since none of us sent a reminder after 48 hours ... I'm also getting quite concerned that some FESCo members are basically effectively ... non-responsive. Given we need +7 and Fabio was +0, basically if I vote +0 as I did in the meeting you need everyone else to vote in favor

supakeen commented

2026-09-22 10:32:05 +00:00

Member

@salimma wrote in #3685 (comment):

I guess the fast track did not seem to really work since none of us sent a reminder after 48 hours ...

I'm also getting quite concerned that some FESCo members are basically effectively ... non-responsive. Given we need +7 and Fabio was +0, basically if I vote +0 as I did in the meeting you need everyone else to vote in favor

Who are we missing? We can tag them directly I guess.

@salimma wrote in https://forge.fedoraproject.org/fesco/tickets/issues/3685#issuecomment-1359218: > I guess the fast track did not seem to really work since none of us sent a reminder after 48 hours ... > > I'm also getting quite concerned that some FESCo members are basically effectively ... non-responsive. Given we need +7 and Fabio was +0, basically if I vote +0 as I did in the meeting you need everyone else to vote in favor Who are we missing? We can tag them directly I guess.

salimma commented

2026-09-22 10:37:57 +00:00

Member

Reminder sent - https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LOJYRDEHEX2NY7LR2WZDS5GJEBHSP7ZX/ - I'll do a procedural -1 to force a meeting vote if we don't hear back in the next few hours

zbyszek added the

Status

Accepted

pending announcement

labels

2026-09-23 20:12:11 +00:00

zbyszek commented

2026-09-23 20:12:32 +00:00