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.

2185 vulnerabilities reference this CWE, most recent first.

GHSA-WXM3-66F2-8XFM

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

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

clk: Fix memory leak in devm_clk_notifier_register()

devm_clk_notifier_register() allocates a devres resource for clk notifier but didn't register that to the device, so the notifier didn't get unregistered on device detach and the allocated resource was leaked.

Fix the issue by registering the resource through devres_add().

This issue was found with kmemleak on a Chromebook.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-53674"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-07T16:15:51Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nclk: Fix memory leak in devm_clk_notifier_register()\n\ndevm_clk_notifier_register() allocates a devres resource for clk\nnotifier but didn\u0027t register that to the device, so the notifier didn\u0027t\nget unregistered on device detach and the allocated resource was leaked.\n\nFix the issue by registering the resource through devres_add().\n\nThis issue was found with kmemleak on a Chromebook.",
  "id": "GHSA-wxm3-66f2-8xfm",
  "modified": "2026-02-03T21:31:47Z",
  "published": "2025-10-07T18:31:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53674"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/49451db71b746df990888068961f1033f7c9b734"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7fb933e56f77a57ef7cfc59fc34cbbf1b1fa31ff"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a326cf0107b197e649bbaa2a2b1355894826ce32"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cb1b04fd4283fc8f9acefe0ddc61ba072ed44877"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/efbbda79b2881a04dcd0e8f28634933d79e17e49"
    }
  ],
  "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-X27M-P9C5-JVF7

Vulnerability from github – Published: 2024-07-16 12:30 – Updated: 2024-08-21 18:31
VLAI
Details

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

Drivers: hv: vmbus: Fix memory leak in vmbus_add_channel_kobj

kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add():

If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object.

Fix memory leak by calling kobject_put().

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-48775"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-16T12:15:02Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nDrivers: hv: vmbus: Fix memory leak in vmbus_add_channel_kobj\n\nkobject_init_and_add() takes reference even when it fails.\nAccording to the doc of kobject_init_and_add()\uff1a\n\n   If this function returns an error, kobject_put() must be called to\n   properly clean up the memory associated with the object.\n\nFix memory leak by calling kobject_put().",
  "id": "GHSA-x27m-p9c5-jvf7",
  "modified": "2024-08-21T18:31:26Z",
  "published": "2024-07-16T12:30:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48775"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/417947891bd5ae327f15efed1a0da2b12ef24962"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8bc69f86328e87a0ffa79438430cc82f3aa6a194"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/91d8866ca55232d21995a3d54fac96de33c9e20c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/92e25b637cd4e010f776c86e4810300e773eac5c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c377e2ba78d3fe9a1f0b4ec424e75f81da7e81e9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fe595759c2a4a5bb41c438474f15947d8ae32f5c"
    }
  ],
  "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-X27V-RJQH-F4XC

Vulnerability from github – Published: 2022-08-11 00:00 – Updated: 2025-11-03 21:30
VLAI
Details

The th_read() function doesn’t free a variable t->th_buf.gnu_longname after allocating memory, which may cause a memory leak.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-33646"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-10T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "The th_read() function doesn\u2019t free a variable t-\u003eth_buf.gnu_longname after allocating memory, which may cause a memory leak.",
  "id": "GHSA-x27v-rjqh-f4xc",
  "modified": "2025-11-03T21:30:42Z",
  "published": "2022-08-11T00:00:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33646"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00026.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/4S4PJRCJLEAWN2EKXGLSOBTL7O57V7NC"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/5YSHZY753R7XW6CIKJVAWI373WW3YRRJ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/7Q26QDNOJDOFYWMJWEIK5XR62M2FF6IJ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/7WX5YE66CT7Y5C2HTHXSFDKQWYWYWJ2T"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/OD4HEBSTI22FNYKOKK7W3X6ZQE6FV3XC"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4S4PJRCJLEAWN2EKXGLSOBTL7O57V7NC"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/5YSHZY753R7XW6CIKJVAWI373WW3YRRJ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/7Q26QDNOJDOFYWMJWEIK5XR62M2FF6IJ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/7WX5YE66CT7Y5C2HTHXSFDKQWYWYWJ2T"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OD4HEBSTI22FNYKOKK7W3X6ZQE6FV3XC"
    },
    {
      "type": "WEB",
      "url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2022-1807"
    }
  ],
  "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-X2CQ-7WHJ-PV8W

