Common Weakness Enumeration
CWE-772
AllowedMissing Release of Resource after Effective Lifetime
Abstraction: Base · Status: Draft
The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
638 vulnerabilities reference this CWE, most recent first.
GHSA-RGV6-WVJ7-CVXV
Vulnerability from github – Published: 2022-05-13 01:47 – Updated: 2022-05-13 01:47
VLAI
Details
In ImageMagick 7.0.5-5, the ReadMPCImage function in mpc.c allows attackers to cause a denial of service (memory leak) via a crafted file.
Severity
6.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2017-9409"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-06-02T19:29:00Z",
"severity": "MODERATE"
},
"details": "In ImageMagick 7.0.5-5, the ReadMPCImage function in mpc.c allows attackers to cause a denial of service (memory leak) via a crafted file.",
"id": "GHSA-rgv6-wvj7-cvxv",
"modified": "2022-05-13T01:47:58Z",
"published": "2022-05-13T01:47:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-9409"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/issues/458"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-RMP9-HJ82-J8Q4
Vulnerability from github – Published: 2022-05-24 17:26 – Updated: 2022-05-24 17:26
VLAI
Details
In BIG-IP APM versions 12.1.0-12.1.5.1 and 11.6.1-11.6.5.2, RADIUS authentication leaks memory when the username for authentication is not set.
{
"affected": [],
"aliases": [
"CVE-2020-5924"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-08-26T15:15:00Z",
"severity": "MODERATE"
},
"details": "In BIG-IP APM versions 12.1.0-12.1.5.1 and 11.6.1-11.6.5.2, RADIUS authentication leaks memory when the username for authentication is not set.",
"id": "GHSA-rmp9-hj82-j8q4",
"modified": "2022-05-24T17:26:47Z",
"published": "2022-05-24T17:26:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5924"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K11400411"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-RP76-R8P6-JH5J
Vulnerability from github – Published: 2022-05-13 01:47 – Updated: 2022-05-13 01:47
VLAI
Details
In ImageMagick 7.0.5-5, the ReadICONImage function in icon.c:452 allows attackers to cause a denial of service (memory leak) via a crafted file.
Severity
6.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2017-9405"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-06-02T19:29:00Z",
"severity": "MODERATE"
},
"details": "In ImageMagick 7.0.5-5, the ReadICONImage function in icon.c:452 allows attackers to cause a denial of service (memory leak) via a crafted file.",
"id": "GHSA-rp76-r8p6-jh5j",
"modified": "2022-05-13T01:47:59Z",
"published": "2022-05-13T01:47:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-9405"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/issues/457"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-RP9V-7XV3-R6G3
Vulnerability from github – Published: 2026-10-08 17:52 – Updated: 2026-10-09 17:41
VLAI
Summary
Coraza: Resource exhaustion via deferred file handle accumulation in multipart body processor
Details
Summary
defer temp.Close() sits inside a for loop in the multipart processor. Go defers run at function return, not loop end, so every file part in the request holds an open fd until ProcessRequest() exits. Send enough parts and you hit EMFILE. With CRS loaded, that flips MULTIPART_STRICT_ERROR to 1 and rule 200001 starts returning 400s, including on legitimate requests hitting the same condition.
Details
internal/bodyprocessors/multipart.go, line 69:
for {
p, err := mr.NextPart()
// ...
temp, err := os.CreateTemp(storagePath, "crzmp*")
defer temp.Close() // wrong scope
io.Copy(temp, p)
}
Each iteration opens a temp file and defers its close. All of them stack up and fire together when ProcessRequest returns. 500 parts, 500 fds held simultaneously.
The body size limit (default 128MB) caps total bytes, not part count. A minimal file part (boundary line, Content-Disposition with filename=, one byte of content) is about 104 bytes. That's roughly 65,000 parts per 6.8MB of body, which on a standard Linux system (hard fd limit 65536) is enough to exhaust the table.
Fix is straightforward: call temp.Close() explicitly after io.Copy instead of deferring it.
PoC
Tested on v3.7.0 (db9850b), Go 1.25, Linux x86_64.
Add this file at internal/bodyprocessors/poc_fd_test.go and run:
go test -v -run TestMultipartFDLeak ./internal/bodyprocessors/...
package bodyprocessors_test
import (
"fmt"
"os"
"strings"
"sync"
"sync/atomic"
"testing"
"github.com/corazawaf/coraza/v3/experimental/plugins/plugintypes"
"github.com/corazawaf/coraza/v3/internal/bodyprocessors"
"github.com/corazawaf/coraza/v3/internal/corazawaf"
)
func countFDs() int {
e, _ := os.ReadDir("/proc/self/fd")
return len(e)
}
func TestMultipartFDLeak(t *testing.T) {
boundary := "testboundary"
var sb strings.Builder
for i := 0; i < 500; i++ {
fmt.Fprintf(&sb, "--%s\r\n", boundary)
fmt.Fprintf(&sb, "Content-Disposition: form-data; name=\"f%d\"; filename=\"f%d.txt\"\r\n", i, i)
sb.WriteString("\r\n")
sb.WriteString("X\r\n")
}
fmt.Fprintf(&sb, "--%s--\r\n", boundary)
mp, _ := bodyprocessors.GetBodyProcessor("multipart")
baseline := countFDs()
var peak int64
done := make(chan struct{})
var wg sync.WaitGroup
wg.Add(1)
go func() {
defer wg.Done()
for {
select {
case <-done:
return
default:
n := int64(countFDs())
for {
cur := atomic.LoadInt64(&peak)
if n <= cur || atomic.CompareAndSwapInt64(&peak, cur, n) {
break
}
}
}
}
}()
v := corazawaf.NewTransactionVariables()
mp.ProcessRequest(strings.NewReader(sb.String()), v,
plugintypes.BodyProcessorOptions{
Mime: "multipart/form-data; boundary=" + boundary,
StoragePath: t.TempDir(),
})
close(done)
wg.Wait()
t.Logf("baseline=%d peak=%d spike=+%d",
baseline, atomic.LoadInt64(&peak),
atomic.LoadInt64(&peak)-int64(baseline))
}
Output:
baseline=7 peak=506 spike=+499
The spike is ~1 fd per part. After ProcessRequest returns the deferred closes fire and it drops back to baseline.
Impact
- No authentication required. Any endpoint that accepts multipart uploads is affected.
- fd exhaustion at ~6.8MB body (~65k parts).
os.CreateTempstarts returning errors andMULTIPART_STRICT_ERRORis set to 1. - CRS false positives / DoS. With CRS loaded, rule
200001then blocks the request with a 400 — and any other multipart request processed concurrently that runs into the same condition gets blocked too. At that point the WAF can't distinguish the attack from a legitimate upload. - Process-wide impact. While the fd table is full the process can't open sockets or files for anything else either.
- Scope. Affects all v3.x releases; the
deferhas been present since the multipart processor was introduced.
Severity
5.3 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/corazawaf/coraza/v3"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.8.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-107834"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-772"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-08T17:52:00Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\n`defer temp.Close()` sits inside a `for` loop in the multipart processor. Go defers run at function return, not loop end, so every file part in the request holds an open fd until `ProcessRequest()` exits. Send enough parts and you hit `EMFILE`. With CRS loaded, that flips `MULTIPART_STRICT_ERROR` to 1 and rule `200001` starts returning 400s, including on legitimate requests hitting the same condition.\n\n## Details\n\n`internal/bodyprocessors/multipart.go`, line 69:\n\n```go\nfor {\n p, err := mr.NextPart()\n // ...\n temp, err := os.CreateTemp(storagePath, \"crzmp*\")\n defer temp.Close() // wrong scope\n io.Copy(temp, p)\n}\n```\n\nEach iteration opens a temp file and defers its close. All of them stack up and fire together when `ProcessRequest` returns. 500 parts, 500 fds held simultaneously.\n\nThe body size limit (default 128MB) caps total bytes, not part count. A minimal file part (boundary line, `Content-Disposition` with `filename=`, one byte of content) is about 104 bytes. That\u0027s roughly 65,000 parts per 6.8MB of body, which on a standard Linux system (hard fd limit 65536) is enough to exhaust the table.\n\nFix is straightforward: call `temp.Close()` explicitly after `io.Copy` instead of deferring it.\n\n## PoC\n\nTested on v3.7.0 (`db9850b`), Go 1.25, Linux x86_64.\n\nAdd this file at `internal/bodyprocessors/poc_fd_test.go` and run:\n\n```text\ngo test -v -run TestMultipartFDLeak ./internal/bodyprocessors/...\n```\n\n```go\npackage bodyprocessors_test\n\nimport (\n\t\"fmt\"\n\t\"os\"\n\t\"strings\"\n\t\"sync\"\n\t\"sync/atomic\"\n\t\"testing\"\n\n\t\"github.com/corazawaf/coraza/v3/experimental/plugins/plugintypes\"\n\t\"github.com/corazawaf/coraza/v3/internal/bodyprocessors\"\n\t\"github.com/corazawaf/coraza/v3/internal/corazawaf\"\n)\n\nfunc countFDs() int {\n\te, _ := os.ReadDir(\"/proc/self/fd\")\n\treturn len(e)\n}\n\nfunc TestMultipartFDLeak(t *testing.T) {\n\tboundary := \"testboundary\"\n\tvar sb strings.Builder\n\tfor i := 0; i \u003c 500; i++ {\n\t\tfmt.Fprintf(\u0026sb, \"--%s\\r\\n\", boundary)\n\t\tfmt.Fprintf(\u0026sb, \"Content-Disposition: form-data; name=\\\"f%d\\\"; filename=\\\"f%d.txt\\\"\\r\\n\", i, i)\n\t\tsb.WriteString(\"\\r\\n\")\n\t\tsb.WriteString(\"X\\r\\n\")\n\t}\n\tfmt.Fprintf(\u0026sb, \"--%s--\\r\\n\", boundary)\n\n\tmp, _ := bodyprocessors.GetBodyProcessor(\"multipart\")\n\tbaseline := countFDs()\n\n\tvar peak int64\n\tdone := make(chan struct{})\n\tvar wg sync.WaitGroup\n\twg.Add(1)\n\tgo func() {\n\t\tdefer wg.Done()\n\t\tfor {\n\t\t\tselect {\n\t\t\tcase \u003c-done:\n\t\t\t\treturn\n\t\t\tdefault:\n\t\t\t\tn := int64(countFDs())\n\t\t\t\tfor {\n\t\t\t\t\tcur := atomic.LoadInt64(\u0026peak)\n\t\t\t\t\tif n \u003c= cur || atomic.CompareAndSwapInt64(\u0026peak, cur, n) {\n\t\t\t\t\t\tbreak\n\t\t\t\t\t}\n\t\t\t\t}\n\t\t\t}\n\t\t}\n\t}()\n\n\tv := corazawaf.NewTransactionVariables()\n\tmp.ProcessRequest(strings.NewReader(sb.String()), v,\n\t\tplugintypes.BodyProcessorOptions{\n\t\t\tMime: \"multipart/form-data; boundary=\" + boundary,\n\t\t\tStoragePath: t.TempDir(),\n\t\t})\n\tclose(done)\n\twg.Wait()\n\n\tt.Logf(\"baseline=%d peak=%d spike=+%d\",\n\t\tbaseline, atomic.LoadInt64(\u0026peak),\n\t\tatomic.LoadInt64(\u0026peak)-int64(baseline))\n}\n```\n\nOutput:\n\n```text\nbaseline=7 peak=506 spike=+499\n```\n\nThe spike is ~1 fd per part. After `ProcessRequest` returns the deferred closes fire and it drops back to baseline.\n\n## Impact\n\n- **No authentication required.** Any endpoint that accepts multipart uploads is affected.\n- **fd exhaustion at ~6.8MB body (~65k parts).** `os.CreateTemp` starts returning errors and `MULTIPART_STRICT_ERROR` is set to 1.\n- **CRS false positives / DoS.** With CRS loaded, rule `200001` then blocks the request with a 400 \u2014 and any other multipart request processed concurrently that runs into the same condition gets blocked too. At that point the WAF can\u0027t distinguish the attack from a legitimate upload.\n- **Process-wide impact.** While the fd table is full the process can\u0027t open sockets or files for anything else either.\n- **Scope.** Affects all v3.x releases; the `defer` has been present since the multipart processor was introduced.",
"id": "GHSA-rp9v-7xv3-r6g3",
"modified": "2026-10-09T17:41:10Z",
"published": "2026-10-08T17:52:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/corazawaf/coraza/security/advisories/GHSA-rp9v-7xv3-r6g3"
},
{
"type": "WEB",
"url": "https://github.com/corazawaf/coraza/commit/1bc39036e99c88e7de60cf8e6bb55ee4c311223c"
},
{
"type": "PACKAGE",
"url": "https://github.com/corazawaf/coraza"
},
{
"type": "WEB",
"url": "https://github.com/corazawaf/coraza/releases/tag/v3.8.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:L",
"type": "CVSS_V3"
}
],
"summary": "Coraza: Resource exhaustion via deferred file handle accumulation in multipart body processor"
}
GHSA-RQMG-XCJ7-66CF
Vulnerability from github – Published: 2022-05-13 01:47 – Updated: 2022-05-13 01:47
VLAI
Details
In ImageMagick 7.0.5-5, the ReadEPTImage function in ept.c allows attackers to cause a denial of service (memory leak) via a crafted file.
Severity
6.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2017-8357"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-04-30T17:59:00Z",
"severity": "MODERATE"
},
"details": "In ImageMagick 7.0.5-5, the ReadEPTImage function in ept.c allows attackers to cause a denial of service (memory leak) via a crafted file.",
"id": "GHSA-rqmg-xcj7-66cf",
"modified": "2022-05-13T01:47:30Z",
"published": "2022-05-13T01:47:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8357"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/issues/453"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2017/dsa-3863"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/98388"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-RQVX-8PR4-6WFH
Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-07-20 15:31
VLAI
Details
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Run queues for all non-SDEV_DEL devices from scsi_run_host_queues
While a SCSI host is in a recovery state, scsi_mq_requeue_cmd() will not set the requeue list for a requeued command to be kicked in the future. The expectation is a call to scsi_run_host_queues() will kick all SCSI devices once the recovery state is cleared.
However, scsi_run_host_queues() uses shost_for_each_device() which uses scsi_device_get() and so will ignore devices in a partially removed state like SDEV_CANCEL. But these devices may also have requeued requests, leaving their requests stuck from not being kicked and causing the removal process of the device to hang.
scsi_run_host_queues() needs to run against more devices than the macro shost_for_each_device() allows. Instead of using the too limiting scsi_device_get() state checks, only ignore devices in SDEV_DEL state or when unable to acquire a reference. Attempt to run the queues for all other devices when scsi_run_host_queues() is called.
Severity
7.5 (High)
{
"affected": [],
"aliases": [
"CVE-2026-64003"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-19T16:17:39Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: core: Run queues for all non-SDEV_DEL devices from scsi_run_host_queues\n\nWhile a SCSI host is in a recovery state, scsi_mq_requeue_cmd() will not\nset the requeue list for a requeued command to be kicked in the future.\nThe expectation is a call to scsi_run_host_queues() will kick all SCSI\ndevices once the recovery state is cleared.\n\nHowever, scsi_run_host_queues() uses shost_for_each_device() which uses\nscsi_device_get() and so will ignore devices in a partially removed\nstate like SDEV_CANCEL. But these devices may also have requeued\nrequests, leaving their requests stuck from not being kicked and causing\nthe removal process of the device to hang.\n\nscsi_run_host_queues() needs to run against more devices than the macro\nshost_for_each_device() allows. Instead of using the too limiting\nscsi_device_get() state checks, only ignore devices in SDEV_DEL state or\nwhen unable to acquire a reference. Attempt to run the queues for all\nother devices when scsi_run_host_queues() is called.",
"id": "GHSA-rqvx-8pr4-6wfh",
"modified": "2026-07-20T15:31:54Z",
"published": "2026-07-19T18:31:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64003"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/15fb19af49f2073ed77fad16aaabc648b0ca6800"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/475f2b37a78f4c698967a7f14f325f04e24c9175"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7205b58702273baf21d6ba7992e6ba15852325f7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c740e13e7fe32d8e4d9a1699f65b8daf6709895a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d4dddfecdbb5467bef158d4e1486459808357fef"
}
],
"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"
}
]
}
GHSA-RR63-XXH8-9RG3
Vulnerability from github – Published: 2022-05-13 01:50 – Updated: 2022-05-13 01:50
VLAI
Details
ImageMagick 7.0.8-5 has a memory leak vulnerability in the function ReadOneJNGImage in coders/png.c.
Severity
6.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2018-16640"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-09-06T22:29:00Z",
"severity": "MODERATE"
},
"details": "ImageMagick 7.0.8-5 has a memory leak vulnerability in the function ReadOneJNGImage in coders/png.c.",
"id": "GHSA-rr63-xxh8-9rg3",
"modified": "2022-05-13T01:50:24Z",
"published": "2022-05-13T01:50:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-16640"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/issues/1201"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/commit/76efa969342568841ecf320b5a041685a6d24e0b"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/3785-1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-RR9P-XG7R-P8XG
Vulnerability from github – Published: 2022-05-13 01:07 – Updated: 2022-05-13 01:07
VLAI
Details
Memory leak in the keyboard input event handlers support in QEMU (aka Quick Emulator) allows local guest OS privileged users to cause a denial of service (host memory consumption) by rapidly generating large keyboard events.
Severity
6.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2017-8379"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-05-23T04:29:00Z",
"severity": "MODERATE"
},
"details": "Memory leak in the keyboard input event handlers support in QEMU (aka Quick Emulator) allows local guest OS privileged users to cause a denial of service (host memory consumption) by rapidly generating large keyboard events.",
"id": "GHSA-rr9p-xg7r-p8xg",
"modified": "2022-05-13T01:07:31Z",
"published": "2022-05-13T01:07:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8379"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:2408"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2018/09/msg00007.html"
},
{
"type": "WEB",
"url": "https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg05599.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201706-03"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2017/05/03/2"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/98277"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-RRRW-3VQX-F9M3
Vulnerability from github – Published: 2022-05-24 17:46 – Updated: 2022-05-24 17:46
VLAI
Details
A memory buffer error vulnerability exists in a component interface of Huawei Smartphone. Local attackers can exploit this vulnerability to cause memory leakage and doS attacks by carefully constructing attack scenarios.
{
"affected": [],
"aliases": [
"CVE-2020-9146"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-01T18:15:00Z",
"severity": "MODERATE"
},
"details": "A memory buffer error vulnerability exists in a component interface of Huawei Smartphone. Local attackers can exploit this vulnerability to cause memory leakage and doS attacks by carefully constructing attack scenarios.",
"id": "GHSA-rrrw-3vqx-f9m3",
"modified": "2022-05-24T17:46:02Z",
"published": "2022-05-24T17:46:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9146"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/cn/support/bulletin/2021/1"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-RVX5-CGPM-65XR
Vulnerability from github – Published: 2022-05-13 01:14 – Updated: 2022-05-13 01:14
VLAI
Details
ImageMagick 7.0.6-2 has a memory leak vulnerability in WriteINLINEImage in coders/inline.c.
Severity
8.8 (High)
{
"affected": [],
"aliases": [
"CVE-2017-12666"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-08-07T21:29:00Z",
"severity": "HIGH"
},
"details": "ImageMagick 7.0.6-2 has a memory leak vulnerability in WriteINLINEImage in coders/inline.c.",
"id": "GHSA-rvx5-cgpm-65xr",
"modified": "2022-05-13T01:14:46Z",
"published": "2022-05-13T01:14:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12666"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/issues/572"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/commit/d5559407ce29f4371e5df9c1cbde65455fe5854c"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/100226"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-3
Requirements
Strategy: Language Selection
- Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, languages such as Java, Ruby, and Lisp perform automatic garbage collection that releases memory for objects that have been deallocated.
Mitigation
Implementation
It is good practice to be responsible for freeing all resources you allocate and to be consistent with how and where you free resources in a function. If you allocate resources that you intend to free upon completion of the function, you must be sure to free the resources at all exit points for that function including error conditions.
Mitigation MIT-47
Operation
Architecture and Design
Strategy: Resource Limitation
- Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.
- When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.
- Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).
CAPEC-469: HTTP DoS
An attacker performs flooding at the HTTP level to bring down only a particular web application rather than anything listening on a TCP/IP connection. This denial of service attack requires substantially fewer packets to be sent which makes DoS harder to detect. This is an equivalent of SYN flood in HTTP. The idea is to keep the HTTP session alive indefinitely and then repeat that hundreds of times. This attack targets resource depletion weaknesses in web server software. The web server will wait to attacker's responses on the initiated HTTP sessions while the connection threads are being exhausted.