CWE-401
AllowedMissing 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.
2179 vulnerabilities reference this CWE, most recent first.
GHSA-PHCQ-C45R-9F84
Vulnerability from github – Published: 2026-06-08 18:31 – Updated: 2026-09-08 09:35In the Linux kernel, the following vulnerability has been resolved:
isofs: validate Rock Ridge CE continuation extent against volume size
rock_continue() reads rs->cont_extent verbatim from the Rock Ridge CE record and passes it to sb_bread() without checking that the block number is within the mounted ISO 9660 volume. commit e595447e177b ("[PATCH] rock.c: handle corrupted directories") added cont_offset and cont_size rejection for the CE continuation but did not validate the extent block number itself. commit f54e18f1b831 ("isofs: Fix infinite looping over CE entries") later capped the CE chain length at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked.
With a crafted ISO mounted via udisks2 (desktop optical auto-mount) or via CAP_SYS_ADMIN mount, rs->cont_extent can therefore point at an out-of-range block or at blocks belonging to an adjacent filesystem on the same block device. sb_bread() on an out-of-range block returns NULL cleanly via the block layer EIO path, so there is no memory-safety violation. For in-range reads of adjacent- filesystem data, the CE buffer is parsed as Rock Ridge records and only the text of SL sub-records reaches userspace through readlink(), which makes the info-leak channel narrow and difficult to exploit; still, rejecting the malformed CE outright matches the rejection shape already present in the same function for cont_offset and cont_size.
Add an ISOFS_SB(sb)->s_nzones bounds check to rock_continue() next to the existing offset/size rejection, printing the same corrupted-directory-entry notice.
{
"affected": [],
"aliases": [
"CVE-2026-46303"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-08T17:16:48Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nisofs: validate Rock Ridge CE continuation extent against volume size\n\nrock_continue() reads rs-\u003econt_extent verbatim from the Rock Ridge CE\nrecord and passes it to sb_bread() without checking that the block\nnumber is within the mounted ISO 9660 volume. commit e595447e177b\n(\"[PATCH] rock.c: handle corrupted directories\") added cont_offset\nand cont_size rejection for the CE continuation but did not validate\nthe extent block number itself. commit f54e18f1b831 (\"isofs: Fix\ninfinite looping over CE entries\") later capped the CE chain length\nat RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked.\n\nWith a crafted ISO mounted via udisks2 (desktop optical auto-mount)\nor via CAP_SYS_ADMIN mount, rs-\u003econt_extent can therefore point at\nan out-of-range block or at blocks belonging to an adjacent\nfilesystem on the same block device. sb_bread() on an out-of-range\nblock returns NULL cleanly via the block layer EIO path, so there\nis no memory-safety violation. For in-range reads of adjacent-\nfilesystem data, the CE buffer is parsed as Rock Ridge records and\nonly the text of SL sub-records reaches userspace through\nreadlink(), which makes the info-leak channel narrow and difficult\nto exploit; still, rejecting the malformed CE outright matches the\nrejection shape already present in the same function for\ncont_offset and cont_size.\n\nAdd an ISOFS_SB(sb)-\u003es_nzones bounds check to rock_continue() next\nto the existing offset/size rejection, printing the same\ncorrupted-directory-entry notice.",
"id": "GHSA-phcq-c45r-9f84",
"modified": "2026-09-08T09:35:31Z",
"published": "2026-06-08T18:31:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46303"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/22b36fa081f38ab397c7697f9d539211b51a0cfc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8356fb821016797f5677cbeee5ddc0d32a95b4be"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a36d990f591320e9dd379ab30063ebfe91d47e1f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bf1bc673c587f5ef7e9c09b94aea7c5a7847d4d9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c9b37c8b73f6368e4750e5ccb0632c380b43c6e5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d582e12378bc1637f337622feef762f53c43fd57"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e69da8eeab74b4f4505024c38a17bce060fe7df8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ef048470c90bc8c1b8318bb2ce329da9ef64b9fe"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PHFQ-PPCX-5J3H
Vulnerability from github – Published: 2026-02-04 18:30 – Updated: 2026-03-17 21:31In the Linux kernel, the following vulnerability has been resolved:
intel_th: fix device leak on output open()
Make sure to drop the reference taken when looking up the th device during output device open() on errors and on close().
Note that a recent commit fixed the leak in a couple of open() error paths but not all of them, and the reference is still leaking on successful open().
{
"affected": [],
"aliases": [
"CVE-2026-23091"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-04T17:16:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nintel_th: fix device leak on output open()\n\nMake sure to drop the reference taken when looking up the th device\nduring output device open() on errors and on close().\n\nNote that a recent commit fixed the leak in a couple of open() error\npaths but not all of them, and the reference is still leaking on\nsuccessful open().",
"id": "GHSA-phfq-ppcx-5j3h",
"modified": "2026-03-17T21:31:40Z",
"published": "2026-02-04T18:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23091"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0fca16c5591534cc1fec8b6181277ee3a3d0f26c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/64015cbf06e8bb75b81ae95b997e847b55280f7f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/95fc36a234da24bbc5f476f8104a5a15f99ed3e3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/af4b9467296b9a16ebc008147238070236982b6d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b71e64ef7ff9443835d1333e3e80ab1e49e5209f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bf7785434b5d05d940d936b78925080950bd54dd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f9b059bda4276f2bb72cb98ec7875a747f042ea2"
}
],
"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-PHMH-WX44-P7VQ
Vulnerability from github – Published: 2023-01-13 00:30 – Updated: 2023-01-24 18:30A Missing Release of Memory after Effective Lifetime vulnerability in Flexible PIC Concentrator (FPC) of Juniper Networks Junos OS allows an adjacent, unauthenticated attacker from the same shared physical or logical network, to cause a heap memory leak and leading to FPC crash. On all Junos PTX Series and QFX10000 Series, when specific EVPN VXLAN Multicast packets are processed, an FPC heap memory leak is observed. The FPC memory usage can be monitored using the CLI command "show heap extensive". Following is an example output. ID Base Total(b) Free(b) Used(b) % Name Peak used % -- -------- --------- --------- --------- --- ----------- ----------- 0 37dcf000 3221225472 1694526368 1526699104 47 Kernel 47 1 17dcf000 1048576 1048576 0 0 TOE DMA 0 2 17ecf000 1048576 1048576 0 0 DMA 0 3 17fcf000 534773760 280968336 253805424 47 Packet DMA 47 This issue affects: Juniper Networks Junos OS PTX Series and QFX10000 Series 20.2 versions prior to 20.2R3-S6; 20.3 versions prior to 20.3R3-S6; 20.4 versions prior to 20.4R3-S4; 21.1 versions prior to 21.1R3-S3; 21.2 versions prior to 21.2R3-S1; 21.3 versions prior to 21.3R3; 21.4 versions prior to 21.4R3; 22.1 versions prior to 22.1R2; 22.2 versions prior to 22.2R2. This issue does not affect Juniper Networks Junos OS versions prior to 20.1R1 on PTX Series and QFX10000 Series.
{
"affected": [],
"aliases": [
"CVE-2023-22414"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-13T00:15:00Z",
"severity": "MODERATE"
},
"details": "A Missing Release of Memory after Effective Lifetime vulnerability in Flexible PIC Concentrator (FPC) of Juniper Networks Junos OS allows an adjacent, unauthenticated attacker from the same shared physical or logical network, to cause a heap memory leak and leading to FPC crash. On all Junos PTX Series and QFX10000 Series, when specific EVPN VXLAN Multicast packets are processed, an FPC heap memory leak is observed. The FPC memory usage can be monitored using the CLI command \"show heap extensive\". Following is an example output. ID Base Total(b) Free(b) Used(b) % Name Peak used % -- -------- --------- --------- --------- --- ----------- ----------- 0 37dcf000 3221225472 1694526368 1526699104 47 Kernel 47 1 17dcf000 1048576 1048576 0 0 TOE DMA 0 2 17ecf000 1048576 1048576 0 0 DMA 0 3 17fcf000 534773760 280968336 253805424 47 Packet DMA 47 This issue affects: Juniper Networks Junos OS PTX Series and QFX10000 Series 20.2 versions prior to 20.2R3-S6; 20.3 versions prior to 20.3R3-S6; 20.4 versions prior to 20.4R3-S4; 21.1 versions prior to 21.1R3-S3; 21.2 versions prior to 21.2R3-S1; 21.3 versions prior to 21.3R3; 21.4 versions prior to 21.4R3; 22.1 versions prior to 22.1R2; 22.2 versions prior to 22.2R2. This issue does not affect Juniper Networks Junos OS versions prior to 20.1R1 on PTX Series and QFX10000 Series.",
"id": "GHSA-phmh-wx44-p7vq",
"modified": "2023-01-24T18:30:34Z",
"published": "2023-01-13T00:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22414"
},
{
"type": "WEB",
"url": "https://kb.juniper.net/JSA70210"
}
],
"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-PHX3-79H9-XHVQ
Vulnerability from github – Published: 2024-05-17 15:31 – Updated: 2024-10-29 21:30In the Linux kernel, the following vulnerability has been resolved:
dmaengine: fsl-qdma: Fix a memory leak related to the queue command DMA
This dma_alloc_coherent() is undone neither in the remove function, nor in the error handling path of fsl_qdma_probe().
Switch to the managed version to fix both issues.
{
"affected": [],
"aliases": [
"CVE-2024-35833"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-17T14:15:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: fsl-qdma: Fix a memory leak related to the queue command DMA\n\nThis dma_alloc_coherent() is undone neither in the remove function, nor in\nthe error handling path of fsl_qdma_probe().\n\nSwitch to the managed version to fix both issues.",
"id": "GHSA-phx3-79h9-xhvq",
"modified": "2024-10-29T21:30:45Z",
"published": "2024-05-17T15:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35833"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/15eb996d7d13cb72a16389231945ada8f0fef2c3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/198270de9d8eb3b5d5f030825ea303ef95285d24"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1c75fe450b5200c78f4a102a0eb8e15d8f1ccda8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/25ab4d72eb7cbfa0f3d97a139a9b2bfcaa72dd59"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3aa58cb51318e329d203857f7a191678e60bb714"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5cd8a51517ce15edbdcea4fc74c4c127ddaa1bd6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ae6769ba51417c1c86fb645812d5bff455eee802"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.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-PJ5F-G5WQ-XH99
Vulnerability from github – Published: 2025-03-18 21:31 – Updated: 2025-03-18 21:32In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix memory leak in error flow for subscribe event routine
In case the second xa_insert() fails, the obj_event is not released. Fix the error unwind flow to free that memory to avoid a memory leak.
{
"affected": [],
"aliases": [
"CVE-2022-49206"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:00:57Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix memory leak in error flow for subscribe event routine\n\nIn case the second xa_insert() fails, the obj_event is not released. Fix\nthe error unwind flow to free that memory to avoid a memory leak.",
"id": "GHSA-pj5f-g5wq-xh99",
"modified": "2025-03-18T21:32:00Z",
"published": "2025-03-18T21:31:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49206"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0174a89663a5ef83617da15bf24c0af2f62b6c7f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/087f9c3f2309ed183f7e4b85ae57121d8663224d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/414b4e8738484379f18d6c4e780787c80dbf8a2c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8dd392e352d3269938fea32061a74655a613f929"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c98d903ff9e79c210beddea4e6bc15ac38e25aa5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d66498507801fd9a20307a15a0814a0a016c3cde"
}
],
"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-PJFG-W894-9457
Vulnerability from github – Published: 2026-09-22 00:30 – Updated: 2026-09-22 00:30vLLM Mooncake connector through 0.29.0 fails to properly manage GPU KV cache block ownership when concurrent child requests share a single transfer ID in prefill/decode disaggregated deployments. Attackers can trigger GPU memory exhaustion by submitting completion requests with multiple prompts, causing orphaned KV cache blocks to accumulate until process restart and eventually preventing legitimate requests from executing.
{
"affected": [],
"aliases": [
"CVE-2026-94627"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-21T22:17:01Z",
"severity": "HIGH"
},
"details": "vLLM Mooncake connector through 0.29.0 fails to properly manage GPU KV cache block ownership when concurrent child requests share a single transfer ID in prefill/decode disaggregated deployments. Attackers can trigger GPU memory exhaustion by submitting completion requests with multiple prompts, causing orphaned KV cache blocks to accumulate until process restart and eventually preventing legitimate requests from executing.",
"id": "GHSA-pjfg-w894-9457",
"modified": "2026-09-22T00:30:55Z",
"published": "2026-09-22T00:30:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94627"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/pull/49796"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/blob/v0.29.0/vllm/distributed/kv_transfer/kv_connector/v1/mooncake/mooncake_connector.py#L1978-L1989"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/vllm-through-0.29.0-gpu-kv-cache-leak-via-mooncake-transfer-id-collision"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-PJMJ-JGGX-2J9H
Vulnerability from github – Published: 2025-09-16 18:31 – Updated: 2025-12-02 00:31In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix xid leak in cifs_create()
If the cifs already shutdown, we should free the xid before return, otherwise, the xid will be leaked.
{
"affected": [],
"aliases": [
"CVE-2022-50351"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-16T17:15:34Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix xid leak in cifs_create()\n\nIf the cifs already shutdown, we should free the xid before return,\notherwise, the xid will be leaked.",
"id": "GHSA-pjmj-jggx-2j9h",
"modified": "2025-12-02T00:31:10Z",
"published": "2025-09-16T18:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50351"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/593d877c39aa9f3fe1a4b5b022492886d7d700ec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/92aa09c86ef297976a3c27c6574c0839418dc2c4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fee0fb1f15054bb6a0ede452acb42da5bef4d587"
}
],
"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-PJRJ-H4FG-6GM4
Vulnerability from github – Published: 2023-12-05 23:42 – Updated: 2023-12-05 23:42Impact
The tokio-boring library in version 4.0.0 is affected by a memory leak issue that can lead to excessive resource consumption and potential DoS by resource exhaustion. The set_ex_data function used by the library did not deallocate memory used by pre-existing data in memory each time after completing a TLS connection causing the program to consume more resources with each new connection.
Patches
The issue is fixed in version 4.1.0 of tokio-boring.
References
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "tokio-boring"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.1.0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"4.0.0"
]
}
],
"aliases": [
"CVE-2023-6180"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-401",
"CWE-404"
],
"github_reviewed": true,
"github_reviewed_at": "2023-12-05T23:42:49Z",
"nvd_published_at": "2023-12-05T15:15:08Z",
"severity": "MODERATE"
},
"details": "### Impact\nThe tokio-boring library in version 4.0.0 is affected by a memory leak issue that can lead to excessive resource consumption and potential DoS by resource exhaustion. The `set_ex_data` function used by the library did not deallocate memory used by pre-existing data in memory each time after completing a TLS connection causing the program to consume more resources with each new connection.\n\n### Patches\nThe issue is fixed in version 4.1.0 of tokio-boring.\n\n### References\n[CVE-2023-6180 at cve.org](https://www.cve.org/CVERecord?id=CVE-2023-6180)\n",
"id": "GHSA-pjrj-h4fg-6gm4",
"modified": "2023-12-05T23:42:49Z",
"published": "2023-12-05T23:42:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cloudflare/boring/security/advisories/GHSA-pjrj-h4fg-6gm4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6180"
},
{
"type": "WEB",
"url": "https://github.com/cloudflare/boring/commit/a32783374f2682e6949fdb713910b1b9f103d3ed"
},
{
"type": "PACKAGE",
"url": "https://github.com/cloudflare/boring"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "tokio-boring vulnerable to resource exhaustion via memory leak"
}
GHSA-PM49-6J2C-6857
Vulnerability from github – Published: 2025-01-08 18:30 – Updated: 2025-01-10 00:30In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix handling of plane refcount
[Why] The mechanism to backup and restore plane states doesn't maintain refcount, which can cause issues if the refcount of the plane changes in between backup and restore operations, such as memory leaks if the refcount was supposed to go down, or double frees / invalid memory accesses if the refcount was supposed to go up.
[How] Cache and re-apply current refcount when restoring plane states.
{
"affected": [],
"aliases": [
"CVE-2024-56775"
],
"database_specific": {
"cwe_ids": [
"CWE-401",
"CWE-415"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-08T18:15:18Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix handling of plane refcount\n\n[Why]\nThe mechanism to backup and restore plane states doesn\u0027t maintain\nrefcount, which can cause issues if the refcount of the plane changes\nin between backup and restore operations, such as memory leaks if the\nrefcount was supposed to go down, or double frees / invalid memory\naccesses if the refcount was supposed to go up.\n\n[How]\nCache and re-apply current refcount when restoring plane states.",
"id": "GHSA-pm49-6j2c-6857",
"modified": "2025-01-10T00:30:35Z",
"published": "2025-01-08T18:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56775"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/27227a234c1487cb7a684615f0749c455218833a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8cb2f6793845f135b28361ba8e96901cae3e5790"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PM4X-JF7F-JMQ6
Vulnerability from github – Published: 2026-05-05 18:33 – Updated: 2026-05-21 00:30In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal()
There's issue as follows: ... EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost
EXT4-fs (mmcblk0p1): error count since last fsck: 1 EXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760 EXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760 ...
According to the log analysis, blocks are always requested from the corrupted block group. This may happen as follows: ext4_mb_find_by_goal ext4_mb_load_buddy ext4_mb_load_buddy_gfp ext4_mb_init_cache ext4_read_block_bitmap_nowait ext4_wait_block_bitmap ext4_validate_block_bitmap if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp)) return -EFSCORRUPTED; // There's no logs. if (err) return err; // Will return error ext4_lock_group(ac->ac_sb, group); if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) // Unreachable goto out;
After commit 9008a58e5dce ("ext4: make the bitmap read routines return real error codes") merged, Commit 163a203ddb36 ("ext4: mark block group as corrupt on block bitmap error") is no real solution for allocating blocks from corrupted block groups. This is because if 'EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)' is true, then 'ext4_mb_load_buddy()' may return an error. This means that the block allocation will fail. Therefore, check block group if corrupted when ext4_mb_load_buddy() returns error.
{
"affected": [],
"aliases": [
"CVE-2026-43068"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-05T16:16:16Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: avoid allocate block from corrupted group in ext4_mb_find_by_goal()\n\nThere\u0027s issue as follows:\n...\nEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117\nEXT4-fs (mmcblk0p1): This should not happen!! Data will be lost\n\nEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117\nEXT4-fs (mmcblk0p1): This should not happen!! Data will be lost\n\nEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117\nEXT4-fs (mmcblk0p1): This should not happen!! Data will be lost\n\nEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117\nEXT4-fs (mmcblk0p1): This should not happen!! Data will be lost\n\nEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117\nEXT4-fs (mmcblk0p1): This should not happen!! Data will be lost\n\nEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117\nEXT4-fs (mmcblk0p1): This should not happen!! Data will be lost\n\nEXT4-fs (mmcblk0p1): error count since last fsck: 1\nEXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760\nEXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760\n...\n\nAccording to the log analysis, blocks are always requested from the\ncorrupted block group. This may happen as follows:\next4_mb_find_by_goal\n ext4_mb_load_buddy\n ext4_mb_load_buddy_gfp\n ext4_mb_init_cache\n ext4_read_block_bitmap_nowait\n ext4_wait_block_bitmap\n ext4_validate_block_bitmap\n if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp))\n return -EFSCORRUPTED; // There\u0027s no logs.\n if (err)\n return err; // Will return error\next4_lock_group(ac-\u003eac_sb, group);\n if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b-\u003ebd_info))) // Unreachable\n goto out;\n\nAfter commit 9008a58e5dce (\"ext4: make the bitmap read routines return\nreal error codes\") merged, Commit 163a203ddb36 (\"ext4: mark block group\nas corrupt on block bitmap error\") is no real solution for allocating\nblocks from corrupted block groups. This is because if\n\u0027EXT4_MB_GRP_BBITMAP_CORRUPT(e4b-\u003ebd_info)\u0027 is true, then\n\u0027ext4_mb_load_buddy()\u0027 may return an error. This means that the block\nallocation will fail.\nTherefore, check block group if corrupted when ext4_mb_load_buddy()\nreturns error.",
"id": "GHSA-pm4x-jf7f-jmq6",
"modified": "2026-05-21T00:30:26Z",
"published": "2026-05-05T18:33:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43068"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0b84571c886719823d537f05f4f07cad6357c4b7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1895f7904be71c48f1e6f338b28f24dabd6b8aeb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1c0d7c4cde38a887c6d74e0c89ddb25226943c78"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2d31a5073f86a177edf44015e0dedb0c47cfd6d8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/46066e3a06647c5b186cc6334409722622d05c44"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9370207b36d26e45a8c8ef0500706d37036edd6b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fea6b2e250ff48f10d166011b57a8516ae5438c9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ffc0a282462d45fee5957621be5afa29752f3b6d"
}
],
"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
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
Use an abstraction library to abstract away risky APIs. Not a complete solution.
Mitigation
Consider using the Boehm-Demers-Weiser garbage collector (bdwgc), which can help avoid leaks.
No CAPEC attack patterns related to this CWE.