Vulnerability from github – Published: 2024-02-15 21:31 – Updated: 2024-02-15 21:31
VLAI
Details

A memory leak in the Silicon Labs' Bluetooth stack for EFR32 products may cause memory to be exhausted when sending notifications to multiple clients, this results in all Bluetooth operations, such as advertising and scanning, to stop.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-0240"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-15T21:15:08Z",
    "severity": "MODERATE"
  },
  "details": "A memory leak in the Silicon Labs\u0027 Bluetooth stack for EFR32 products may cause memory to be exhausted when sending notifications to multiple clients, this results in all Bluetooth operations, such as advertising and scanning, to stop.",
  "id": "GHSA-x2cq-7whj-pv8w",
  "modified": "2024-02-15T21:31:27Z",
  "published": "2024-02-15T21:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0240"
    },
    {
      "type": "WEB",
      "url": "https://community.silabs.com/069Vm000001AjEfIAK"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SiliconLabs/gecko_sdk"
    }
  ],
  "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-X2PV-VMM7-RHWR

Vulnerability from github – Published: 2026-03-04 18:31 – Updated: 2026-03-04 18:31
VLAI
Details

A vulnerability in the Remote Access SSL VPN functionality of Cisco Secure Firewall Adaptive Security Appliance (ASA) Software and Secure Firewall Threat Defense (FTD) Software could allow an authenticated, remote attacker with a valid VPN connection to exhaust device memory resulting in a denial of service (DoS) condition.This does not affect the management or MUS interfaces.

This vulnerability is due to trusting user input without validation. An attacker could exploit this vulnerability by sending crafted packets to the Remote Access SSL VPN server. A successful exploit could allow the attacker to cause the device to reload, resulting in a DoS condition.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-20105"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-04T18:16:26Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the Remote Access SSL VPN functionality of Cisco Secure Firewall Adaptive Security Appliance (ASA) Software and Secure Firewall Threat Defense (FTD) Software could allow an authenticated, remote attacker with a valid VPN connection to exhaust device memory resulting in a denial of service (DoS) condition.This does not affect the management or MUS interfaces.\n\n This vulnerability is due to trusting user input without validation. An attacker could exploit this vulnerability by sending crafted packets to the Remote Access SSL VPN server. A successful exploit could allow the attacker to cause the device to reload, resulting in a DoS condition.",
  "id": "GHSA-x2pv-vmm7-rhwr",
  "modified": "2026-03-04T18:31:56Z",
  "published": "2026-03-04T18:31:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20105"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-vpn-m9sx6MbC"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X2XJ-658J-798F

Vulnerability from github – Published: 2024-08-21 03:31 – Updated: 2026-05-12 12:32
VLAI
Details

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

devres: Fix memory leakage caused by driver API devm_free_percpu()

It will cause memory leakage when use driver API devm_free_percpu() to free memory allocated by devm_alloc_percpu(), fixed by using devres_release() instead of devres_destroy() within devm_free_percpu().

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-43871"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-21T01:15:11Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndevres: Fix memory leakage caused by driver API devm_free_percpu()\n\nIt will cause memory leakage when use driver API devm_free_percpu()\nto free memory allocated by devm_alloc_percpu(), fixed by using\ndevres_release() instead of devres_destroy() within devm_free_percpu().",
  "id": "GHSA-x2xj-658j-798f",
  "modified": "2026-05-12T12:32:04Z",
  "published": "2024-08-21T03:31:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43871"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-355557.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-398330.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-613116.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3047f99caec240a88ccd06197af2868da1af6a96"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3dcd0673e47664bc6c719ad47dadac6d55d5950d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/700e8abd65b10792b2f179ce4e858f2ca2880f85"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/95065edb8ebb27771d5f1e898eef6ab43dc6c87c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b044588a16a978cd891cb3d665dd7ae06850d5bf"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b67552d7c61f52f1271031adfa7834545ae99701"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bd50a974097bb82d52a458bd3ee39fb723129a0c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ef56dcdca8f2a53abc3a83d388b8336447533d85"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.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-X37F-9GM8-PV63

Vulnerability from github – Published: 2025-04-01 18:30 – Updated: 2025-11-03 21:33
VLAI
Details

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

drm/hyperv: Fix address space leak when Hyper-V DRM device is removed

