CVE-2021-3481 (https://bugreports.qt.io/browse/QTBUG-91507): A flaw was found in Qt. An out-of-bounds read vulnerability was found in QRadialFetchSimd in qt/qtbase/src/gui/painting/qdrawhelper_p.h in Qt/Qtbase. While rendering and displaying a crafted Scalable Vector Graphics (SVG) file this flaw may lead to an unauthorized memory access. The highest threat from this vulnerability is to data confidentiality and the application availability. Looks like this is in 5.12.11 as 9311a42677db244cd1c584f27270fa73f69d90d7
(In reply to John Helmert III from comment #0) > CVE-2021-3481 (https://bugreports.qt.io/browse/QTBUG-91507): > > A flaw was found in Qt. An out-of-bounds read vulnerability was found in > QRadialFetchSimd in qt/qtbase/src/gui/painting/qdrawhelper_p.h in Qt/Qtbase. > While rendering and displaying a crafted Scalable Vector Graphics (SVG) file > this flaw may lead to an unauthorized memory access. The highest threat from > this vulnerability is to data confidentiality and the application > availability. > > Looks like this is in 5.12.11 as 9311a42677db244cd1c584f27270fa73f69d90d7 Which doesn't go in summary without a bump in tree, of course
No affected versions in Gentoo since 2022-04-17.
(In reply to Andreas Sturmlechner from comment #2) > No affected versions in Gentoo since 2022-04-17. Could you share how to verify that?
(In reply to John Helmert III from comment #3) > (In reply to Andreas Sturmlechner from comment #2) > > No affected versions in Gentoo since 2022-04-17. > > Could you share how to verify that? The latest public open source upstream Qt LTC release is 5.15.5. In Gentoo, we use KDE's Qt5PatchCollection on top of that (and Qt5PatchCollection is rebased on every new Qt release). The Qt releases come out a year after they were made available to paying customers. So, we'd have to do digging to look around in https://invent.kde.org/qt/qt/qtsvg/-/commits/kde/5.15. I see the commit there but I'm not sure how to verify the exact versions. asturm is best placed because he generates the patch tarballs from the KDE repos (they don't produce tags for the patchset)
Ah, I see. I'm quite happy trusting asturm, but I try to verify everything. Only an OOB read, so no GLSA.
(In reply to John Helmert III from comment #5) > Ah, I see. I'm quite happy trusting asturm, but I try to verify everything. > > Only an OOB read, so no GLSA. A solution might be for us to either keep an archive of the patch tarballs used (and/or put some metadata into them), or to do something like we do for glibc, and have our own Gentoo qt branch which we rebase (and tag) on top of it. I'd like that but I don't want to impose more work on asturm.
Correction: This was already merged 1 year ago, so the fix was part of our very first Qt5PatchCollection snapshot qtsvg-5.15.2-r10, which was stabilised and the affected version subsequently cleaned up on 2021-10-17, so much earlier than I thought.
