Common Weakness Enumeration

CWE-401

Allowed

Missing Release of Memory after Effective Lifetime

Abstraction: Variant · Status: Draft

The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.

2002 vulnerabilities reference this CWE, most recent first.

GHSA-5QHG-FFC9-X697

Vulnerability from github – Published: 2025-09-15 15:31 – Updated: 2025-12-02 21:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

coresight: Fix memory leak in acpi_buffer->pointer

There are memory leaks reported by kmemleak: ... unreferenced object 0xffff00213c141000 (size 1024): comm "systemd-udevd", pid 2123, jiffies 4294909467 (age 6062.160s) hex dump (first 32 bytes): 04 00 00 00 02 00 00 00 18 10 14 3c 21 00 ff ff ...........<!... 00 00 00 00 00 00 00 00 03 00 00 00 10 00 00 00 ................ backtrace: [<000000004b7c9001>] __kmem_cache_alloc_node+0x2f8/0x348 [<00000000b0fc7ceb>] __kmalloc+0x58/0x108 [<0000000064ff4695>] acpi_os_allocate+0x2c/0x68 [<000000007d57d116>] acpi_ut_initialize_buffer+0x54/0xe0 [<0000000024583908>] acpi_evaluate_object+0x388/0x438 [<0000000017b2e72b>] acpi_evaluate_object_typed+0xe8/0x240 [<000000005df0eac2>] coresight_get_platform_data+0x1b4/0x988 [coresight] ...

The ACPI buffer memory (buf.pointer) should be freed. But the buffer is also used after returning from acpi_get_dsd_graph(). Move the temporary variables buf to acpi_coresight_parse_graph(), and free it before the function return to prevent memory leak.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-53261"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-15T15:15:53Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncoresight: Fix memory leak in acpi_buffer-\u003epointer\n\nThere are memory leaks reported by kmemleak:\n...\nunreferenced object 0xffff00213c141000 (size 1024):\n  comm \"systemd-udevd\", pid 2123, jiffies 4294909467 (age 6062.160s)\n  hex dump (first 32 bytes):\n    04 00 00 00 02 00 00 00 18 10 14 3c 21 00 ff ff  ...........\u003c!...\n    00 00 00 00 00 00 00 00 03 00 00 00 10 00 00 00  ................\n  backtrace:\n    [\u003c000000004b7c9001\u003e] __kmem_cache_alloc_node+0x2f8/0x348\n    [\u003c00000000b0fc7ceb\u003e] __kmalloc+0x58/0x108\n    [\u003c0000000064ff4695\u003e] acpi_os_allocate+0x2c/0x68\n    [\u003c000000007d57d116\u003e] acpi_ut_initialize_buffer+0x54/0xe0\n    [\u003c0000000024583908\u003e] acpi_evaluate_object+0x388/0x438\n    [\u003c0000000017b2e72b\u003e] acpi_evaluate_object_typed+0xe8/0x240\n    [\u003c000000005df0eac2\u003e] coresight_get_platform_data+0x1b4/0x988 [coresight]\n...\n\nThe ACPI buffer memory (buf.pointer) should be freed. But the buffer\nis also used after returning from acpi_get_dsd_graph().\nMove the temporary variables buf to acpi_coresight_parse_graph(),\nand free it before the function return to prevent memory leak.",
  "id": "GHSA-5qhg-ffc9-x697",
  "modified": "2025-12-02T21:31:26Z",
  "published": "2025-09-15T15:31:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53261"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1a9e02673e2550f5612099e64e8761f0c8fc0f50"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d1b60e7c9fee34eaedf1fc4e0471f75b33f83a4a"
    }
  ],
  "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"
    }
  ]
}

GHSA-5R7X-C359-RJ25

Vulnerability from github – Published: 2022-05-24 17:46 – Updated: 2022-05-24 17:46
VLAI
Details

