An issue was discovered in Pillow before 8.2.0. There is an out-of-bounds read in J2kDecode, in j2ku_gray_i.

Pillow (PIL Fork)

**Deprecations¶**

**Categories¶**

`im.category` is deprecated and will be removed in Pillow 10.0.0 (2023-01-02), along with the related `Image.NORMAL`, `Image.SEQUENCE` and `Image.CONTAINER` attributes.

To determine if an image has multiple frames or not, `getattr(im, "is_animated", False)` can be used instead.

**Tk/Tcl 8.4¶**

Support for Tk/Tcl 8.4 is deprecated and will be removed in Pillow 10.0.0 (2023-01-02), when Tk/Tcl 8.5 will be the minimum supported.

**API Changes¶**

**Image.alpha\_composite: dest¶**

When calling `alpha_composite()`, the `dest` argument now accepts negative co-ordinates, like the upper left corner of the `box` argument of `paste()` can be negative. Naturally, this has effect of cropping the overlaid image.

**Image.getexif: EXIF and GPS IFD¶**

Previously, `getexif()` flattened the EXIF IFD into the rest of the data, losing information. This information is now kept separate, moved under `im.getexif().get_ifd(0x8769)`.

Direct access to the GPS IFD dictionary was possible through `im.getexif()[0x8825]`. This is now consistent with other IFDs, and must be accessed through `im.getexif().get_ifd(0x8825)`.

These changes only affect `getexif()`, introduced in Pillow 6.0. The older `_getexif()` methods are unaffected.

**Image.\_MODEINFO¶**

This internal dictionary had been deprecated by a comment since PIL, and is now removed. Instead, `Image.getmodebase()`, `Image.getmodetype()`, `Image.getmodebandnames()`, `Image.getmodebands()` or `ImageMode.getmode()` can be used.

**API Additions¶**

**getxmp() for JPEG images¶**

A new method has been added to return XMP data for JPEG images. It reads the XML data into a dictionary of names and values.

For example:

\>>> from PIL import Image
\>>> with Image.open("Tests/images/xmp\_test.jpg") as im:
\>>>     print(im.getxmp())
{'RDF': {}, 'Description': {'Version': '10.4', 'ProcessVersion': '10.0', ...}, ...}

**ImageDraw.rounded\_rectangle¶**

Added `rounded_rectangle()`. It works the same as `rectangle()`, except with an additional `radius` argument. `radius` is limited to half of the width or the height, so that users can create a circle, but not any other ellipse.

from PIL import Image, ImageDraw
im \= Image.new("RGB", (200, 200))
draw \= ImageDraw.Draw(im)
draw.rounded\_rectangle(xy\=(10, 20, 190, 180), radius\=30, fill\="red")

**ImageOps.autocontrast: preserve\_tone¶**

The default behaviour of `autocontrast()` is to normalize separate histograms for each color channel, changing the tone of the image. The new `preserve_tone` argument keeps the tone unchanged by using one luminance histogram for all channels.

**ImageShow.GmDisplayViewer¶**

If GraphicsMagick is present, this new `PIL.ImageShow.Viewer` subclass will be registered. It uses GraphicsMagick, an ImageMagick fork, to display images.

The GraphicsMagick based viewer has a lower priority than its ImageMagick counterpart. Thus, if both ImageMagick and GraphicsMagick are installed, `im.show()` and `ImageShow.show()` prefer the viewer based on ImageMagick, i.e the behaviour stays the same for Pillow users having ImageMagick installed.

**ImageShow.IPythonViewer¶**

If IPython is present, this new `PIL.ImageShow.Viewer` subclass will be registered. It displays images on all IPython frontends. This will be helpful to users of Google Colab, allowing `im.show()` to display images.

It is lower in priority than the other default `PIL.ImageShow.Viewer` instances, so it will only be used by `im.show()` or `ImageShow.show()` if none of the other viewers are available. This means that the behaviour of `PIL.ImageShow` will stay the same for most Pillow users.