When a Hyper-V DRM device is probed, the driver allocates MMIO space for the vram, and maps it cacheable. If the device removed, or in the error path for device probing, the MMIO space is released but no unmap is done. Consequently the kernel address space for the mapping is leaked.

Fix this by adding iounmap() calls in the device removal path, and in the error path during device probing.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-21978"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-01T16:15:29Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/hyperv: Fix address space leak when Hyper-V DRM device is removed\n\nWhen a Hyper-V DRM device is probed, the driver allocates MMIO space for\nthe vram, and maps it cacheable. If the device removed, or in the error\npath for device probing, the MMIO space is released but no unmap is done.\nConsequently the kernel address space for the mapping is leaked.\n\nFix this by adding iounmap() calls in the device removal path, and in the\nerror path during device probing.",
  "id": "GHSA-x37f-9gm8-pv63",
  "modified": "2025-11-03T21:33:26Z",
  "published": "2025-04-01T18:30:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21978"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/158242b56bf465a73e1edeac0fe828a8acad4499"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/24f1bbfb2be77dad82489c1468bbb14312aab129"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ad27b4a51495490b815580d9b935e8eee14d1a9c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/aed709355fd05ef747e1af24a1d5d78cd7feb81e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c40cd24bfb9bfbb315c118ca14ebe6cf52e2dd1e"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.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-X37Q-QW63-QF28

Vulnerability from github – Published: 2025-09-11 18:35 – Updated: 2026-05-12 15:31
VLAI
Details

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

mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()

A soft lockup warning was observed on a relative small system x86-64 system with 16 GB of memory when running a debug kernel with kmemleak enabled.

watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]

The test system was running a workload with hot unplug happening in parallel. Then kemleak decided to disable itself due to its inability to allocate more kmemleak objects. The debug kernel has its CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.

The soft lockup happened in kmemleak_do_cleanup() when the existing kmemleak objects were being removed and deleted one-by-one in a loop via a workqueue. In this particular case, there are at least 40,000 objects that need to be processed and given the slowness of a debug kernel and the fact that a raw_spinlock has to be acquired and released in __delete_object(), it could take a while to properly handle all these objects.

As kmemleak has been disabled in this case, the object removal and deletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edge case that should rarely happen. So the simple solution is to call cond_resched() at periodic interval in the iteration loop to avoid soft lockup.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-39737"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-11T17:15:35Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()\n\nA soft lockup warning was observed on a relative small system x86-64\nsystem with 16 GB of memory when running a debug kernel with kmemleak\nenabled.\n\n  watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]\n\nThe test system was running a workload with hot unplug happening in\nparallel.  Then kemleak decided to disable itself due to its inability to\nallocate more kmemleak objects.  The debug kernel has its\nCONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.\n\nThe soft lockup happened in kmemleak_do_cleanup() when the existing\nkmemleak objects were being removed and deleted one-by-one in a loop via a\nworkqueue.  In this particular case, there are at least 40,000 objects\nthat need to be processed and given the slowness of a debug kernel and the\nfact that a raw_spinlock has to be acquired and released in\n__delete_object(), it could take a while to properly handle all these\nobjects.\n\nAs kmemleak has been disabled in this case, the object removal and\ndeletion process can be further optimized as locking isn\u0027t really needed. \nHowever, it is probably not worth the effort to optimize for such an edge\ncase that should rarely happen.  So the simple solution is to call\ncond_resched() at periodic interval in the iteration loop to avoid soft\nlockup.",
  "id": "GHSA-x37q-qw63-qf28",
  "modified": "2026-05-12T15:31:05Z",
  "published": "2025-09-11T18:35:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39737"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1ef72a7fedc5bca70e8cc980985790de10d407aa"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8d2d22a55ffe35c38e69795468a7addd1a80e9ce"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/926092268efdf1ed7b55cf486356c74a9e7710d1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9b80430c194e4a114dc663c1025d56b4f3d0153d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9f1f4e95031f84867c5821540466d62f88dab8ca"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a04de4c40aab9b338dfa989cf4aec70fd187eeb2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d1534ae23c2b6be350c8ab060803fbf6e9682adc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e21a3ddd58733ce31afcb1e5dc3cb80a4b5bc29b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f014c10d190b92aad366e56b445daffcd1c075e4"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.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-X3CP-9CGR-M6GC

