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.

2091 vulnerabilities reference this CWE, most recent first.

GHSA-2Q39-W2HW-2PJM

Vulnerability from github – Published: 2025-03-28 21:30 – Updated: 2026-07-21 15:01
VLAI
Summary
Infinispan Potential Out of Memory Error via REST Compare API Buffer API
Details

A vulnerability was found in the Infinispan component in Red Hat Data Grid. The REST compare API may have a buffer leak and an out of memory error can occur when sending continual requests with large POST data to the REST API.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.infinispan:infinispan-query"
      },
      "versions": [
        "15.1.0.Dev01"
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.infinispan:infinispan-query"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "15.0.5.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-6875"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-31T16:10:04Z",
    "nvd_published_at": "2025-03-28T21:15:17Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in the Infinispan component in Red Hat Data Grid. The REST compare API may have a buffer leak and an out of memory error can occur when sending continual requests with large POST data to the REST API.",
  "id": "GHSA-2q39-w2hw-2pjm",
  "modified": "2026-07-21T15:01:34Z",
  "published": "2025-03-28T21:30:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6875"
    },
    {
      "type": "WEB",
      "url": "https://github.com/infinispan/infinispan/pull/12645"
    },
    {
      "type": "WEB",
      "url": "https://github.com/infinispan/infinispan/pull/12663"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2024-6875"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2298555"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/infinispan/infinispan"
    },
    {
      "type": "WEB",
      "url": "https://issues.redhat.com/browse/JDG-7169"
    }
  ],
  "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"
    }
  ],
  "summary": "Infinispan Potential Out of Memory Error via REST Compare API Buffer API"
}

GHSA-2Q87-GCQ9-5RFQ

Vulnerability from github – Published: 2025-10-07 18:31 – Updated: 2026-02-04 21:30
VLAI
Details

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

r6040: Fix kmemleak in probe and remove

There is a memory leaks reported by kmemleak:

unreferenced object 0xffff888116111000 (size 2048): comm "modprobe", pid 817, jiffies 4294759745 (age 76.502s) hex dump (first 32 bytes): 00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff ................ 08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [] kmalloc_trace+0x22/0x60 [] phy_device_create+0x4e/0x90 [] get_phy_device+0xd2/0x220 [] mdiobus_scan+0xa4/0x2e0 [] __mdiobus_register+0x482/0x8b0 [] r6040_init_one+0x714/0xd2c [r6040] ...

The problem occurs in probe process as follows: r6040_init_one: mdiobus_register mdiobus_scan <- alloc and register phy_device, the reference count of phy_device is 3 r6040_mii_probe phy_connect <- connect to the first phy_device, so the reference count of the first phy_device is 4, others are 3 register_netdev <- fault inject succeeded, goto error handling path

// error handling path
err_out_mdio_unregister:
  mdiobus_unregister(lp->mii_bus);
err_out_mdio:
  mdiobus_free(lp->mii_bus);    <- the reference count of the first
                                   phy_device is 1, it is not released
                                   and other phy_devices are released

// similarly, the remove process also has the same problem

The root cause is traced to the phy_device is not disconnected when removes one r6040 device in r6040_remove_one() or on error handling path after r6040_mii probed successfully. In r6040_mii_probe(), a net ethernet device is connected to the first PHY device of mii_bus, in order to notify the connected driver when the link status changes, which is the default behavior of the PHY infrastructure to handle everything. Therefore the phy_device should be disconnected when removes one r6040 device or on error handling path.

Fix it by adding phy_disconnect() when removes one r6040 device or on error handling path after r6040_mii probed successfully.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-50545"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-07T16:15:38Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nr6040: Fix kmemleak in probe and remove\n\nThere is a memory leaks reported by kmemleak:\n\n  unreferenced object 0xffff888116111000 (size 2048):\n    comm \"modprobe\", pid 817, jiffies 4294759745 (age 76.502s)\n    hex dump (first 32 bytes):\n      00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff  ................\n      08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00  ................\n    backtrace:\n      [\u003cffffffff815bcd82\u003e] kmalloc_trace+0x22/0x60\n      [\u003cffffffff827e20ee\u003e] phy_device_create+0x4e/0x90\n      [\u003cffffffff827e6072\u003e] get_phy_device+0xd2/0x220\n      [\u003cffffffff827e7844\u003e] mdiobus_scan+0xa4/0x2e0\n      [\u003cffffffff827e8be2\u003e] __mdiobus_register+0x482/0x8b0\n      [\u003cffffffffa01f5d24\u003e] r6040_init_one+0x714/0xd2c [r6040]\n      ...\n\nThe problem occurs in probe process as follows:\n  r6040_init_one:\n    mdiobus_register\n      mdiobus_scan    \u003c- alloc and register phy_device,\n                         the reference count of phy_device is 3\n    r6040_mii_probe\n      phy_connect     \u003c- connect to the first phy_device,\n                         so the reference count of the first\n                         phy_device is 4, others are 3\n    register_netdev   \u003c- fault inject succeeded, goto error handling path\n\n    // error handling path\n    err_out_mdio_unregister:\n      mdiobus_unregister(lp-\u003emii_bus);\n    err_out_mdio:\n      mdiobus_free(lp-\u003emii_bus);    \u003c- the reference count of the first\n                                       phy_device is 1, it is not released\n                                       and other phy_devices are released\n  // similarly, the remove process also has the same problem\n\nThe root cause is traced to the phy_device is not disconnected when\nremoves one r6040 device in r6040_remove_one() or on error handling path\nafter r6040_mii probed successfully. In r6040_mii_probe(), a net ethernet\ndevice is connected to the first PHY device of mii_bus, in order to\nnotify the connected driver when the link status changes, which is the\ndefault behavior of the PHY infrastructure to handle everything.\nTherefore the phy_device should be disconnected when removes one r6040\ndevice or on error handling path.\n\nFix it by adding phy_disconnect() when removes one r6040 device or on\nerror handling path after r6040_mii probed successfully.",
  "id": "GHSA-2q87-gcq9-5rfq",
  "modified": "2026-02-04T21:30:24Z",
  "published": "2025-10-07T18:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50545"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2ce242e1b9ad31c1f68496b3548e407a8cb2c07d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3d5f83a62e8235d235534b3dc6f197d8a822c269"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5944c25c67de54e0aa53623e1e1af3bf8b16ed44"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7e43039a49c2da45edc1d9d7c9ede4003ab45a5f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9b5b50329e2e966831a7237dd6949e7b5362a49a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a04707f4596952049da05756c27398c34d9a1d36"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ad2c8f25457ca9a81e7e958148cbc26600ce3071"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b0a61359026b57a287a48fbb4ba1d097023eca3e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b4448816e6a565e08236a6009c6bf48c6836cdfd"
    }
  ],
  "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-2QJ8-C2V4-6CG6

Vulnerability from github – Published: 2025-02-27 03:34 – Updated: 2025-10-01 21:31
VLAI
Details

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

net: ethernet: ti: am65-cpsw: fix memleak in certain XDP cases

If the XDP program doesn't result in XDP_PASS then we leak the memory allocated by am65_cpsw_build_skb().

It is pointless to allocate SKB memory before running the XDP program as we would be wasting CPU cycles for cases other than XDP_PASS. Move the SKB allocation after evaluating the XDP program result.

This fixes the memleak. A performance boost is seen for XDP_DROP test.

XDP_DROP test: Before: 460256 rx/s 0 err/s After: 784130 rx/s 0 err/s

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-21788"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-27T03:15:19Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: ti: am65-cpsw: fix memleak in certain XDP cases\n\nIf the XDP program doesn\u0027t result in XDP_PASS then we leak the\nmemory allocated by am65_cpsw_build_skb().\n\nIt is pointless to allocate SKB memory before running the XDP\nprogram as we would be wasting CPU cycles for cases other than XDP_PASS.\nMove the SKB allocation after evaluating the XDP program result.\n\nThis fixes the memleak. A performance boost is seen for XDP_DROP test.\n\nXDP_DROP test:\nBefore: 460256 rx/s                  0 err/s\nAfter:  784130 rx/s                  0 err/s",
  "id": "GHSA-2qj8-c2v4-6cg6",
  "modified": "2025-10-01T21:31:12Z",
  "published": "2025-02-27T03:34:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21788"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1bba1d042107167164a0ae3a843fdf650ab005d7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5db843258de1e4e6b1ef1cbd1797923c9e3de548"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dc11f049612b9d926aca2e55f8dc9d82850d0da3"
    }
  ],
  "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-2QJP-425J-52J9

Vulnerability from github – Published: 2022-12-07 23:23 – Updated: 2022-12-07 23:23
VLAI
Summary
containerd CRI stream server vulnerable to host memory exhaustion via terminal
Details

Impact

A bug was found in containerd's CRI implementation where a user can exhaust memory on the host. In the CRI stream server, a goroutine is launched to handle terminal resize events if a TTY is requested. If the user's process fails to launch due to, for example, a faulty command, the goroutine will be stuck waiting to send without a receiver, resulting in a memory leak. Kubernetes and crictl can both be configured to use containerd's CRI implementation and the stream server is used for handling container IO.

Patches

This bug has been fixed in containerd 1.6.12 and 1.5.16. Users should update to these versions to resolve the issue.

Workarounds

Ensure that only trusted images and commands are used and that only trusted users have permissions to execute commands in running containers.

For more information

If you have any questions or comments about this advisory:

To report a security issue in containerd: * Report a new vulnerability * Email us at security@containerd.io

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containerd/containerd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.5.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containerd/containerd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.6.0"
            },
            {
              "fixed": "1.6.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-23471"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-401"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-07T23:23:43Z",
    "nvd_published_at": "2022-12-07T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nA bug was found in containerd\u0027s CRI implementation where a user can exhaust memory on the host. In the CRI stream server, a goroutine is launched to handle terminal resize events if a TTY is requested. If the user\u0027s process fails to launch due to, for example, a faulty command, the goroutine will be stuck waiting to send without a receiver, resulting in a memory leak. Kubernetes and crictl can both be configured to use containerd\u0027s CRI implementation and the stream server is used for handling container IO.\n\n### Patches\n\nThis bug has been fixed in containerd 1.6.12 and 1.5.16.  Users should update to these versions to resolve the issue.\n\n### Workarounds\n\nEnsure that only trusted images and commands are used and that only trusted users have permissions to execute commands in running containers. \n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n* Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose)\n* Email us at [security@containerd.io](mailto:security@containerd.io)\n\nTo report a security issue in containerd:\n* [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new)\n* Email us at [security@containerd.io](mailto:security@containerd.io)",
  "id": "GHSA-2qjp-425j-52j9",
  "modified": "2022-12-07T23:23:43Z",
  "published": "2022-12-07T23:23:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/containerd/containerd/security/advisories/GHSA-2qjp-425j-52j9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23471"
    },
    {
      "type": "WEB",
      "url": "https://github.com/containerd/containerd/commit/241563be06a3de8b6a849414c4e805b68d3bb295"
    },
    {
      "type": "WEB",
      "url": "https://github.com/containerd/containerd/commit/a05d175400b1145e5e6a735a6710579d181e7fb0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/containerd/containerd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/containerd/containerd/releases/tag/v1.5.16"
    },
    {
      "type": "WEB",
      "url": "https://github.com/containerd/containerd/releases/tag/v1.6.12"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202401-31"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "containerd CRI stream server vulnerable to host memory exhaustion via terminal"
}

GHSA-2QM8-4J25-V4W6

Vulnerability from github – Published: 2024-02-05 18:31 – Updated: 2024-02-08 00:32
VLAI
Details

gpac v2.2.1 was discovered to contain a memory leak via the dst_props variable in the gf_filter_pid_merge_properties_internal function.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-24265"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-05T18:15:52Z",
    "severity": "HIGH"
  },
  "details": "gpac v2.2.1 was discovered to contain a memory leak via the dst_props variable in the gf_filter_pid_merge_properties_internal function.",
  "id": "GHSA-2qm8-4j25-v4w6",
  "modified": "2024-02-08T00:32:19Z",
  "published": "2024-02-05T18:31:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24265"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yinluming13579/gpac_defects/blob/main/gpac_1.md"
    }
  ],
  "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-2QM9-92XG-CR8H

Vulnerability from github – Published: 2024-05-21 18:31 – Updated: 2025-09-23 21:30
VLAI
Details

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

media: imon: fix access to invalid resource for the second interface

imon driver probes two USB interfaces, and at the probe of the second interface, the driver assumes blindly that the first interface got bound with the same imon driver. It's usually true, but it's still possible that the first interface is bound with another driver via a malformed descriptor. Then it may lead to a memory corruption, as spotted by syzkaller; imon driver accesses the data from drvdata as struct imon_context object although it's a completely different one that was assigned by another driver.

This patch adds a sanity check -- whether the first interface is really bound with the imon driver or not -- for avoiding the problem above at the probe time.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-52754"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-21T16:15:14Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: imon: fix access to invalid resource for the second interface\n\nimon driver probes two USB interfaces, and at the probe of the second\ninterface, the driver assumes blindly that the first interface got\nbound with the same imon driver.  It\u0027s usually true, but it\u0027s still\npossible that the first interface is bound with another driver via a\nmalformed descriptor.  Then it may lead to a memory corruption, as\nspotted by syzkaller; imon driver accesses the data from drvdata as\nstruct imon_context object although it\u0027s a completely different one\nthat was assigned by another driver.\n\nThis patch adds a sanity check -- whether the first interface is\nreally bound with the imon driver or not -- for avoiding the problem\nabove at the probe time.",
  "id": "GHSA-2qm9-92xg-cr8h",
  "modified": "2025-09-23T21:30:53Z",
  "published": "2024-05-21T18:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52754"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0f5068519f89d928d6c51100e4b274479123829f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/10ec5a97f8f5a772a1a42b4eb27196b447cd3aa9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2a493a34bd6e496c55fabedd82b957193ace178f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5e0b788fb96be36d1baf1a5c88d09c7c82a0452a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a1766a4fd83befa0b34d932d532e7ebb7fab1fa7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b083aaf5db2eeca9e362723258e5d8698f7dd84e"
    }
  ],
  "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-2QP4-WWRV-GF4C

Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2022-05-24 19:03
VLAI
Details

A Denial of Service vulnerability exists in FFmpeg 4.2 due to a memory leak in avcodec_alloc_context3 at options.c.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-22037"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-01T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A Denial of Service vulnerability exists in FFmpeg 4.2 due to a memory leak in avcodec_alloc_context3 at options.c.",
  "id": "GHSA-2qp4-wwrv-gf4c",
  "modified": "2022-05-24T19:03:40Z",
  "published": "2022-05-24T19:03:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-22037"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/11/msg00012.html"
    },
    {
      "type": "WEB",
      "url": "https://trac.ffmpeg.org/ticket/8281"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-4990"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-4998"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-2R25-QJCV-HR44

Vulnerability from github – Published: 2026-07-19 12:30 – Updated: 2026-07-29 18:31
VLAI
Details

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

drm/colorop: Fix blob property reference tracking in state lifecycle

The colorop state blob property handling had memory leaks during state duplication, destruction, and reset operations. The implementation failed to follow the established pattern from drm_crtc's handling of DEGAMMA/GAMMA blob properties.

Issues fixed: - drm_colorop_atomic_destroy_state() was freeing state memory without releasing the blob reference, causing a leak - drm_colorop_reset() was directly freeing old state with kfree() instead of properly destroying it, leaking blob references - drm_colorop_cleanup() had duplicate blob cleanup code

Changes: - Add __drm_atomic_helper_colorop_destroy_state() helper to properly release blob references before freeing state memory - Update drm_colorop_atomic_destroy_state() to call the helper - Fix drm_colorop_reset() to use drm_colorop_atomic_destroy_state() for proper cleanup of old state - Simplify drm_colorop_cleanup() to use the common destruction path

This matches the well-tested pattern used by drm_crtc since 2016 and ensures proper reference counting throughout the state lifecycle.

Co-developed by Claude Sonnet 4.5.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-53378"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-19T11:16:38Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/colorop: Fix blob property reference tracking in state lifecycle\n\nThe colorop state blob property handling had memory leaks during state\nduplication, destruction, and reset operations. The implementation\nfailed to follow the established pattern from drm_crtc\u0027s handling of\nDEGAMMA/GAMMA blob properties.\n\nIssues fixed:\n- drm_colorop_atomic_destroy_state() was freeing state memory without\n  releasing the blob reference, causing a leak\n- drm_colorop_reset() was directly freeing old state with kfree()\n  instead of properly destroying it, leaking blob references\n- drm_colorop_cleanup() had duplicate blob cleanup code\n\nChanges:\n- Add __drm_atomic_helper_colorop_destroy_state() helper to properly\n  release blob references before freeing state memory\n- Update drm_colorop_atomic_destroy_state() to call the helper\n- Fix drm_colorop_reset() to use drm_colorop_atomic_destroy_state()\n  for proper cleanup of old state\n- Simplify drm_colorop_cleanup() to use the common destruction path\n\nThis matches the well-tested pattern used by drm_crtc since 2016 and\nensures proper reference counting throughout the state lifecycle.\n\nCo-developed by Claude Sonnet 4.5.",
  "id": "GHSA-2r25-qjcv-hr44",
  "modified": "2026-07-29T18:31:31Z",
  "published": "2026-07-19T12:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53378"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/235b333e2878d791cee09e1e72f44611a9400114"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/271059f1d9020e9ac967524e319fbbaa22d0475b"
    }
  ],
  "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-2R2X-3JH4-CHHV

Vulnerability from github – Published: 2024-05-22 09:31 – Updated: 2025-11-03 18:31
VLAI
Details

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

ptp: Fix possible memory leak in ptp_clock_register()

I got memory leak as follows when doing fault injection test:

unreferenced object 0xffff88800906c618 (size 8): comm "i2c-idt82p33931", pid 4421, jiffies 4294948083 (age 13.188s) hex dump (first 8 bytes): 70 74 70 30 00 00 00 00 ptp0.... backtrace: [<00000000312ed458>] __kmalloc_track_caller+0x19f/0x3a0 [<0000000079f6e2ff>] kvasprintf+0xb5/0x150 [<0000000026aae54f>] kvasprintf_const+0x60/0x190 [<00000000f323a5f7>] kobject_set_name_vargs+0x56/0x150 [<000000004e35abdd>] dev_set_name+0xc0/0x100 [<00000000f20cfe25>] ptp_clock_register+0x9f4/0xd30 [ptp] [<000000008bb9f0de>] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]

When posix_clock_register() returns an error, the name allocated in dev_set_name() will be leaked, the put_device() should be used to give up the device reference, then the name will be freed in kobject_cleanup() and other memory will be freed in ptp_clock_release().

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-47455"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-22T07:15:10Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nptp: Fix possible memory leak in ptp_clock_register()\n\nI got memory leak as follows when doing fault injection test:\n\nunreferenced object 0xffff88800906c618 (size 8):\n  comm \"i2c-idt82p33931\", pid 4421, jiffies 4294948083 (age 13.188s)\n  hex dump (first 8 bytes):\n    70 74 70 30 00 00 00 00                          ptp0....\n  backtrace:\n    [\u003c00000000312ed458\u003e] __kmalloc_track_caller+0x19f/0x3a0\n    [\u003c0000000079f6e2ff\u003e] kvasprintf+0xb5/0x150\n    [\u003c0000000026aae54f\u003e] kvasprintf_const+0x60/0x190\n    [\u003c00000000f323a5f7\u003e] kobject_set_name_vargs+0x56/0x150\n    [\u003c000000004e35abdd\u003e] dev_set_name+0xc0/0x100\n    [\u003c00000000f20cfe25\u003e] ptp_clock_register+0x9f4/0xd30 [ptp]\n    [\u003c000000008bb9f0de\u003e] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]\n\nWhen posix_clock_register() returns an error, the name allocated\nin dev_set_name() will be leaked, the put_device() should be used\nto give up the device reference, then the name will be freed in\nkobject_cleanup() and other memory will be freed in ptp_clock_release().",
  "id": "GHSA-2r2x-3jh4-chhv",
  "modified": "2025-11-03T18:31:14Z",
  "published": "2024-05-22T09:31:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47455"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4225fea1cb28370086e17e82c0f69bec2779dca0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/95c0a0c5ec8839f8f21672be786e87a100319ca8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f1c96d8085588e1b997a96214b409ac3be20b524"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.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"
    }
  ]
}

GHSA-2R3R-854P-XJFR

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

Memory leak in pngrutil.c in libpng before 1.2.44, and 1.4.x before 1.4.3, allows remote attackers to cause a denial of service (memory consumption and application crash) via a PNG image containing malformed Physical Scale (aka sCAL) chunks.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2010-2249"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2010-06-30T18:30:00Z",
    "severity": "MODERATE"
  },
  "details": "Memory leak in pngrutil.c in libpng before 1.2.44, and 1.4.x before 1.4.3, allows remote attackers to cause a denial of service (memory consumption and application crash) via a PNG image containing malformed Physical Scale (aka sCAL) chunks.",
  "id": "GHSA-2r3r-854p-xjfr",
  "modified": "2022-05-13T01:23:34Z",
  "published": "2022-05-13T01:23:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2010-2249"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2010:0534"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2010-2249"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=608644"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/59816"
    },
    {
      "type": "WEB",
      "url": "http://libpng.git.sourceforge.net/git/gitweb.cgi?p=libpng/libpng%3Ba=commitdiff%3Bh=90cfcecc09febb8d6c8c1d37ea7bb7cf0f4b00f3#patch20"
    },
    {
      "type": "WEB",
      "url": "http://libpng.git.sourceforge.net/git/gitweb.cgi?p=libpng/libpng;a=commitdiff;h=90cfcecc09febb8d6c8c1d37ea7bb7cf0f4b00f3#patch20"
    },
    {
      "type": "WEB",
      "url": "http://lists.apple.com/archives/security-announce/2010//Nov/msg00000.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.apple.com/archives/security-announce/2010//Nov/msg00003.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.apple.com/archives/security-announce/2011//Mar/msg00004.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.apple.com/archives/security-announce/2011/Mar/msg00000.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.fedoraproject.org/pipermail/package-announce/2010-July/044283.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.fedoraproject.org/pipermail/package-announce/2010-July/044397.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2010-09/msg00006.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.vmware.com/pipermail/security-announce/2010/000105.html"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/40302"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/40336"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/40472"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/40547"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/41574"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/42314"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/42317"
    },
    {
      "type": "WEB",
      "url": "http://slackware.com/security/viewer.php?l=slackware-security\u0026y=2010\u0026m=slackware-security.613061"
    },
    {
      "type": "WEB",
      "url": "http://support.apple.com/kb/HT4435"
    },
    {
      "type": "WEB",
      "url": "http://support.apple.com/kb/HT4456"
    },
    {
      "type": "WEB",
      "url": "http://support.apple.com/kb/HT4457"
    },
    {
      "type": "WEB",
      "url": "http://support.apple.com/kb/HT4554"
    },
    {
      "type": "WEB",
      "url": "http://support.apple.com/kb/HT4566"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2010/dsa-2072"
    },
    {
      "type": "WEB",
      "url": "http://www.libpng.org/pub/png/libpng.html"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDVSA-2010:133"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/41174"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id?1024723"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/USN-960-1"
    },
    {
      "type": "WEB",
      "url": "http://www.vmware.com/security/advisories/VMSA-2010-0014.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2010/1612"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2010/1637"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2010/1755"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2010/1837"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2010/1846"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2010/1877"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2010/2491"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2010/3045"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2010/3046"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/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.