**Saving TIFF with ICC profile¶**

As is already possible for JPEG, PNG and WebP, the ICC profile for TIFF files can now be specified through a keyword argument:

im.save("out.tif", icc\_profile\=...)

**Security¶**

These were all found with OSS-Fuzz.

**CVE-2021-25287, CVE-2021-25288: Fix OOB read in Jpeg2KDecode¶**

*   For J2k images with multiple bands, it’s legal to have different widths for each band, e.g. 1 byte for `L`, 4 bytes for `A`.
    
*   This dates to Pillow 2.4.0.
    

**CVE-2021-28676: Fix FLI DOS¶**

*   `FliDecode.c` did not properly check that the block advance was non-zero, potentially leading to an infinite loop on load.
    
*   This dates to the PIL fork.
    

**CVE-2021-28677: Fix EPS DOS on \_open¶**

*   The readline used in EPS has to deal with any combination of `\r` and `\n` as line endings. It accidentally used a quadratic method of accumulating lines while looking for a line ending.
    
*   A malicious EPS file could use this to perform a denial-of-service of Pillow in the open phase, before an image was accepted for opening.
    
*   This dates to the PIL fork.
    

**CVE-2021-28678: Fix BLP DOS¶**

*   `BlpImagePlugin` did not properly check that reads after jumping to file offsets returned data. This could lead to a denial-of-service where the decoder could be run a large number of times on empty data.
    
*   This dates to Pillow 5.1.0.
    

**Fix memory DOS in ImageFont¶**

*   A corrupt or specially crafted TTF font could have font metrics that lead to unreasonably large sizes when rendering text in font. `ImageFont.py` did not check the image size before allocating memory for it.
    
*   This dates to the PIL fork.
    

**Other Changes¶**

**GIF writer uses LZW encoding¶**

GIF files are now written using LZW encoding, which will generate smaller files, typically about 70% of the size generated by the older encoder.

The pixel data is encoded using the format specified in the CompuServe GIF standard.

The older encoder used a variant of run-length encoding that was compatible but less efficient.

**GraphicsMagick¶**

The test suite can now be run on systems which have GraphicsMagick but not ImageMagick installed. If both are installed, the tests prefer ImageMagick.

**Libraqm and FriBiDi linking¶**

The way the libraqm dependency for complex text scripts is linked has been changed:

Source builds will now link against the system version of libraqm at build time rather than at runtime by default.

Binary wheels now include a statically linked modified version of libraqm that links against FriBiDi at runtime instead. This change is intended to address issues with the previous implementation on some platforms. These are created by building Pillow with the new build flags `--vendor-raqm --vendor-fribidi`.

Windows users will now need to install `fribidi.dll` (or `fribidi-0.dll`) only, `libraqm.dll` is no longer used.

See installation documentation for more information.

**PyQt6¶**

Support has been added for PyQt6. If it is installed, it will be used instead of PySide6, PyQt5 or PySide2.

CVE-2021-25288: 8.2.0

Istio before 1.8.6 and 1.9.x before 1.9.5 contains a remotely exploitable vulnerability where an external client can access unexpected services in the cluster, bypassing authorization checks, when a gateway is configured with AUTO_PASSTHROUGH routing configuration.

An external client can access unexpected services in the cluster, bypassing authorization checks, when a gateway is configured with AUTO\_PASSTHROUGH routing configuration.

Disclosure Details

CVE(s)

CVE-2021-31921  

CVSS Impact Score

10 AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Affected Releases

All releases prior to 1.8.6  
1.9.0 to 1.9.4  

**Issue**

Istio contains a remotely exploitable vulnerability where an external client can access unexpected services in the cluster, bypassing authorization checks, when a gateway is configured with AUTO_PASSTHROUGH routing configuration.

**Am I impacted?**