There is a memory leak vulnerability in some Huawei products. An authenticated remote attacker may exploit this vulnerability by sending specific message to the affected product. Due to not release the allocated memory properly, successful exploit may cause some service abnormal. Affected product include some versions of IPS Module, NGFW Module, Secospace USG6300, Secospace USG6500, Secospace USG6600 and USG9500.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-22312"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-08T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "There is a memory leak vulnerability in some Huawei products. An authenticated remote attacker may exploit this vulnerability by sending specific message to the affected product. Due to not release the allocated memory properly, successful exploit may cause some service abnormal. Affected product include some versions of IPS Module, NGFW Module, Secospace USG6300, Secospace USG6500, Secospace USG6600 and USG9500.",
  "id": "GHSA-5r7x-c359-rj25",
  "modified": "2022-05-24T17:46:53Z",
  "published": "2022-05-24T17:46:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22312"
    },
    {
      "type": "WEB",
      "url": "https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20210210-01-memoryleak-en"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-5RMX-H57X-XQ29

Vulnerability from github – Published: 2024-10-21 21:30 – Updated: 2024-10-25 21:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

gpiolib: fix memory leak in gpiochip_setup_dev()

Here is a backtrace report about memory leak detected in gpiochip_setup_dev():

unreferenced object 0xffff88810b406400 (size 512): comm "python3", pid 1682, jiffies 4295346908 (age 24.090s) backtrace: kmalloc_trace device_add device_private_init at drivers/base/core.c:3361 (inlined by) device_add at drivers/base/core.c:3411 cdev_device_add gpiolib_cdev_register gpiochip_setup_dev gpiochip_add_data_with_key

gcdev_register() & gcdev_unregister() would call device_add() & device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to register/unregister device.

However, if device_add() succeeds, some resource (like struct device_private allocated by device_private_init()) is not released by device_del().

Therefore, after device_add() succeeds by gcdev_register(), it needs to call put_device() to release resource in the error handle path.

Here we move forward the register of release function, and let it release every piece of resource by put_device() instead of kfree().

While at it, fix another subtle issue, i.e. when gc->ngpio is equal to 0, we still call kcalloc() and, in case of further error, kfree() on the ZERO_PTR pointer, which is not NULL. It's not a bug per se, but rather waste of the resources and potentially wrong expectation about contents of the gdev->descs variable.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-48975"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-21T20:15:09Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ngpiolib: fix memory leak in gpiochip_setup_dev()\n\nHere is a backtrace report about memory leak detected in\ngpiochip_setup_dev():\n\nunreferenced object 0xffff88810b406400 (size 512):\n  comm \"python3\", pid 1682, jiffies 4295346908 (age 24.090s)\n  backtrace:\n    kmalloc_trace\n    device_add\t\tdevice_private_init at drivers/base/core.c:3361\n\t\t\t(inlined by) device_add at drivers/base/core.c:3411\n    cdev_device_add\n    gpiolib_cdev_register\n    gpiochip_setup_dev\n    gpiochip_add_data_with_key\n\ngcdev_register() \u0026 gcdev_unregister() would call device_add() \u0026\ndevice_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to\nregister/unregister device.\n\nHowever, if device_add() succeeds, some resource (like\nstruct device_private allocated by device_private_init())\nis not released by device_del().\n\nTherefore, after device_add() succeeds by gcdev_register(), it\nneeds to call put_device() to release resource in the error handle\npath.\n\nHere we move forward the register of release function, and let it\nrelease every piece of resource by put_device() instead of kfree().\n\nWhile at it, fix another subtle issue, i.e. when gc-\u003engpio is equal\nto 0, we still call kcalloc() and, in case of further error, kfree()\non the ZERO_PTR pointer, which is not NULL. It\u0027s not a bug per se,\nbut rather waste of the resources and potentially wrong expectation\nabout contents of the gdev-\u003edescs variable.",
  "id": "GHSA-5rmx-h57x-xq29",
  "modified": "2024-10-25T21:31:27Z",
  "published": "2024-10-21T21:30:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48975"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/371363716398ed718e389bea8c5e9843a79dde4e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6daaa84b621485fe28c401be18debf92ae8ef04a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ec851b23084b3a0af8bf0f5e51d33a8d678bdc49"
    }
  ],
  "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"
    }
  ]
}

