Bug 2015229 (CVE-2021-28021)

Created stb tracking bugs for this issue:

Affects: epel-all [bug 2015232]
Affects: fedora-all [bug 2015231]

I am the maintainer of the “stb” package in Fedora and in EPEL.

The separate stb package in Fedora (and EPEL8 and EPEL7) is only a couple of months old, and the oldest packaged stb_image version was 2.27. Nevertheless, the initial packaged version was affected by this CVE, as explained in the following paragraph.

The CVE text claims the latest affected version is 2.26, but this is not quite right. The upstream fix in https://github.com/nothings/stb/commit/5ba0baaa269b3fd681828e0e3b3ac0f1472eaf40 came after the bump to stb_image 2.27 in https://github.com/nothings/stb/commit/3a7dcdd2696ed7b85f892f951b0801e382b81778—so even though the “stb” package has never contained stb_image 2.26 or earlier, the initial package *was* affected by the CVE, and the current version *is not* affected, even though both provide stb_image 2.27. Is that confusing enough?

The following are the Bodhi updates (each already in stable) in which the CVE was corrected.

F36: https://bodhi.fedoraproject.org/updates/FEDORA-2021-35ace22099
F35: https://bodhi.fedoraproject.org/updates/FEDORA-2021-f049bf1e9a
F34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-91a1112a15
F33: https://bodhi.fedoraproject.org/updates/FEDORA-2021-7251e0ffa8
EPEL8: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-a3ef29c6c4
EPEL7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-def1471d2b

Accordingly, there is no need for a further update to the stb package in response to this issue.

Since stb_image is a header-only library, fully eradicating vulnerable code associated with the “stb” package would require rebuilding any package that depends on “stb_image-devel” and/or “stb_image-static”.

Furthermore, since stb libraries are designed for bundling, it is likely that vulnerable versions do remain bundled with other packages in the distribution—either properly marked with “Provides: bundled(stb_image) = […]”, or, quite commonly, undetected. Wherever possible, I suggest migrating any such packages to use the unbundled stb_image-devel/stb_image-static provided here. I’m happy to assist with any such efforts upon request.

Please let me know if there is anything I can do.

Flaw summary:

In stb_image.h, a crafted JPEG file could cause stbi__jpeg_huff_decode() to return values out-of-range which were then passed as the 'n' argument into stbi__extend_receive(). The max 'n' value that stbi_extend_receive() is designed to handle is <= 15, and values outside of this range can trigger an out-of-bounds read in global memory.

In reply to comment #2:
> The CVE text claims the latest affected version is 2.26, but this is not
> quite right. The upstream fix in
> https://github.com/nothings/stb/commit/
> 5ba0baaa269b3fd681828e0e3b3ac0f1472eaf40 came after the bump to stb_image
> 2.27 in
> https://github.com/nothings/stb/commit/
> 3a7dcdd2696ed7b85f892f951b0801e382b81778—so even though the “stb” package
> has never contained stb_image 2.26 or earlier, the initial package *was*
> affected by the CVE, and the current version *is not* affected, even though
> both provide stb_image 2.27. Is that confusing enough?

> Please let me know if there is anything I can do.
Hi,

So in essence, you're saying that version 2.27 is both affected and unaffected because the patch was applied but not during a version bump (in fact, after one)? So it would be misleading to state that the "fixed version" is 2.27 because there are 2.27s floating around out there that are also vulnerable? Is this a fair statement?

> So in essence, you're saying that version 2.27 is both affected and unaffected because the patch was applied but not during a version bump (in fact, after one)? So it would be misleading to state that the "fixed version" is 2.27 because there are 2.27s floating around out there that are also vulnerable? Is this a fair statement?

Yes, exactly.

In reply to comment #7:
> > So in essence, you're saying that version 2.27 is both affected and unaffected because the patch was applied but not during a version bump (in fact, after one)? So it would be misleading to state that the "fixed version" is 2.27 because there are 2.27s floating around out there that are also vulnerable? Is this a fair statement?
> 
> Yes, exactly.

Oh lovely, thanks for the heads up...

As a heads-up, see also the similar flaw https://nvd.nist.gov/vuln/detail/CVE-2021-42716, which affects stb_image 2.27. It was reported 2021-07-14 and assiged a CVE yesterday (2021-10-21). No official fix is yet available.

Aaaaaand also https://nvd.nist.gov/vuln/detail/CVE-2021-42715.

It turns out there is a PR open to fix both CVE-2021-42715 and CVE-2021-42716. I just applied that PR as a downstream patch in Rawhide and will be rolling out updates for stable Fedora and EPEL releases.

All of that has, strictly speaking, nothing to do with *this* issue and CVE.

To clarify the status for cogl and clutter.

The cogl library contains an old version of stb_image.c, however this is only compiled in when cogl in when gdk-pixbuf support is disabled. cogl as shipped in  RHEL and Fedora uses gdk-pixbuf, so is not affected by this vulnerability.  This also applies to the bundled copy of cogl inside clutter in RHEL 6 and very old versions of Fedora.

FEDORA-2021-001f25d986 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2021-8ea648186c has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2021-16d848834d has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.