When hashing empty strings which aren't null-terminated, xmlDictComputeFastKey could produce inconsistent results. This could lead to various logic or memory errors, including double frees. References: https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.10.4 https://gitlab.gnome.org/GNOME/libxml2/-/commit/09a2dd453007f9c7205274623acdd73747c22d64
Created libxml2 tracking bugs for this issue: Affects: fedora-all [bug 2185985]
Created mingw-libxml2 tracking bugs for this issue: Affects: fedora-all [bug 2185987] Created pcem tracking bugs for this issue: Affects: fedora-all [bug 2185988] Created qt5-qtwebengine tracking bugs for this issue: Affects: epel-all [bug 2185986] Affects: fedora-all [bug 2185989] Created qt6-qtwebengine tracking bugs for this issue: Affects: fedora-all [bug 2185990] Created rubygem-nokogiri tracking bugs for this issue: Affects: epel-all [bug 2185992] Affects: fedora-all [bug 2185991]
@Pedro I wonder how the list of affected libraries is compiled? I understand that rubygem-nokogiri might bundle libxml2, but that is not the case. It is very unfortunate, that ProdSec recently started to file these false positives trackers. Unfortunately, OTOH, we don't have trackers which really affects some components (e.g. CVE-2023-28755, CVE-2023-28756).
(In reply to Vít Ondruch from comment #3) > @Pedro I wonder how the list of affected libraries is compiled? I understand > that rubygem-nokogiri might bundle libxml2, but that is not the case. It is > very unfortunate, that ProdSec recently started to file these false > positives trackers. Unfortunately, OTOH, we don't have trackers which really > affects some components (e.g. CVE-2023-28755, CVE-2023-28756). The list is compiled from information in the report combined with the data in our package manifests. We have to rely on the information from the report for the initial assessment and bug filling. That's why sometimes we'll put in the affects list, packages that might not be affected. Unfortunately we have to delegate some of the affect checking to other Teams.
(In reply to Pedro Sampaio from comment #7) > (In reply to Vít Ondruch from comment #3) > > @Pedro I wonder how the list of affected libraries is compiled? I understand > > that rubygem-nokogiri might bundle libxml2, but that is not the case. It is > > very unfortunate, that ProdSec recently started to file these false > > positives trackers. Unfortunately, OTOH, we don't have trackers which really > > affects some components (e.g. CVE-2023-28755, CVE-2023-28756). > > The list is compiled from information in the report combined with the data > in our package manifests. We have to rely on the information from the report > for the initial assessment and bug filling. That's why sometimes we'll put > in the affects list, packages that might not be affected. Unfortunately we > have to delegate some of the affect checking to other Teams. So could you please update your package manifests and mark there that rubygem-nokogiri does not bundle libxml2, so we don't need to have this discussion again? BTW if rubygem-nokogiri bundled libxml2, there would be `bundled(libxml2)` provide which: 1) is still mandatory in Fedora AFAIK [1] 2) is not there. [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling
(In reply to Vít Ondruch from comment #8) > (In reply to Pedro Sampaio from comment #7) > > (In reply to Vít Ondruch from comment #3) > > > @Pedro I wonder how the list of affected libraries is compiled? I understand > > > that rubygem-nokogiri might bundle libxml2, but that is not the case. It is > > > very unfortunate, that ProdSec recently started to file these false > > > positives trackers. Unfortunately, OTOH, we don't have trackers which really > > > affects some components (e.g. CVE-2023-28755, CVE-2023-28756). > > > > The list is compiled from information in the report combined with the data > > in our package manifests. We have to rely on the information from the report > > for the initial assessment and bug filling. That's why sometimes we'll put > > in the affects list, packages that might not be affected. Unfortunately we > > have to delegate some of the affect checking to other Teams. > > So could you please update your package manifests and mark there that > rubygem-nokogiri does not bundle libxml2, so we don't need to have this > discussion again? > > BTW if rubygem-nokogiri bundled libxml2, there would be `bundled(libxml2)` > provide which: > > 1) is still mandatory in Fedora AFAIK [1] > 2) is not there. > > > > [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling Thank you for the info. I'll update de manifests.
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2023:4349 https://access.redhat.com/errata/RHSA-2023:4349
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2023:4529 https://access.redhat.com/errata/RHSA-2023:4529
This issue has been addressed in the following products: Red Hat JBoss Core Services Via RHSA-2023:4628 https://access.redhat.com/errata/RHSA-2023:4628
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.6 Extended Update Support Via RHSA-2024:0413 https://access.redhat.com/errata/RHSA-2024:0413