GHSA-5RR5-4VG6-QW69

Vulnerability from github – Published: 2022-05-24 16:58 – Updated: 2022-05-24 16:58
VLAI
Details

An issue was discovered in Xen through 4.11.x allowing x86 guest OS users to cause a denial of service or gain privileges because grant-table transfer requests are mishandled.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-17340"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-10-08T01:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in Xen through 4.11.x allowing x86 guest OS users to cause a denial of service or gain privileges because grant-table transfer requests are mishandled.",
  "id": "GHSA-5rr5-4vg6-qw69",
  "modified": "2022-05-24T16:58:09Z",
  "published": "2022-05-24T16:58:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17340"
    },
    {
      "type": "WEB",
      "url": "https://seclists.org/bugtraq/2020/Jan/21"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2020/dsa-4602"
    },
    {
      "type": "WEB",
      "url": "https://xenbits.xen.org/xsa/advisory-284.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2019/10/25/1"
    },
    {
      "type": "WEB",
      "url": "http://xenbits.xen.org/xsa/advisory-284.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5RVR-WXFV-48QG

Vulnerability from github – Published: 2022-05-13 01:22 – Updated: 2022-05-13 01:22
VLAI
Details

On BIG-IP 11.5.1-11.6.3, 12.1.0-12.1.3, 13.0.0-13.1.1.1, and 14.0.0-14.0.0.2, under certain conditions, the snmpd daemon may leak memory on a multi-blade BIG-IP vCMP guest when processing authorized SNMP requests.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-6608"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-03-28T21:29:00Z",
    "severity": "HIGH"
  },
  "details": "On BIG-IP 11.5.1-11.6.3, 12.1.0-12.1.3, 13.0.0-13.1.1.1, and 14.0.0-14.0.0.2, under certain conditions, the snmpd daemon may leak memory on a multi-blade BIG-IP vCMP guest when processing authorized SNMP requests.",
  "id": "GHSA-5rvr-wxfv-48qg",
  "modified": "2022-05-13T01:22:45Z",
  "published": "2022-05-13T01:22:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-6608"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K12139752"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5RWJ-J5M3-3CHJ

Vulnerability from github – Published: 2021-09-01 18:25 – Updated: 2021-10-21 14:28
VLAI
Summary
Missing Release of Memory after Effective Lifetime in detect-character-encoding
Details

Impact

In detect-character-encoding v0.3.0 and earlier, allocated memory is not released.

Patches

The problem has been patched in detect-character-encoding v0.3.1.

CVSS score

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/RL:O/RC:C

Base Score: 7.5 (High) Temporal Score: 7.2 (High)

Since detect-character-encoding is a library, the scoring is based on the “reasonable worst-case implementation scenario”, namely, using detect-character-encoding in a program accessible over the internet which becomes unavailable when running out of memory. Depending on your specific implementation, the vulnerability’s severity in your program may be different.

Proof of concept

const express = require("express");
const detectCharacterEncoding = require("detect-character-encoding");

const app = express();

app.get("/", (req, res) => {
  detectCharacterEncoding(Buffer.from("foo"));

  res.end();
});

app.listen(3000);

hey -n 1000000 http://localhost:3000 (hey) causes the Node.js process to consume more and more memory.