This vulnerability impacts only usage of the AUTO_PASSTHROUGH Gateway type, which is typically only used in multi-network multi-cluster deployments.

The TLS mode of all Gateways in the cluster can be detected with the following command:

    $ kubectl get gateways.networking.istio.io -A -o "custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,TLS_MODE:.spec.servers[*].tls.mode"
    

If the output shows any AUTO_PASSTHROUGH Gateways, you may be impacted.

**Mitigation**

Update your cluster to the latest supported version:

*   Istio 1.8.6, if using 1.8.x
*   Istio 1.9.5 or up
*   The patch version specified by your cloud provider

**Credit**

We would like to thank John Howard (Google) for reporting this issue.

ISTIO-SECURITY-2021-005

ISTIO-SECURITY-2021-003

CVE-2021-31921: ISTIO-SECURITY-2021-006

The Funnel Builder by CartFlows â€“ Create High Converting Sales Funnels For WordPress plugin before 1.6.13 did not sanitise its facebook_pixel_id and google_analytics_id settings, allowing high privilege users to set XSS payload in them, which will either be executed on pages generated by the plugin, or the whole website depending on the settings used.

CVE-2021-24330

XStream is software for serializing Java objects to XML and back again. A vulnerability in XStream versions prior to 1.4.17 may allow a remote attacker has sufficient rights to execute commands of the host only by manipulating the processed input stream. No user who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types is affected. The vulnerability is patched in version 1.4.17.

**Impact**

The vulnerability may allow a remote attacker has sufficient rights to execute commands of the host only by manipulating the processed input stream. No user is affected, who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types.

**Patches**

If you rely on XStream's default blacklist of the Security Framework, you will have to use at least version 1.4.17.

**Workarounds**

See workarounds for the different versions covering all CVEs.

**References**

See full information about the nature of the vulnerability and the steps to reproduce it in XStream's documentation for CVE-2021-29505.

**Credits**

V3geB1rd, white hat hacker from Tencent Security Response Center found and reported the issue to XStream and provided the required information to reproduce it.

**For more information**

If you have any questions or comments about this advisory:

*   Open an issue in XStream
*   Email us at XStream Google Group

CVE-2021-29505: Build software better, together

net/http in Go before 1.15.12 and 1.16.x before 1.16.4 allows remote attackers to cause a denial of service (panic) via a large header to ReadRequest or ReadResponse. Server, Transport, and Client can each be affected in some configurations.

**Comments**

 odeke-em changed the title http: ReadRequest can stack overflow net/http: ReadRequest can stack overflow due to recursion with very large headers

Apr 23, 2021

 dmitshur added the NeedsFix

The path to resolution is known, but the work has not been done.

label

Apr 28, 2021

gopherbot pushed a commit to golang/net that referenced this issue

Apr 28, 2021

…aderValuesContainsToken

Previously, httpguts.HeaderValuesContainsToken called a
function which could recurse to the point of a stack
overflow when given a very large header (~10MB).

Credit to Guido Vranken who reported the crash as
part of the Ethereum 2.0 bounty program.

Fixes CVE-2021-31525

Updates golang/go#45710
Updates golang/go#45712

Change-Id: I2c54ce3b2acf1c5efdea66db0595b93a3f5ae5f3
Reviewed-on: https://go-review.googlesource.com/c/net/+/313069
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
(cherry picked from commit 89ef3d9)
Reviewed-on: https://go-review.googlesource.com/c/net/+/314649
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

gopherbot pushed a commit to golang/net that referenced this issue

Apr 28, 2021

…esContainsToken

Previously, httpguts.HeaderValuesContainsToken called a
function which could recurse to the point of a stack
overflow when given a very large header (~10MB).

Credit to Guido Vranken who reported the crash as
part of the Ethereum 2.0 bounty program.

Fixes CVE-2021-31525

Updates golang/go#45710
Updates golang/go#45711

