Re: CVE-2021-38595 incorrectly marked as not affecting Qt 5?
Hi Neil,
On Wed, Dec 01, 2021 at 03:33:10PM +0000, Neil Williams wrote:
> On Wed, 1 Dec 2021 13:38:48 +0000
> Neil Williams <codehelp@debian.org> wrote:
>
> > On Sun, 28 Nov 2021 21:02:16 +0100
> > Salvatore Bonaccorso <carnil@debian.org> wrote:
> >
> > > Hi Adrian, Neil,
> > >
> > > One additional point:
> > >
> > > On Sun, Nov 28, 2021 at 08:56:57PM +0100, Salvatore Bonaccorso
> > > wrote:
> > > > Hi,
> > > >
> > > > > > =====================================
> > > > > > data/CVE/list
> > > > > > =====================================
> > > > > > @@ -3785,8 +3785,8 @@ CVE-2021-38595
> > > > > > CVE-2021-38594
> > > > > > RESERVED
> > > > > > CVE-2021-38593 (Qt 5.0.0 through 6.1.2 has an out-of-bounds
> > > > > > write in QOutlineMapper::c ...)
> > > > > > - - qtbase-opensource-src <unfixed>
> > > > > > - - qtbase-opensource-src-gles <unfixed>
> > > > > > + - qtbase-opensource-src <not-affected> (Vulnerable
> > > > > > code introduced later)
> > > > > > + - qtbase-opensource-src-gles <not-affected>
> > > > > > (Vulnerable code introduced later) NOTE:
> > > > > > https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=35566
> > > > > > NOTE:
> > > > > > https://github.com/google/oss-fuzz-vulns/blob/main/vulns/qt/OSV-2021-903.yaml
> > > > > > NOTE:
> > > > > > https://github.com/qt/qtbase/commit/1ca02cf2879a5e1511a2f2109f0925cf4c892862
> > > > > > (6.1)
> > > > > >...
> > > > >
> > > > > Hi Neil,
> > > > >
> > > > > can you double-check that?
> > > > >
> > > > > Upload [1] makes me wonder whether the not-affected is correct,
> > > > > and "Qt 5.0.0 through 6.1.2" also implies all versions of
> > > > > qtbase-opensource-src{,-gles} would be affected.
> > > >
> > > > I currently think the tracking from Neil was correct. The Issue
> > > > was introduced by the commit
> > > > 2https://github.com/qt/qtbase/commit/6869d2463a2e0d71bd04dbc82f5d6ef4933dc510
> > > > .
> > > >
> > > > Now the maintainer has today uploaded
> > > > https://tracker.debian.org/news/1281817/accepted-qtbase-opensource-src-5152dfsg-14-source-into-unstable/
> > > > claiming it fixes CVE-2021-38593. But looking at the changes it
> > > > looks that the debian/patches/CVE-2021-38593.diff patch both used
> > > > https://code.qt.io/cgit/qt/qtbase.git/commit/?id=f4d791b330d02777
> > > > introducing the needed "breaking" change, and then as well the
> > > > fix.
> > > >
> > > > See as well https://bugzilla.suse.com/show_bug.cgi?id=1189652#c2
> > > > arguing in the same direction.
> > > >
> > > > We should recheck, but currently tend to that the tracking is
> > > > already correct.
> > >
> > > https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1950193
> > > contains some further information from Ubuntu's side. Does the test
> > > there triggers the exact out-of-bounds write issue from the CVE?
>
> In summary, no, I do not see an out of bounds write with the Launchpad
> test, either with or without the fix uploaded to unstable. The change
> in unstable does fix the issue reported in Launchpad but I don't see
> how that is meant to match against the CVE.
>
> > After testing with 5.15.2+dfsg-14 (unstable) and 5.15.2+dfsg-13
> > (bookworm):
> >
> > The specific test program from the Launchpad bug **does** exhibit the
> > behaviour, in bookworm, that the Launchpad bug describes as "you might
> > be affected".
> >
>
> Bullseye shows the original bug - that the test SVG simply does not get
> shown & the test program continues, taking up 100% of 1 core until
> killed by the user. The program does not die without intervention, as it
> does in bookworm.
>
> Bullseye: gdb reports no termination
> Bookworm: gdb reports "Program terminated with signal SIGKILL, Killed"
>
> The code referenced in the fixes for the CVE in unstable does not exist
> in bookworm or bullseye. Some other change is responsible for the
> effects shown when using the test SVG from Launchpad in bookworm.
>
> It looks like there is a long-standing bug in Qt5 that this type of SVG
> will trigger, causing Qt5 to stall, hogging 1 CPU at 100%. With the
> changes in bookworm, this bug now causes program termination *but gdb
> does not show any evidence of an out-of-bounds write*, just that the
> QApplication terminates. The vulnerable code from the CVE does not
> exist in bookworm.
>
> In bookworm, there is a change in behaviour which will be fixed
> when the package from unstable migrates in a few days. This temporary
> issue does not look like CVE-2021-38595 - it looks like a different bug.
>
> IMHO the Launchpad bug conflates two different issues:
>
> - CVE-2021-38593 - an out-of-bounds write - Qt6
> - the Launchpad svg file will block one core at 100% and occupy much
> memory
>
> I don't see that these are the same problem. The CVE was introduced in
> Qt6 code. The code to trigger the stalling bug still exists in Qt5
> after the fix for the CVE is applied, it's just that the CVE fix
> introduces *new* code that tries to handle the specially crafted
> test SVG, then falls back to the old stalling code if the new code is
> not called.
>
> Bullseye has the original bug
> Bookworm has a new bug which causes the test program to crash & still
> has the original bug.
> unstable fixes the test program crash from bookworm but still has the
> original bug, it just works around it for the tested SVG. It is not
> clear whether another crafted SVG would skip the fix from unstable and
> execute the original code flow.
>
> The commits added to unstable address the Launchpad issue of consuming
> 100% of one core using the provided test SVG. IMHO the commits do not
> address the CVE because the vulnerable code of that CVE does not exist.
>
> * Backport four upstream commits to fix massive memory consumption
> when rendering specially crafted SVG files (CVE-2021-38593, LP:
> #1950193).
>
> As noted in https://bugzilla.suse.com/show_bug.cgi?id=1189652#c2,
>
> it was only applied to very recent 5.15(at least not for 5.15.2,
> possibly does exist in 5.15.3 but 5.15.3 and above are for commercial
> license user only) and 6.x series,
>
> If a different SVG is supplied which doesn't trigger the new code, Qt5
> in bookworm would use the same slow code as bullseye & the same is true
> in unstable - the slow code path still exists there too.
>
> https://sources.debian.org/src/qtbase-opensource-src/5.15.2+dfsg-14/src/gui/painting/qpaintengineex.cpp/#L438
>
> https://sources.debian.org/src/qtbase-opensource-src/5.15.2+dfsg-13/src/gui/painting/qpaintengineex.cpp/#L406
>
> https://sources.debian.org/src/qtbase-opensource-src/5.15.2+dfsg-9/src/gui/painting/qpaintengineex.cpp/#L406
>
> Overall, I see no vulnerable code in Qt5 for CVE-2021-38595 and the
> reported fix appears to be addressing a different bug to handle a
> specific test SVG.
Thank your for doing again the analysis. So I think regarding the
specific CVE we do correctly track the issue, and the other issue from
the Launchpad in Ubuntu is idfferent. TTBOMK there is not CVE assigned
to it, but I would probably not bother to going to spend time to it.
TBH, I fear that would cause more conflicts in tracking to any other
for not much benefit for a issue which can be classified minor.
If someone want's to go down the rabbit hole and request a CVE for the
"consumes 100% of one core when processing specially crafted SVG
files" though this can be done. We should then though carefully update
the tracking information to not mix up the issues.
Regards,
Salvatore
Reply to: