Common Weakness Enumeration

CWE-401

Allowed

Missing Release of Memory after Effective Lifetime

Abstraction: Variant · Status: Draft

API response cwe.mitre.org

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

2010 vulnerabilities reference this CWE, most recent first.

GHSA-G9WX-JRCM-HGG5

Vulnerability from github – Published: 2025-10-01 12:30 – Updated: 2026-01-16 21:30
VLAI
Details

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

cifs: Fix xid leak in cifs_flock()

If not flock, before return -ENOLCK, should free the xid, otherwise, the xid will be leaked.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-50460"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-01T12:15:39Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix xid leak in cifs_flock()\n\nIf not flock, before return -ENOLCK, should free the xid,\notherwise, the xid will be leaked.",
  "id": "GHSA-g9wx-jrcm-hgg5",
  "modified": "2026-01-16T21:30:28Z",
  "published": "2025-10-01T12:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50460"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2d08311aa3056a84bfdc09bc47777de6a9b16c30"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/575e079c782b9862ec2626403922d041a42e6ed6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8905d13b9ede4caa88c577faed832d6c7383f4fb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f8c9b4a963fec5d0e37e3e8522bb19b0c28e1a73"
    }
  ],
  "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-GCF6-VGCR-474F

Vulnerability from github – Published: 2025-05-19 03:30 – Updated: 2025-05-19 03:30
VLAI
Details

In Node.js, the ReadFileUtf8 internal binding leaks memory due to a corrupted pointer in uv_fs_s.file: a UTF-16 path buffer is allocated but subsequently overwritten when the file descriptor is set. This results in an unrecoverable memory leak on every call. Repeated use can cause unbounded memory growth, leading to a denial of service.

Impact: * This vulnerability affects APIs relying on ReadFileUtf8 on Node.js release lines: v20 and v22.

Severity
3.7 (Low)
CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-23165"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-19T02:15:17Z",
    "severity": "LOW"
  },
  "details": "In Node.js, the `ReadFileUtf8` internal binding leaks memory due to a corrupted pointer in `uv_fs_s.file`: a UTF-16 path buffer is allocated but subsequently overwritten when the file descriptor is set. This results in an unrecoverable memory leak on every call. Repeated use can cause unbounded memory growth, leading to a denial of service.\n\nImpact:\n* This vulnerability affects APIs relying on `ReadFileUtf8` on Node.js release lines: v20 and v22.",
  "id": "GHSA-gcf6-vgcr-474f",
  "modified": "2025-05-19T03:30:29Z",
  "published": "2025-05-19T03:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23165"
    },
    {
      "type": "WEB",
      "url": "https://nodejs.org/en/blog/vulnerability/may-2025-security-releases"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GCM7-8QCF-55M9

Vulnerability from github – Published: 2022-05-24 22:28 – Updated: 2022-08-06 00:00
VLAI
Details

On Juniper Networks MX Series and EX9200 Series platforms with Trio-based MPCs (Modular Port Concentrators) where Integrated Routing and Bridging (IRB) interfaces are configured and mapped to a VPLS instance or a Bridge-Domain, certain Layer 2 network events at Customer Edge (CE) devices may cause memory leaks in the MPC of Provider Edge (PE) devices which can cause an out of memory condition and MPC restart. When this issue occurs, there will be temporary traffic interruption until the MPC is restored. An administrator can use the following CLI command to monitor the status of memory usage level of the MPC: user@device> show system resource-monitor fpc FPC Resource Usage Summary Free Heap Mem Watermark : 20 % Free NH Mem Watermark : 20 % Free Filter Mem Watermark : 20 % * - Watermark reached Slot # % Heap Free RTT Average RTT 1 87 PFE # % ENCAP mem Free % NH mem Free % FW mem Free 0 NA 88 99 1 NA 89 99 When the issue is occurring, the value of “% NH mem Free” will go down until the MPC restarts. This issue affects MX Series and EX9200 Series with Trio-based PFEs (Packet Forwarding Engines), including MX-MPC1-3D, MX-MPC1E-3D, MX-MPC2-3D, MX-MPC2E-3D, MPC-3D-16XGE, and CHAS-MXxx Series MPCs. No other products or platforms are affected by this issue. This issue affects Juniper Networks Junos OS on MX Series, EX9200 Series: 17.3 versions prior to 17.3R3-S10; 17.4 versions prior to 17.4R3-S3; 18.2 versions prior to 18.2R3-S7; 18.3 versions prior to 18.3R3-S4; 18.4 versions prior to 18.4R3-S6; 19.2 versions prior to 19.2R3-S2; 19.3 versions prior to 19.3R3-S1; 19.4 versions prior to 19.4R2-S2, 19.4R3; 20.2 versions prior to 20.2R1-S3, 20.2R2; 20.3 versions prior to 20.3R1-S1,, 20.3R2. This issue does not affect Juniper Networks Junos OS: 17.3 versions prior to 17.3R3-S8; 17.4 versions prior to 17.4R3-S2; 18.1; 18.2 versions prior to 18.2R3-S4; 18.3 versions prior to 18.3R3-S2; 18.4 versions prior to 18.4R3-S1; 19.1; 19.2 versions prior to 19.2R2; 19.3 versions prior to 19.3R3; 19.4 versions prior to 19.4R2.

Severity
6.5 (Medium)
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-0257"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-22T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "On Juniper Networks MX Series and EX9200 Series platforms with Trio-based MPCs (Modular Port Concentrators) where Integrated Routing and Bridging (IRB) interfaces are configured and mapped to a VPLS instance or a Bridge-Domain, certain Layer 2 network events at Customer Edge (CE) devices may cause memory leaks in the MPC of Provider Edge (PE) devices which can cause an out of memory condition and MPC restart. When this issue occurs, there will be temporary traffic interruption until the MPC is restored. An administrator can use the following CLI command to monitor the status of memory usage level of the MPC: user@device\u003e show system resource-monitor fpc FPC Resource Usage Summary Free Heap Mem Watermark : 20 % Free NH Mem Watermark : 20 % Free Filter Mem Watermark : 20 % * - Watermark reached Slot # % Heap Free RTT Average RTT 1 87 PFE # % ENCAP mem Free % NH mem Free % FW mem Free 0 NA 88 99 1 NA 89 99 When the issue is occurring, the value of \u201c% NH mem Free\u201d will go down until the MPC restarts. This issue affects MX Series and EX9200 Series with Trio-based PFEs (Packet Forwarding Engines), including MX-MPC1-3D, MX-MPC1E-3D, MX-MPC2-3D, MX-MPC2E-3D, MPC-3D-16XGE, and CHAS-MXxx Series MPCs. No other products or platforms are affected by this issue. This issue affects Juniper Networks Junos OS on MX Series, EX9200 Series: 17.3 versions prior to 17.3R3-S10; 17.4 versions prior to 17.4R3-S3; 18.2 versions prior to 18.2R3-S7; 18.3 versions prior to 18.3R3-S4; 18.4 versions prior to 18.4R3-S6; 19.2 versions prior to 19.2R3-S2; 19.3 versions prior to 19.3R3-S1; 19.4 versions prior to 19.4R2-S2, 19.4R3; 20.2 versions prior to 20.2R1-S3, 20.2R2; 20.3 versions prior to 20.3R1-S1,, 20.3R2. This issue does not affect Juniper Networks Junos OS: 17.3 versions prior to 17.3R3-S8; 17.4 versions prior to 17.4R3-S2; 18.1; 18.2 versions prior to 18.2R3-S4; 18.3 versions prior to 18.3R3-S2; 18.4 versions prior to 18.4R3-S1; 19.1; 19.2 versions prior to 19.2R2; 19.3 versions prior to 19.3R3; 19.4 versions prior to 19.4R2.",
  "id": "GHSA-gcm7-8qcf-55m9",
  "modified": "2022-08-06T00:00:43Z",
  "published": "2022-05-24T22:28:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0257"
    },
    {
      "type": "WEB",
      "url": "https://kb.juniper.net/JSA11148"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GG3P-V52W-P6FR

Vulnerability from github – Published: 2024-03-03 00:30 – Updated: 2024-12-11 15:31
VLAI
Details

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

drm/meson: fix memory leak on ->hpd_notify callback

The EDID returned by drm_bridge_get_edid() needs to be freed.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-52563"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-02T22:15:48Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/meson: fix memory leak on -\u003ehpd_notify callback\n\nThe EDID returned by drm_bridge_get_edid() needs to be freed.",
  "id": "GHSA-gg3p-v52w-p6fr",
  "modified": "2024-12-11T15:31:14Z",
  "published": "2024-03-03T00:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52563"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/099f0af9d98231bb74956ce92508e87cbcb896be"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/43b63e088887a8b82750e16762f77100ffa76cba"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/66cb6d74f5a1b6eafe3370b56bf2cb575a91acbc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ee335e0094add7fc2c7034e0534e1920d61d2078"
    }
  ],
  "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-GG7H-8W45-PGPG

Vulnerability from github – Published: 2022-05-24 17:10 – Updated: 2023-01-24 03:30
VLAI
Details

QEMU 4.1.0 has a memory leak in zrle_compress_data in ui/vnc-enc-zrle.c during a VNC disconnect operation because libz is misused, resulting in a situation where memory allocated in deflateInit2 is not freed in deflateEnd.

Severity
3.5 (Low)
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-20382"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-03-05T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "QEMU 4.1.0 has a memory leak in zrle_compress_data in ui/vnc-enc-zrle.c during a VNC disconnect operation because libz is misused, resulting in a situation where memory allocated in deflateInit2 is not freed in deflateEnd.",
  "id": "GHSA-gg7h-8w45-pgpg",
  "modified": "2023-01-24T03:30:18Z",
  "published": "2022-05-24T17:10:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-20382"
    },
    {
      "type": "WEB",
      "url": "https://git.qemu.org/?p=qemu.git;a=commit;h=6bf21f3d83e95bcc4ba35a7a07cc6655e8b010b0"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/07/msg00020.html"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4372-1"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2020/dsa-4665"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-04/msg00007.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2020/03/05/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GG86-5H5F-JRWX

Vulnerability from github – Published: 2024-05-21 15:31 – Updated: 2024-12-30 21:30
VLAI
Details

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

drm/amd/display: Fix potential memory leak in DMUB hw_init

[Why] On resume we perform DMUB hw_init which allocates memory: dm_resume->dm_dmub_hw_init->dc_dmub_srv_create->kzalloc That results in memory leak in suspend/resume scenarios.

[How] Allocate memory for the DC wrapper to DMUB only if it was not allocated before. No need to reallocate it on suspend/resume.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-47253"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-21T15:15:14Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix potential memory leak in DMUB hw_init\n\n[Why]\nOn resume we perform DMUB hw_init which allocates memory:\ndm_resume-\u003edm_dmub_hw_init-\u003edc_dmub_srv_create-\u003ekzalloc\nThat results in memory leak in suspend/resume scenarios.\n\n[How]\nAllocate memory for the DC wrapper to DMUB only if it was not\nallocated before.\nNo need to reallocate it on suspend/resume.",
  "id": "GHSA-gg86-5h5f-jrwx",
  "modified": "2024-12-30T21:30:46Z",
  "published": "2024-05-21T15:31:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47253"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9e8c2af010463197315fa54a6c17e74988b5259c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/aa000f828e60ac15d6340f606ec4a673966f5b0b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c5699e2d863f58221044efdc3fa712dd32d55cde"
    }
  ],
  "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-GGV4-4QFX-2GH6

Vulnerability from github – Published: 2024-11-09 12:30 – Updated: 2025-09-26 18:31
VLAI
Details

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

lib: alloc_tag_module_unload must wait for pending kfree_rcu calls

Ben Greear reports following splat: ------------[ cut here ]------------ net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0 Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat ... Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020 RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0 codetag_unload_module+0x19b/0x2a0 ? codetag_load_module+0x80/0x80

nf_nat module exit calls kfree_rcu on those addresses, but the free operation is likely still pending by the time alloc_tag checks for leaks.

Wait for outstanding kfree_rcu operations to complete before checking resolves this warning.

Reproducer: unshare -n iptables-nft -t nat -A PREROUTING -p tcp grep nf_nat /proc/allocinfo # will list 4 allocations rmmod nft_chain_nat rmmod nf_nat # will WARN.

[akpm@linux-foundation.org: add comment]

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-50212"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-09T11:15:04Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nlib: alloc_tag_module_unload must wait for pending kfree_rcu calls\n\nBen Greear reports following splat:\n ------------[ cut here ]------------\n net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload\n WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0\n Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat\n...\n Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020\n RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0\n  codetag_unload_module+0x19b/0x2a0\n  ? codetag_load_module+0x80/0x80\n\nnf_nat module exit calls kfree_rcu on those addresses, but the free\noperation is likely still pending by the time alloc_tag checks for leaks.\n\nWait for outstanding kfree_rcu operations to complete before checking\nresolves this warning.\n\nReproducer:\nunshare -n iptables-nft -t nat -A PREROUTING -p tcp\ngrep nf_nat /proc/allocinfo # will list 4 allocations\nrmmod nft_chain_nat\nrmmod nf_nat                # will WARN.\n\n[akpm@linux-foundation.org: add comment]",
  "id": "GHSA-ggv4-4qfx-2gh6",
  "modified": "2025-09-26T18:31:18Z",
  "published": "2024-11-09T12:30:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50212"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/24211fb49c9ac1b576470b7e393a5a0b50af2707"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dc783ba4b9df3fb3e76e968b2cbeb9960069263c"
    }
  ],
  "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-GGWM-QQ5R-J28W

Vulnerability from github – Published: 2022-05-24 22:28 – Updated: 2022-08-06 00:00
VLAI
Details

On Juniper Networks MX Series and EX9200 Series platforms with Trio-based MPC (Modular Port Concentrator) where Integrated Routing and Bridging (IRB) interface is configured and it is mapped to a VPLS instance or a Bridge-Domain, certain network events at Customer Edge (CE) device may cause memory leak in the MPC which can cause an out of memory and MPC restarts. When this issue occurs, there will be temporary traffic interruption until the MPC is restored. An administrator can use the following CLI command to monitor the status of memory usage level of the MPC: user@device> show system resource-monitor fpc FPC Resource Usage Summary Free Heap Mem Watermark : 20 % Free NH Mem Watermark : 20 % Free Filter Mem Watermark : 20 % * - Watermark reached Slot # % Heap Free RTT Average RTT 1 87 PFE # % ENCAP mem Free % NH mem Free % FW mem Free 0 NA 88 99 1 NA 89 99 When the issue is occurring, the value of “% NH mem Free” will go down until the MPC restarts. This issue affects MX Series and EX9200 Series with Trio-based PFEs (Packet Forwarding Engines). Please refer to https://kb.juniper.net/KB25385 for the list of Trio-based PFEs. This issue affects Juniper Networks Junos OS on MX Series, EX9200 Series: 17.3R3-S8; 17.4R3-S2; 18.2R3-S4, 18.2R3-S5; 18.3R3-S2, 18.3R3-S3; 18.4 versions starting from 18.4R3-S1 and later versions prior to 18.4R3-S6; 19.2 versions starting from 19.2R2 and later versions prior to 19.2R3-S1; 19.4 versions starting from 19.4R2 and later versions prior to 19.4R2-S3, 19.4R3; 20.2 versions starting from 20.2R1 and later versions prior to 20.2R1-S3, 20.2R2. This issue does not affect Juniper Networks Junos OS: 18.1, 19.1, 19.3, 20.1.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-0202"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-15T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "On Juniper Networks MX Series and EX9200 Series platforms with Trio-based MPC (Modular Port Concentrator) where Integrated Routing and Bridging (IRB) interface is configured and it is mapped to a VPLS instance or a Bridge-Domain, certain network events at Customer Edge (CE) device may cause memory leak in the MPC which can cause an out of memory and MPC restarts. When this issue occurs, there will be temporary traffic interruption until the MPC is restored. An administrator can use the following CLI command to monitor the status of memory usage level of the MPC: user@device\u003e show system resource-monitor fpc FPC Resource Usage Summary Free Heap Mem Watermark : 20 % Free NH Mem Watermark : 20 % Free Filter Mem Watermark : 20 % * - Watermark reached Slot # % Heap Free RTT Average RTT 1 87 PFE # % ENCAP mem Free % NH mem Free % FW mem Free 0 NA 88 99 1 NA 89 99 When the issue is occurring, the value of \u201c% NH mem Free\u201d will go down until the MPC restarts. This issue affects MX Series and EX9200 Series with Trio-based PFEs (Packet Forwarding Engines). Please refer to https://kb.juniper.net/KB25385 for the list of Trio-based PFEs. This issue affects Juniper Networks Junos OS on MX Series, EX9200 Series: 17.3R3-S8; 17.4R3-S2; 18.2R3-S4, 18.2R3-S5; 18.3R3-S2, 18.3R3-S3; 18.4 versions starting from 18.4R3-S1 and later versions prior to 18.4R3-S6; 19.2 versions starting from 19.2R2 and later versions prior to 19.2R3-S1; 19.4 versions starting from 19.4R2 and later versions prior to 19.4R2-S3, 19.4R3; 20.2 versions starting from 20.2R1 and later versions prior to 20.2R1-S3, 20.2R2. This issue does not affect Juniper Networks Junos OS: 18.1, 19.1, 19.3, 20.1.",
  "id": "GHSA-ggwm-qq5r-j28w",
  "modified": "2022-08-06T00:00:38Z",
  "published": "2022-05-24T22:28:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0202"
    },
    {
      "type": "WEB",
      "url": "https://kb.juniper.net/JSA11092"
    }
  ],
  "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-GH8C-2875-38XV

Vulnerability from github – Published: 2024-11-19 18:31 – Updated: 2024-11-23 03:31
VLAI
Details

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

iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table()