Change-Id: I2c54ce3b2acf1c5efdea66db0595b93a3f5ae5f3
Reviewed-on: https://go-review.googlesource.com/c/net/+/313069
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
(cherry picked from commit 89ef3d9)
Reviewed-on: https://go-review.googlesource.com/c/net/+/314650
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

This was referenced

May 6, 2021

AkihiroSuda pushed a commit to containerd/containerd that referenced this issue

May 7, 2021

buildroot-auto-update pushed a commit to buildroot/buildroot that referenced this issue

May 8, 2021

Fixes the following security issues:

- CVE-2021-31525: ReadRequest and ReadResponse in net/http can hit an
  unrecoverable panic when reading a very large header (over 7MB on 64-bit
  architectures, or over 4MB on 32-bit ones).  Transport and Client are
  vulnerable and the program can be made to crash by a malicious server.
  Server is not vulnerable by default, but can be if the default max header
  of 1MB is overridden by setting Server.MaxHeaderBytes to a higher value,
  in which case the program can be made to crash by a malicious client.

  golang/go#45710

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

buildroot-auto-update pushed a commit to buildroot/buildroot that referenced this issue

May 8, 2021

Fixes the following security issues:

- CVE-2021-31525: ReadRequest and ReadResponse in net/http can hit an
  unrecoverable panic when reading a very large header (over 7MB on 64-bit
  architectures, or over 4MB on 32-bit ones).  Transport and Client are
  vulnerable and the program can be made to crash by a malicious server.
  Server is not vulnerable by default, but can be if the default max header
  of 1MB is overridden by setting Server.MaxHeaderBytes to a higher value,
  in which case the program can be made to crash by a malicious client.

  golang/go#45710

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

dmcgowan pushed a commit to dmcgowan/containerd that referenced this issue

May 10, 2021

 