Vulnerability from github – Published: 2024-05-17 15:31 – Updated: 2025-09-19 18:31
VLAI
Details

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

KVM: x86: Mark target gfn of emulated atomic instruction as dirty

When emulating an atomic access on behalf of the guest, mark the target gfn dirty if the CMPXCHG by KVM is attempted and doesn't fault. This fixes a bug where KVM effectively corrupts guest memory during live migration by writing to guest memory without informing userspace that the page is dirty.

Marking the page dirty got unintentionally dropped when KVM's emulated CMPXCHG was converted to do a user access. Before that, KVM explicitly mapped the guest page into kernel memory, and marked the page dirty during the unmap phase.

Mark the page dirty even if the CMPXCHG fails, as the old data is written back on failure, i.e. the page is still written. The value written is guaranteed to be the same because the operation is atomic, but KVM's ABI is that all writes are dirty logged regardless of the value written. And more importantly, that's what KVM did before the buggy commit.

Huge kudos to the folks on the Cc list (and many others), who did all the actual work of triaging and debugging.

base-commit: 6769ea8da8a93ed4630f1ce64df6aafcaabfce64

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-35804"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-17T14:15:13Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Mark target gfn of emulated atomic instruction as dirty\n\nWhen emulating an atomic access on behalf of the guest, mark the target\ngfn dirty if the CMPXCHG by KVM is attempted and doesn\u0027t fault.  This\nfixes a bug where KVM effectively corrupts guest memory during live\nmigration by writing to guest memory without informing userspace that the\npage is dirty.\n\nMarking the page dirty got unintentionally dropped when KVM\u0027s emulated\nCMPXCHG was converted to do a user access.  Before that, KVM explicitly\nmapped the guest page into kernel memory, and marked the page dirty during\nthe unmap phase.\n\nMark the page dirty even if the CMPXCHG fails, as the old data is written\nback on failure, i.e. the page is still written.  The value written is\nguaranteed to be the same because the operation is atomic, but KVM\u0027s ABI\nis that all writes are dirty logged regardless of the value written.  And\nmore importantly, that\u0027s what KVM did before the buggy commit.\n\nHuge kudos to the folks on the Cc list (and many others), who did all the\nactual work of triaging and debugging.\n\nbase-commit: 6769ea8da8a93ed4630f1ce64df6aafcaabfce64",
  "id": "GHSA-x3cp-9cgr-m6gc",
  "modified": "2025-09-19T18:31:17Z",
  "published": "2024-05-17T15:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35804"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/225d587a073584946c05c9b7651d637bd45c0c71"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/726374dde5d608b15b9756bd52b6fc283fda7a06"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/910c57dfa4d113aae6571c2a8b9ae8c430975902"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9d1b22e573a3789ed1f32033ee709106993ba551"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a9bd6bb6f02bf7132c1ab192ba62bbfa52df7d66"
    }
  ],
  "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-X3WV-3WJ6-MVVV

Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-16 03:30
VLAI
Details

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

drm/amdgpu: Fix memory leak in amdgpu_ras_init()

When amdgpu_nbio_ras_sw_init() fails in amdgpu_ras_init(), the function returns directly without freeing the allocated con structure, leading to a memory leak.

Fix this by jumping to the release_con label to properly clean up the allocated memory before returning the error code.

Compile tested only. Issue found using a prototype static analysis tool and code review.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-45976"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-27T14:17:14Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix memory leak in amdgpu_ras_init()\n\nWhen amdgpu_nbio_ras_sw_init() fails in amdgpu_ras_init(), the function\nreturns directly without freeing the allocated con structure, leading\nto a memory leak.\n\nFix this by jumping to the release_con label to properly clean up the\nallocated memory before returning the error code.\n\nCompile tested only. Issue found using a prototype static analysis tool\nand code review.",
  "id": "GHSA-x3wv-3wj6-mvvv",
  "modified": "2026-06-16T03:30:33Z",
  "published": "2026-05-27T15:33:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45976"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2fef8c2ac67e7c1b0409d23653300b134c63e54c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3f43e7812b30d6b2e850218f9bb1dae60727fcef"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c11cd77a18115d2cd3f4b6915c4a537b6042f950"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ee41e5b63c8210525c936ee637a2c8d185ce873c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f8a5426652bdadd4a5cb48326d48abbdfebe8153"
    }
  ],
  "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.