References

  • https://github.com/sonicdoe/detect-character-encoding/commit/d44356927b92e3b13e178071bf6d7c671766f588
  • https://github.com/sonicdoe/detect-character-encoding/pull/6
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "detect-character-encoding"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-39176"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-08-31T19:58:46Z",
    "nvd_published_at": "2021-08-31T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nIn detect-character-encoding v0.3.0 and earlier, allocated memory is not released.\n\n### Patches\n\nThe problem has been patched in [detect-character-encoding v0.3.1](https://github.com/sonicdoe/detect-character-encoding/releases/tag/v0.3.1).\n\n### CVSS score\n\n[CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/RL:O/RC:C](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/RL:O/RC:C)\n\nBase Score: 7.5 (High)\nTemporal Score: 7.2 (High)\n\nSince detect-character-encoding is a library, the scoring is based on the \u201c[reasonable worst-case implementation scenario](https://www.first.org/cvss/v3.1/user-guide#3-7-Scoring-Vulnerabilities-in-Software-Libraries-and-Similar)\u201d, namely, using detect-character-encoding in a program accessible over the internet which becomes unavailable when running out of memory. Depending on your specific implementation, the vulnerability\u2019s severity in your program may be different.\n\n### Proof of concept\n\n```js\nconst express = require(\"express\");\nconst detectCharacterEncoding = require(\"detect-character-encoding\");\n\nconst app = express();\n\napp.get(\"/\", (req, res) =\u003e {\n  detectCharacterEncoding(Buffer.from(\"foo\"));\n\n  res.end();\n});\n\napp.listen(3000);\n```\n\n`hey -n 1000000 http://localhost:3000` ([`hey`](https://github.com/rakyll/hey)) causes the Node.js process to consume more and more memory.\n\n### References\n\n- https://github.com/sonicdoe/detect-character-encoding/commit/d44356927b92e3b13e178071bf6d7c671766f588\n- https://github.com/sonicdoe/detect-character-encoding/pull/6",
  "id": "GHSA-5rwj-j5m3-3chj",
  "modified": "2021-10-21T14:28:07Z",
  "published": "2021-09-01T18:25:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sonicdoe/detect-character-encoding/security/advisories/GHSA-5rwj-j5m3-3chj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39176"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sonicdoe/detect-character-encoding/pull/6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sonicdoe/detect-character-encoding/commit/d44356927b92e3b13e178071bf6d7c671766f588"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sonicdoe/detect-character-encoding"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sonicdoe/detect-character-encoding/releases/tag/v0.3.1"
    }
  ],
  "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": "Missing Release of Memory after Effective Lifetime in detect-character-encoding"
}

GHSA-5V43-2P8Q-45M6

Vulnerability from github – Published: 2022-05-24 19:18 – Updated: 2023-02-11 03:32
VLAI
Details

Multiple Cisco products are affected by a vulnerability in the way the Snort detection engine processes ICMP traffic that could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. The vulnerability is due to improper memory resource management while the Snort detection engine is processing ICMP packets. An attacker could exploit this vulnerability by sending a series of ICMP packets through an affected device. A successful exploit could allow the attacker to exhaust resources on the affected device, causing the device to reload.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-40114"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401",
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-10-27T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "Multiple Cisco products are affected by a vulnerability in the way the Snort detection engine processes ICMP traffic that could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. The vulnerability is due to improper memory resource management while the Snort detection engine is processing ICMP packets. An attacker could exploit this vulnerability by sending a series of ICMP packets through an affected device. A successful exploit could allow the attacker to exhaust resources on the affected device, causing the device to reload.",
  "id": "GHSA-5v43-2p8q-45m6",
  "modified": "2023-02-11T03:32:49Z",
  "published": "2022-05-24T19:18:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40114"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/02/msg00011.html"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-snort-dos-s2R7W9UU"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2023/dsa-5354"
    }
  ],
  "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-5V59-J8MR-J2WP

Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-14 18:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

net: lantiq_xrx200: restore buffer if memory allocation failed