If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loop of iio_gts_build_avail_scale_table(), the err_free_out will fail to call kfree() each time when i is reduced to 0, so all the per_time_scales[0] and per_time_gains[0] will not be freed, which will cause memory leaks.

Fix it by checking if i >= 0.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-53076"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-19T18:15:27Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\niio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table()\n\nIf per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loop\nof iio_gts_build_avail_scale_table(), the err_free_out will fail to call\nkfree() each time when i is reduced to 0, so all the per_time_scales[0]\nand per_time_gains[0] will not be freed, which will cause memory leaks.\n\nFix it by checking if i \u003e= 0.",
  "id": "GHSA-gh8c-2875-38xv",
  "modified": "2024-11-23T03:31:57Z",
  "published": "2024-11-19T18:31:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53076"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/369f05688911b05216cfcd6ca74473bec87948d7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/62c11896683129790b8f5ab6eb7e695818b0b723"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b304362ce836968b803e5d4c5f84dcb51a7bf0f2"
    }
  ],
  "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-GH9Q-398W-69GX

Vulnerability from github – Published: 2025-10-04 18:31 – Updated: 2026-01-23 18:31
VLAI
Details

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

ntb_netdev: Use dev_kfree_skb_any() in interrupt context

TX/RX callback handlers (ntb_netdev_tx_handler(), ntb_netdev_rx_handler()) can be called in interrupt context via the DMA framework when the respective DMA operations have completed. As such, any calls by these routines to free skb's, should use the interrupt context safe dev_kfree_skb_any() function.

Previously, these callback handlers would call the interrupt unsafe version of dev_kfree_skb(). This has not presented an issue on Intel IOAT DMA engines as that driver utilizes tasklets rather than a hard interrupt handler, like the AMD PTDMA DMA driver. On AMD systems, a kernel WARNING message is encountered, which is being issued from skb_release_head_state() due to in_hardirq() being true.

Besides the user visible WARNING from the kernel, the other symptom of this bug was that TCP/IP performance across the ntb_netdev interface was very poor, i.e. approximately an order of magnitude below what was expected. With the repair to use dev_kfree_skb_any(), kernel WARNINGs from skb_release_head_state() ceased and TCP/IP performance, as measured by iperf, was on par with expected results, approximately 20 Gb/s on AMD Milan based server. Note that this performance is comparable with Intel based servers.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-50476"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-04T16:15:44Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nntb_netdev: Use dev_kfree_skb_any() in interrupt context\n\nTX/RX callback handlers (ntb_netdev_tx_handler(),\nntb_netdev_rx_handler()) can be called in interrupt\ncontext via the DMA framework when the respective\nDMA operations have completed. As such, any calls\nby these routines to free skb\u0027s, should use the\ninterrupt context safe dev_kfree_skb_any() function.\n\nPreviously, these callback handlers would call the\ninterrupt unsafe version of dev_kfree_skb(). This has\nnot presented an issue on Intel IOAT DMA engines as\nthat driver utilizes tasklets rather than a hard\ninterrupt handler, like the AMD PTDMA DMA driver.\nOn AMD systems, a kernel WARNING message is\nencountered, which is being issued from\nskb_release_head_state() due to in_hardirq()\nbeing true.\n\nBesides the user visible WARNING from the kernel,\nthe other symptom of this bug was that TCP/IP performance\nacross the ntb_netdev interface was very poor, i.e.\napproximately an order of magnitude below what was\nexpected. With the repair to use dev_kfree_skb_any(),\nkernel WARNINGs from skb_release_head_state() ceased\nand TCP/IP performance, as measured by iperf, was on\npar with expected results, approximately 20 Gb/s on\nAMD Milan based server. Note that this performance\nis comparable with Intel based servers.",
  "id": "GHSA-gh9q-398w-69gx",
  "modified": "2026-01-23T18:31:23Z",
  "published": "2025-10-04T18:31:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50476"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/07e28a8f450217db679802ebd4de0915556ce846"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/13286ad1c7c49c606fdcba4cf66f953a1a16c1ca"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/14d245da57a11e80277ab455aa9b6dcc5ed38a19"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/21296a52caa6a6bad6debdfe40ad81d4f1a27e69"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5f7d78b2b12a9d561f48fa00bab29b40f4616dad"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8b78493968ed3cef0326183ed059c55e42f24d5b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a6b9e09403102bdf8402dae734800e4916c7ea58"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d4460c82177899751975180c268f352893302221"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dd860b39aa7c7b82e6c99b6fdb99d4610ce49d67"
    }
  ],
  "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"
    }
  ]
}
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.

← Back to the CWE list