fix \[#45710\](golang/go#45710) and CVE-2021-31525.

Signed-off-by: Jintao Zhang <zhangjintao9020@gmail.com>
(cherry picked from commit 79d800b)
Signed-off-by: Derek McGowan <derek@mcg.dev>

olix0r added a commit to linkerd/linkerd2 that referenced this issue

May 24, 2021

Go 1.16.4 includes a fix for a denial-of-service in net/http: golang/go#45710

Go's error file-line formatting changed in 1.16.3, so this change
updates tests to only do suffix matching on these error strings.

olix0r added a commit to linkerd/linkerd2 that referenced this issue

May 24, 2021

Go 1.16.4 includes a fix for a denial-of-service in net/http: golang/go#45710

Go's error file-line formatting changed in 1.16.3, so this change
updates tests to only do suffix matching on these error strings.

buildroot-auto-update pushed a commit to buildroot/buildroot that referenced this issue

Sep 14, 2021

Fixes the following security issues:

- CVE-2021-31525: ReadRequest and ReadResponse in net/http can hit an
  unrecoverable panic when reading a very large header (over 7MB on 64-bit
  architectures, or over 4MB on 32-bit ones).  Transport and Client are
  vulnerable and the program can be made to crash by a malicious server.
  Server is not vulnerable by default, but can be if the default max header
  of 1MB is overridden by setting Server.MaxHeaderBytes to a higher value,
  in which case the program can be made to crash by a malicious client.

  golang/go#45710

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 1cfc01a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

thaJeztah pushed a commit to thaJeztah/containerd that referenced this issue

Sep 15, 2021

 

fix \[#45710\](golang/go#45710) and CVE-2021-31525.

Signed-off-by: Jintao Zhang <zhangjintao9020@gmail.com>
(cherry picked from commit 79d800b)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

fahedouch pushed a commit to fahedouch/containerd that referenced this issue

Oct 15, 2021

 

 golang locked and limited conversation to collaborators

May 10, 2022

CVE-2021-31525: net/http: ReadRequest can stack overflow due to recursion with very large headers · Issue #45710 · golang/go

**Comments**

![@katiehockman](https://avatars.githubusercontent.com/u/28789760?s=88&u=e2750425c681d9ecc2cf44f67e82d8a7e861ad3b&v=4)

![@odeke-em](https://avatars.githubusercontent.com/u/4898263?s=60&u=71396c0dd79a0f55328aa0781c13ca5d940e6af3&v=4) odeke-em changed the title http: ReadRequest can stack overflow net/http: ReadRequest can stack overflow due to recursion with very large headers

Apr 23, 2021

gopherbot pushed a commit to golang/net that referenced this issue

Apr 28, 2021

![@katiehockman](https://avatars.githubusercontent.com/u/28789760?s=40&u=e2750425c681d9ecc2cf44f67e82d8a7e861ad3b&v=4)

…aderValuesContainsToken

Previously, httpguts.HeaderValuesContainsToken called a
function which could recurse to the point of a stack
overflow when given a very large header (~10MB).

Credit to Guido Vranken who reported the crash as
part of the Ethereum 2.0 bounty program.

Fixes CVE-2021-31525

Updates golang/go#45710
Updates golang/go#45712

Change-Id: I2c54ce3b2acf1c5efdea66db0595b93a3f5ae5f3
Reviewed-on: https://go-review.googlesource.com/c/net/+/313069
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
(cherry picked from commit 89ef3d9)
Reviewed-on: https://go-review.googlesource.com/c/net/+/314649
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

gopherbot pushed a commit to golang/net that referenced this issue

Apr 28, 2021

![@katiehockman](https://avatars.githubusercontent.com/u/28789760?s=40&u=e2750425c681d9ecc2cf44f67e82d8a7e861ad3b&v=4)

…esContainsToken

Previously, httpguts.HeaderValuesContainsToken called a
function which could recurse to the point of a stack
overflow when given a very large header (~10MB).

Credit to Guido Vranken who reported the crash as
part of the Ethereum 2.0 bounty program.

Fixes CVE-2021-31525

Updates golang/go#45710
Updates golang/go#45711

Change-Id: I2c54ce3b2acf1c5efdea66db0595b93a3f5ae5f3
Reviewed-on: https://go-review.googlesource.com/c/net/+/313069
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
(cherry picked from commit 89ef3d9)
Reviewed-on: https://go-review.googlesource.com/c/net/+/314650
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

AkihiroSuda pushed a commit to containerd/containerd that referenced this issue

May 7, 2021

![@tao12345666333](https://avatars.githubusercontent.com/u/3264292?s=40&v=4)

fix \[#45710\](golang/go#45710) and CVE-2021-31525.

Signed-off-by: Jintao Zhang <zhangjintao9020@gmail.com>

buildroot-auto-update pushed a commit to buildroot/buildroot that referenced this issue

May 8, 2021

![@jacmet](https://avatars.githubusercontent.com/u/6599?s=40&u=9fe70d3f87b3e89e02b065a383742e42f37a3e16&v=4)

Fixes the following security issues:

- CVE-2021-31525: ReadRequest and ReadResponse in net/http can hit an
  unrecoverable panic when reading a very large header (over 7MB on 64-bit
  architectures, or over 4MB on 32-bit ones).  Transport and Client are
  vulnerable and the program can be made to crash by a malicious server.
  Server is not vulnerable by default, but can be if the default max header
  of 1MB is overridden by setting Server.MaxHeaderBytes to a higher value,
  in which case the program can be made to crash by a malicious client.

  golang/go#45710

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

buildroot-auto-update pushed a commit to buildroot/buildroot that referenced this issue

May 8, 2021

![@jacmet](https://avatars.githubusercontent.com/u/6599?s=40&u=9fe70d3f87b3e89e02b065a383742e42f37a3e16&v=4)

Fixes the following security issues:

- CVE-2021-31525: ReadRequest and ReadResponse in net/http can hit an
  unrecoverable panic when reading a very large header (over 7MB on 64-bit
  architectures, or over 4MB on 32-bit ones).  Transport and Client are
  vulnerable and the program can be made to crash by a malicious server.
  Server is not vulnerable by default, but can be if the default max header
  of 1MB is overridden by setting Server.MaxHeaderBytes to a higher value,
  in which case the program can be made to crash by a malicious client.

  golang/go#45710

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

dmcgowan pushed a commit to dmcgowan/containerd that referenced this issue

May 10, 2021

 ![@tao12345666333](https://avatars.githubusercontent.com/u/3264292?s=40&v=4)![@dmcgowan](https://avatars.githubusercontent.com/u/169601?s=40&v=4)

fix \[#45710\](golang/go#45710) and CVE-2021-31525.

Signed-off-by: Jintao Zhang <zhangjintao9020@gmail.com>
(cherry picked from commit 79d800b)
Signed-off-by: Derek McGowan <derek@mcg.dev>

olix0r added a commit to linkerd/linkerd2 that referenced this issue

May 24, 2021

![@olix0r](https://avatars.githubusercontent.com/u/240738?s=40&u=93d91af656d51c5ae35f757a4e36c6ad8bb94866&v=4)

Go 1.16.4 includes a fix for a denial-of-service in net/http: golang/go#45710

Go's error file-line formatting changed in 1.16.3, so this change
updates tests to only do suffix matching on these error strings.

olix0r added a commit to linkerd/linkerd2 that referenced this issue

May 24, 2021

![@olix0r](https://avatars.githubusercontent.com/u/240738?s=40&u=93d91af656d51c5ae35f757a4e36c6ad8bb94866&v=4)

Go 1.16.4 includes a fix for a denial-of-service in net/http: golang/go#45710

Go's error file-line formatting changed in 1.16.3, so this change
updates tests to only do suffix matching on these error strings.

buildroot-auto-update pushed a commit to buildroot/buildroot that referenced this issue

Sep 14, 2021

![@jacmet](https://avatars.githubusercontent.com/u/6599?s=40&u=9fe70d3f87b3e89e02b065a383742e42f37a3e16&v=4)

Fixes the following security issues:

- CVE-2021-31525: ReadRequest and ReadResponse in net/http can hit an
  unrecoverable panic when reading a very large header (over 7MB on 64-bit
  architectures, or over 4MB on 32-bit ones).  Transport and Client are
  vulnerable and the program can be made to crash by a malicious server.
  Server is not vulnerable by default, but can be if the default max header
  of 1MB is overridden by setting Server.MaxHeaderBytes to a higher value,
  in which case the program can be made to crash by a malicious client.

  golang/go#45710

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 1cfc01a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

thaJeztah pushed a commit to thaJeztah/containerd that referenced this issue

Sep 15, 2021

 ![@tao12345666333](https://avatars.githubusercontent.com/u/3264292?s=40&v=4)![@thaJeztah](https://avatars.githubusercontent.com/u/1804568?s=40&v=4)

fix \[#45710\](golang/go#45710) and CVE-2021-31525.

Signed-off-by: Jintao Zhang <zhangjintao9020@gmail.com>
(cherry picked from commit 79d800b)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

fahedouch pushed a commit to fahedouch/containerd that referenced this issue

Oct 15, 2021

 ![@tao12345666333](https://avatars.githubusercontent.com/u/3264292?s=40&v=4)![@fahedouch](https://avatars.githubusercontent.com/u/11649303?s=40&v=4)

fix \[#45710\](golang/go#45710) and CVE-2021-31525.

Signed-off-by: Jintao Zhang <zhangjintao9020@gmail.com>

NET12115 added a commit to NET12115/Golang-C-NET that referenced this issue

Feb 28, 2022

![@NET12115](https://avatars.githubusercontent.com/u/88066112?s=40&u=01910a2b4d14b02d9d3ef852f6d47aeb61f9ecf0&v=4)

Previously, httpguts.HeaderValuesContainsToken called a
function which could recurse to the point of a stack
overflow when given a very large header (~10MB).

Credit to Guido Vranken who reported the crash as
part of the Ethereum 2.0 bounty program.

Fixes CVE-2021-31525

Fixes golang/go#45710

Change-Id: I2c54ce3b2acf1c5efdea66db0595b93a3f5ae5f3
Reviewed-on: https://go-review.googlesource.com/c/net/+/313069
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>

golang.org/x/net before v0.0.0-20210520170846-37e1c6afe023 allows attackers to cause a denial of service (infinite loop) via crafted ParseFragment input.

**Filippo Valsorda**

unread,

May 20, 2021, 7:24:58 PM5/20/21

to golang-nuts, golang-...@googlegroups.com, golang-dev

Hello gophers,

Version v0.0.0-20210520170846-37e1c6afe023 of golang.org/x/net fixes a vulnerability in the golang.org/x/net/html package which could cause a denial of service.

An attacker can craft an input to ParseFragment that would cause it to enter an infinite loop and never return.

This issue was discovered by OSS-Fuzz and reported to us by Andrew Thornton <ar...@cantab.net\>, and is tracked as CVE-2021-33194.

Cheers,  
Filippo on behalf of the Go team

CVE-2021-33194: [security] Vulnerability in golang.org/x/net/html

A flaw was found in libwebp in versions before 1.0.1. An out-of-bounds read was found in function ShiftBytes. The highest threat from this vulnerability is to data confidentiality and to the service availability.

*   
*   
*   
*   
*   
*   

**Bug 1956926** (CVE-2018-25013) - CVE-2018-25013 libwebp: out-of-bounds read in ShiftBytes()

Summary: CVE-2018-25013 libwebp: out-of-bounds read in ShiftBytes()

Keywords:

Status:

CLOSED ERRATA

Alias:

CVE-2018-25013

Product:

Security Response

Classification:

Other

Component:

vulnerability

Sub Component:

Version:

unspecified

Hardware:

All

OS:

Linux

Priority:

medium

Severity:

medium

Target Milestone:

\---

Assignee:

Red Hat Product Security

QA Contact:

Docs Contact:

URL:

Whiteboard:

Depends On:

1961978 1961979 1962004 1962005 1961611 1961612

Blocks:

1940150 1956995

TreeView+

depends on / blocked

Reported:

2021-05-04 16:44 UTC by Guilherme de Almeida Suckevicz

Modified:

2021-11-10 01:54 UTC (History)

CC List:

9 users (show)

Fixed In Version:

libwebp 1.0.1

Doc Type:

If docs needed, set a value

Doc Text:

A flaw was found in libwebp. An out-of-bounds read was found in function ShiftBytes. The highest threat from this vulnerability is to data confidentiality and to the service availability.

Clone Of:

Environment:

Last Closed:

2021-11-10 01:54:11 UTC

  

Attachments

(Terms of Use)

Add an attachment (proposed patch, testcase, etc.)

Links

System

ID

Private

Priority

Status

Summary

Last Updated

Red Hat Product Errata

RHSA-2021:4231

0

None

None

None

2021-11-09 17:50:34 UTC

  

Description Guilherme de Almeida Suckevicz 2021-05-04 16:44:45 UTC

A heap-based buffer overflow was found in libwebp in versions before 1.0.1 in ShiftBytes().

Reference:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9417

Comment 1 Riccardo Schirone 2021-05-18 10:59:33 UTC

Upstream patch:
https://chromium.googlesource.com/webm/libwebp/+/907208f97ead639bd521cf355a2f203f462eade6

Comment 7 errata-xmlrpc 2021-11-09 17:50:33 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2021:4231 https://access.redhat.com/errata/RHSA-2021:4231

Comment 8 Product Security DevOps Team 2021-11-10 01:54:09 UTC

This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2018-25013

Note You need to log in before you can comment on or make changes to this bug.

*   
*   
*   
*   
*   
*

CVE-2018-25013: 1956926 – (CVE-2018-25013) CVE-2018-25013 libwebp: out-of-bounds read in ShiftBytes()

A flaw was found in libwebp in versions before 1.0.1. A use-after-free was found due to a thread being killed too early. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

Description Guilherme de Almeida Suckevicz 2021-05-04 14:18:22 UTC

An use-after-free was found in libwebp in versions before 1.0.1 in EmitFancyRGB() in dec/io\_dec.c.

Reference:
https://bugs.chromium.org/p/webp/issues/detail?id=385

Comment 1 Riccardo Schirone 2021-05-13 10:55:14 UTC

Upstream patch:
https://chromium.googlesource.com/webm/libwebp/+/569001f19fc81fcb5ab358f587a54c62e7c4665c

Comment 4 Riccardo Schirone 2021-05-17 10:47:46 UTC

Upstream release notes:
https://chromium.googlesource.com/webm/libwebp/+/v1.0.1

Comment 9 errata-xmlrpc 2021-06-07 12:18:12 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2021:2260 https://access.redhat.com/errata/RHSA-2021:2260

Comment 10 Product Security DevOps Team 2021-06-07 15:04:00 UTC

This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2020-36329

Comment 11 errata-xmlrpc 2021-06-08 22:38:17 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2021:2328 https://access.redhat.com/errata/RHSA-2021:2328

Comment 12 errata-xmlrpc 2021-06-09 00:25:45 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2021:2354 https://access.redhat.com/errata/RHSA-2021:2354

Comment 13 errata-xmlrpc 2021-06-09 13:32:25 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.1 Extended Update Support

Via RHSA-2021:2365 https://access.redhat.com/errata/RHSA-2021:2365

Comment 14 errata-xmlrpc 2021-06-09 13:51:01 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.2 Extended Update Support

Via RHSA-2021:2364 https://access.redhat.com/errata/RHSA-2021:2364

CVE-2020-36329: use-after-free in EmitFancyRGB() in dec/io_dec.c

A flaw was found in libwebp in versions before 1.0.1. A heap-based buffer overflow in function WebPDecodeRGBInto is possible due to an invalid check for buffer size. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

Description Guilherme de Almeida Suckevicz 2021-05-04 13:59:01 UTC

A heap-based buffer overflow was found in libwebp in versions before 1.0.1 in WebPDecode\*Into functions.

Reference:
https://bugs.chromium.org/p/webp/issues/detail?id=383

Comment 1 Riccardo Schirone 2021-05-13 10:38:02 UTC

Upstream patch:
https://chromium.googlesource.com/webm/libwebp/+/dad31750e374eff8e02fb467eb562d4bf236ed6e

Comment 5 Riccardo Schirone 2021-05-17 10:47:48 UTC

Upstream release notes:
https://chromium.googlesource.com/webm/libwebp/+/v1.0.1

Comment 10 errata-xmlrpc 2021-06-07 12:18:13 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2021:2260 https://access.redhat.com/errata/RHSA-2021:2260

Comment 11 Product Security DevOps Team 2021-06-07 15:03:56 UTC

This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2020-36328

Comment 12 errata-xmlrpc 2021-06-08 22:38:15 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2021:2328 https://access.redhat.com/errata/RHSA-2021:2328

Comment 13 errata-xmlrpc 2021-06-09 00:25:45 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2021:2354 https://access.redhat.com/errata/RHSA-2021:2354

Comment 14 errata-xmlrpc 2021-06-09 13:32:24 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.1 Extended Update Support

Via RHSA-2021:2365 https://access.redhat.com/errata/RHSA-2021:2365

Comment 15 errata-xmlrpc 2021-06-09 13:51:00 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.2 Extended Update Support

Via RHSA-2021:2364 https://access.redhat.com/errata/RHSA-2021:2364

Tag

#google