In a situation where memory allocation fails, an invalid buffer address is stored. When this descriptor is used again, the system panics in the build_skb() function when accessing memory.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-49997"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-18T11:15:27Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: lantiq_xrx200: restore buffer if memory allocation failed\n\nIn a situation where memory allocation fails, an invalid buffer address\nis stored. When this descriptor is used again, the system panics in the\nbuild_skb() function when accessing memory.",
  "id": "GHSA-5v59-j8mr-j2wp",
  "modified": "2025-11-14T18:31:24Z",
  "published": "2025-06-18T12:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49997"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3ef2786e32d93e562cd40601248a14ae090de873"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c9c3b1775f80fa21f5bff874027d2ccb10f5d90c"
    }
  ],
  "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"
    }
  ]
}

GHSA-5VFQ-RV44-C5FF

Vulnerability from github – Published: 2022-09-22 00:00 – Updated: 2025-05-28 18:33
VLAI
Details

By spoofing the target resolver with responses that have a malformed ECDSA signature, an attacker can trigger a small memory leak. It is possible to gradually erode available memory to the point where named crashes for lack of resources.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-38177"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347",
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-09-21T11:15:00Z",
    "severity": "HIGH"
  },
  "details": "By spoofing the target resolver with responses that have a malformed ECDSA signature, an attacker can trigger a small memory leak. It is possible to gradually erode available memory to the point where named crashes for lack of resources.",
  "id": "GHSA-5vfq-rv44-c5ff",
  "modified": "2025-05-28T18:33:05Z",
  "published": "2022-09-22T00:00:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38177"
    },
    {
      "type": "WEB",
      "url": "https://kb.isc.org/docs/cve-2022-38177"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/10/msg00007.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/CV4GQWBPF7Y52J2FA24U6UMHQAOXZEF7"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/MRHB6J4Z7BKH4HPEKG5D35QGRD6ANNMT"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YZJQNUASODNVAWZV6STKG5SD6XIJ446S"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/CV4GQWBPF7Y52J2FA24U6UMHQAOXZEF7"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MRHB6J4Z7BKH4HPEKG5D35QGRD6ANNMT"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/YZJQNUASODNVAWZV6STKG5SD6XIJ446S"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202210-25"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20221228-0010"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2022/dsa-5235"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2022/09/21/3"
    }
  ],
  "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-5VP7-VVX6-J367

Vulnerability from github – Published: 2021-12-08 00:01 – Updated: 2021-12-08 00:01
VLAI
Details

There is a Memory leak vulnerability with the codec detection module in Huawei Smartphone.Successful exploitation of this vulnerability may cause the device to restart due to memory exhaustion.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-37046"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-12-07T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "There is a Memory leak vulnerability with the codec detection module in Huawei Smartphone.Successful exploitation of this vulnerability may cause the device to restart due to memory exhaustion.",
  "id": "GHSA-5vp7-vvx6-j367",
  "modified": "2021-12-08T00:01:26Z",
  "published": "2021-12-08T00:01:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37046"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2021/9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

Mitigation MIT-41
Implementation

Strategy: Libraries or Frameworks

  • Choose a language or tool that provides automatic memory management, or makes manual memory management less error-prone.
  • For example, glibc in Linux provides protection against free of invalid pointers.
  • When using Xcode to target OS X or iOS, enable automatic reference counting (ARC) [REF-391].
  • To help correctly and consistently manage memory when programming in C++, consider using a smart pointer class such as std::auto_ptr (defined by ISO/IEC ISO/IEC 14882:2003), std::shared_ptr and std::unique_ptr (specified by an upcoming revision of the C++ standard, informally referred to as C++ 1x), or equivalent solutions such as Boost.
Mitigation
Architecture and Design

Use an abstraction library to abstract away risky APIs. Not a complete solution.

Mitigation
Architecture and Design Build and Compilation

Consider using the Boehm-Demers-Weiser garbage collector (bdwgc), which can help avoid leaks.

No CAPEC attack patterns related to this CWE.