CVE-2022-41725

Source
https://nvd.nist.gov/vuln/detail/CVE-2022-41725
Import Source
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2022-41725.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2022-41725
Aliases
Related
Published
2023-02-28T18:15:10Z
Modified
2024-09-18T03:22:36.401997Z
Severity
  • 7.5 (High) CVSS_V3 - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H CVSS Calculator
Summary
[none]
Details

A denial of service is possible from excessive resource consumption in net/http and mime/multipart. Multipart form parsing with mime/multipart.Reader.ReadForm can consume largely unlimited amounts of memory and disk files. This also affects form parsing in the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. ReadForm takes a maxMemory parameter, and is documented as storing "up to maxMemory bytes +10MB (reserved for non-file parts) in memory". File parts which cannot be stored in memory are stored on disk in temporary files. The unconfigurable 10MB reserved for non-file parts is excessively large and can potentially open a denial of service vector on its own. However, ReadForm did not properly account for all memory consumed by a parsed form, such as map entry overhead, part names, and MIME headers, permitting a maliciously crafted form to consume well over 10MB. In addition, ReadForm contained no limit on the number of disk files created, permitting a relatively small request body to create a large number of disk temporary files. With fix, ReadForm now properly accounts for various forms of memory overhead, and should now stay within its documented limit of 10MB + maxMemory bytes of memory consumption. Users should still be aware that this limit is high and may still be hazardous. In addition, ReadForm now creates at most one on-disk temporary file, combining multiple form parts into a single temporary file. The mime/multipart.File interface type's documentation states, "If stored on disk, the File's underlying concrete type will be an *os.File.". This is no longer the case when a form contains more than one file part, due to this coalescing of parts into a single file. The previous behavior of using distinct files for each form part may be reenabled with the environment variable GODEBUG=multipartfiles=distinct. Users should be aware that multipart.ReadForm and the http.Request methods that call it do not limit the amount of disk consumed by temporary files. Callers can limit the size of form data with http.MaxBytesReader.

References

Affected packages

Debian:11 / golang-1.15

Package

Name
golang-1.15
Purl
pkg:deb/debian/golang-1.15?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected

Affected versions

1.*

1.15.9-6
1.15.15-1~deb11u1
1.15.15-1~deb11u2
1.15.15-1~deb11u3
1.15.15-1~deb11u4
1.15.15-1
1.15.15-2
1.15.15-3
1.15.15-4
1.15.15-5

Ecosystem specific

{
    "urgency": "not yet assigned"
}

Debian:12 / golang-1.19

Package

Name
golang-1.19
Purl
pkg:deb/debian/golang-1.19?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
1.19.6-2

Ecosystem specific

{
    "urgency": "not yet assigned"
}

Git / github.com/golang/go

Affected ranges

Type
GIT
Repo
https://github.com/golang/go
Events
Introduced
0 Unknown introduced commit / All previous commits are affected
Fixed

Affected versions

go1.*

go1.10beta1
go1.10beta2
go1.10rc1
go1.10rc2
go1.11beta1
go1.11beta2
go1.11beta3
go1.12beta1
go1.12beta2
go1.13beta1
go1.14beta1
go1.15beta1
go1.16beta1
go1.17beta1
go1.18beta1
go1.18beta2
go1.19
go1.19.1
go1.19.2
go1.19.3
go1.19.4
go1.19.5
go1.19beta1
go1.19rc1
go1.19rc2
go1.3beta1
go1.3beta2
go1.4beta1
go1.5beta1
go1.5beta2
go1.5beta3
go1.6beta1
go1.6beta2
go1.7beta1
go1.7beta2
go1.7rc1
go1.7rc2
go1.7rc3
go1.7rc4
go1.8beta1
go1.8beta2
go1.9
go1.9.1
go1.9.2
go1.9beta1
go1.9beta2
go1.9rc1
go1.9rc2

release.*

release.r56

Other

weekly

weekly.*

weekly.2009-11-06
weekly.2009-11-10
weekly.2009-11-10.1
weekly.2009-11-12
weekly.2009-11-17
weekly.2009-12-07
weekly.2009-12-09
weekly.2009-12-22
weekly.2010-01-05
weekly.2010-01-13
weekly.2010-01-27
weekly.2010-02-04
weekly.2010-02-17
weekly.2010-02-23
weekly.2010-03-04
weekly.2010-03-15
weekly.2010-03-22
weekly.2010-03-30
weekly.2010-04-13
weekly.2010-04-27
weekly.2010-05-04
weekly.2010-05-27
weekly.2010-06-09
weekly.2010-06-21
weekly.2010-07-01
weekly.2010-07-14
weekly.2010-07-29
weekly.2010-08-04
weekly.2010-08-11
weekly.2010-08-25
weekly.2010-09-06
weekly.2010-09-15
weekly.2010-09-22
weekly.2010-09-29
weekly.2010-10-13
weekly.2010-10-13.1
weekly.2010-10-20
weekly.2010-10-27
weekly.2010-11-02
weekly.2010-11-10
weekly.2010-11-23
weekly.2010-12-02
weekly.2010-12-08
weekly.2010-12-15
weekly.2010-12-15.1
weekly.2010-12-22
weekly.2011-01-06
weekly.2011-01-12
weekly.2011-01-19
weekly.2011-01-20
weekly.2011-02-01
weekly.2011-02-01.1
weekly.2011-02-15
weekly.2011-02-24
weekly.2011-03-07
weekly.2011-03-07.1
weekly.2011-03-15
weekly.2011-03-28
weekly.2011-04-04
weekly.2011-04-13
weekly.2011-04-27
weekly.2011-05-22
weekly.2011-06-02
weekly.2011-06-09
weekly.2011-06-16
weekly.2011-06-23
weekly.2011-07-07
weekly.2011-07-19
weekly.2011-07-29
weekly.2011-08-10
weekly.2011-08-17
weekly.2011-09-01
weekly.2011-09-07
weekly.2011-09-16
weekly.2011-09-21
weekly.2011-10-06
weekly.2011-10-18
weekly.2011-10-25
weekly.2011-10-26
weekly.2011-11-01
weekly.2011-11-02
weekly.2011-11-08
weekly.2011-11-09
weekly.2011-11-18
weekly.2011-12-01
weekly.2011-12-02
weekly.2011-12-06
weekly.2011-12-14
weekly.2011-12-22
weekly.2012-01-15
weekly.2012-01-20
weekly.2012-01-27
weekly.2012-02-07
weekly.2012-02-14
weekly.2012-02-22
weekly.2012-03-04
weekly.2012-03-13
weekly.2012-03-22
weekly.2012-03-27