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.
2125 vulnerabilities reference this CWE, most recent first.
GHSA-72JM-3MP2-PJW5
Vulnerability from github – Published: 2022-05-24 17:45 – Updated: 2022-05-24 17:45A flaw was found in Privoxy in versions before 3.0.29. Memory leaks in the client-tags CGI handler when client tags are configured and memory allocations fail can lead to a system crash.
{
"affected": [],
"aliases": [
"CVE-2021-20214"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-03-25T19:15:00Z",
"severity": "HIGH"
},
"details": "A flaw was found in Privoxy in versions before 3.0.29. Memory leaks in the client-tags CGI handler when client tags are configured and memory allocations fail can lead to a system crash.",
"id": "GHSA-72jm-3mp2-pjw5",
"modified": "2022-05-24T17:45:22Z",
"published": "2022-05-24T17:45:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20214"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1928742"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202107-16"
},
{
"type": "WEB",
"url": "https://www.privoxy.org/3.0.29/user-manual/whatsnew.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-72MW-QPH4-CR4C
Vulnerability from github – Published: 2025-09-22 21:30 – Updated: 2025-09-22 21:30In the Linux kernel, the following vulnerability has been resolved:
brcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path
This avoids leaking memory if brcmf_chip_get_raminfo fails. Note that the CLM blob is released in the device remove path.
{
"affected": [],
"aliases": [
"CVE-2022-49263"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:03Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbrcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path\n\nThis avoids leaking memory if brcmf_chip_get_raminfo fails. Note that\nthe CLM blob is released in the device remove path.",
"id": "GHSA-72mw-qph4-cr4c",
"modified": "2025-09-22T21:30:16Z",
"published": "2025-09-22T21:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49263"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0347bdfdb1529994ac3a4cb425087c477a74eb2c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4e0b507597e1a86e9b4c056ab274c427223cf8ea"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5e90f0f3ead014867dade7a22f93958119f5efab"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a88337a06966f2d733ad9a97714b874469133f14"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d0ab87f8dcdfe72dc1d763be3392c1fc51a1ace2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f3820ddaf4f3ac80c7401ccc6a42e663c9317f31"
}
],
"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-72QV-726V-82FQ
Vulnerability from github – Published: 2022-05-24 17:36 – Updated: 2022-05-24 17:36In certain configurations on version 13.1.3.4, when a BIG-IP AFM HTTP security profile is applied to a virtual server and the BIG-IP system receives a request with specific characteristics, the connection is reset and the Traffic Management Microkernel (TMM) leaks memory.
{
"affected": [],
"aliases": [
"CVE-2020-27713"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-11T19:15:00Z",
"severity": "HIGH"
},
"details": "In certain configurations on version 13.1.3.4, when a BIG-IP AFM HTTP security profile is applied to a virtual server and the BIG-IP system receives a request with specific characteristics, the connection is reset and the Traffic Management Microkernel (TMM) leaks memory.",
"id": "GHSA-72qv-726v-82fq",
"modified": "2022-05-24T17:36:04Z",
"published": "2022-05-24T17:36:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27713"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K37960100"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-72QW-2VP3-GVG9
Vulnerability from github – Published: 2024-10-11 18:32 – Updated: 2024-11-15 18:30In Eclipse Mosquitto up to version 2.0.18a, an attacker can achieve memory leaking, segmentation fault or heap-use-after-free by sending specific sequences of "CONNECT", "DISCONNECT", "SUBSCRIBE", "UNSUBSCRIBE" and "PUBLISH" packets.
{
"affected": [],
"aliases": [
"CVE-2024-8376"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-11T16:15:14Z",
"severity": "HIGH"
},
"details": "In Eclipse Mosquitto up to version 2.0.18a, an attacker can achieve memory leaking, segmentation fault or heap-use-after-free by sending specific sequences of \"CONNECT\", \"DISCONNECT\", \"SUBSCRIBE\", \"UNSUBSCRIBE\" and \"PUBLISH\" packets.",
"id": "GHSA-72qw-2vp3-gvg9",
"modified": "2024-11-15T18:30:47Z",
"published": "2024-10-11T18:32:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8376"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-mosquitto/mosquitto/commit/1914b3ee2a18102d0a94cbdbbfeae1afa03edd17"
},
{
"type": "WEB",
"url": "https://github.com/eclipse/mosquitto/releases/tag/v2.0.19"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/cve-assignement/-/issues/26"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/216"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/217"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/218"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/227"
},
{
"type": "WEB",
"url": "https://mosquitto.org"
}
],
"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:L/UI:N/VC:H/VI:L/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-72VP-MGCV-889W
Vulnerability from github – Published: 2025-10-01 12:30 – Updated: 2026-01-16 21:30In the Linux kernel, the following vulnerability has been resolved:
MIPS: vpe-mt: fix possible memory leak while module exiting
Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, it need be freed when module exiting, call put_device() to give up reference, so that it can be freed in kobject_cleanup() when the refcount hit to 0. The vpe_device is static, so remove kfree() from vpe_device_release().
{
"affected": [],
"aliases": [
"CVE-2022-50462"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-01T12:15:39Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nMIPS: vpe-mt: fix possible memory leak while module exiting\n\nAfer commit 1fa5ae857bb1 (\"driver core: get rid of struct device\u0027s\nbus_id string array\"), the name of device is allocated dynamically,\nit need be freed when module exiting, call put_device() to give up\nreference, so that it can be freed in kobject_cleanup() when the\nrefcount hit to 0. The vpe_device is static, so remove kfree() from\nvpe_device_release().",
"id": "GHSA-72vp-mgcv-889w",
"modified": "2026-01-16T21:30:29Z",
"published": "2025-10-01T12:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50462"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/170e9913c2ed5cfc37c0adf0fdbd368d2d8d8168"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/48d42f4464d713fbdd79f334fdcd6e5be534cc67"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5822e8cc84ee37338ab0bdc3124f6eec04dc232d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/851ae5640875f06494e40002cd503b11a634c6fb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9d180e0bb21c57bd6cca2adeb672d3b522e910b5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ab3d47c1fd0202821abd473ca87580faafd47847"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b191dde84e40624d5577f64db0ec922c5c0ec57c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b3325a443525e3b89151879b834519b21c5e3011"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e820a8192ff68570100347855b567512aec43819"
}
],
"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-733M-QP96-W42H
Vulnerability from github – Published: 2025-10-01 09:30 – Updated: 2025-12-12 21:31In the Linux kernel, the following vulnerability has been resolved:
spi: spi-qpic-snand: unregister ECC engine on probe error and device remove
The on-host hardware ECC engine remains registered both when the spi_register_controller() function returns with an error and also on device removal.
Change the qcom_spi_probe() function to unregister the engine on the error path, and add the missing unregistering call to qcom_spi_remove() to avoid possible use-after-free issues.
{
"affected": [],
"aliases": [
"CVE-2025-39893"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-01T08:15:31Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nspi: spi-qpic-snand: unregister ECC engine on probe error and device remove\n\nThe on-host hardware ECC engine remains registered both when\nthe spi_register_controller() function returns with an error\nand also on device removal.\n\nChange the qcom_spi_probe() function to unregister the engine\non the error path, and add the missing unregistering call to\nqcom_spi_remove() to avoid possible use-after-free issues.",
"id": "GHSA-733m-qp96-w42h",
"modified": "2025-12-12T21:31:32Z",
"published": "2025-10-01T09:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39893"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1991a458528588ff34e98b6365362560d208710f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e4de48e66af17547727bb2e4b1867952817edff7"
}
],
"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-73CW-J3WH-RF6G
Vulnerability from github – Published: 2025-05-08 09:30 – Updated: 2025-11-10 18:30In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix kmemleak warning for percpu hashmap
Vlad Poenaru reported the following kmemleak issue:
unreferenced object 0x606fd7c44ac8 (size 32): backtrace (crc 0): pcpu_alloc_noprof+0x730/0xeb0 bpf_map_alloc_percpu+0x69/0xc0 prealloc_init+0x9d/0x1b0 htab_map_alloc+0x363/0x510 map_create+0x215/0x3a0 __sys_bpf+0x16b/0x3e0 __x64_sys_bpf+0x18/0x20 do_syscall_64+0x7b/0x150 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Further investigation shows the reason is due to not 8-byte aligned store of percpu pointer in htab_elem_set_ptr(): (void __percpu *)(l->key + key_size) = pptr;
Note that the whole htab_elem alignment is 8 (for x86_64). If the key_size is 4, that means pptr is stored in a location which is 4 byte aligned but not 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based on 8 byte stride, so it won't detect above pptr, hence reporting the memory leak.
In htab_map_alloc(), we already have
htab->elem_size = sizeof(struct htab_elem) +
round_up(htab->map.key_size, 8);
if (percpu)
htab->elem_size += sizeof(void *);
else
htab->elem_size += round_up(htab->map.value_size, 8);
So storing pptr with 8-byte alignment won't cause any problem and can fix kmemleak too.
The issue can be reproduced with bpf selftest as well: 1. Enable CONFIG_DEBUG_KMEMLEAK config 2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c. The purpose is to keep map available so kmemleak can be detected. 3. run './test_progs -t for_each/hash_map &' and a kmemleak should be reported.
{
"affected": [],
"aliases": [
"CVE-2025-37807"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-08T07:15:51Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix kmemleak warning for percpu hashmap\n\nVlad Poenaru reported the following kmemleak issue:\n\n unreferenced object 0x606fd7c44ac8 (size 32):\n backtrace (crc 0):\n pcpu_alloc_noprof+0x730/0xeb0\n bpf_map_alloc_percpu+0x69/0xc0\n prealloc_init+0x9d/0x1b0\n htab_map_alloc+0x363/0x510\n map_create+0x215/0x3a0\n __sys_bpf+0x16b/0x3e0\n __x64_sys_bpf+0x18/0x20\n do_syscall_64+0x7b/0x150\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nFurther investigation shows the reason is due to not 8-byte aligned\nstore of percpu pointer in htab_elem_set_ptr():\n *(void __percpu **)(l-\u003ekey + key_size) = pptr;\n\nNote that the whole htab_elem alignment is 8 (for x86_64). If the key_size\nis 4, that means pptr is stored in a location which is 4 byte aligned but\nnot 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based\non 8 byte stride, so it won\u0027t detect above pptr, hence reporting the memory\nleak.\n\nIn htab_map_alloc(), we already have\n\n htab-\u003eelem_size = sizeof(struct htab_elem) +\n round_up(htab-\u003emap.key_size, 8);\n if (percpu)\n htab-\u003eelem_size += sizeof(void *);\n else\n htab-\u003eelem_size += round_up(htab-\u003emap.value_size, 8);\n\nSo storing pptr with 8-byte alignment won\u0027t cause any problem and can fix\nkmemleak too.\n\nThe issue can be reproduced with bpf selftest as well:\n 1. Enable CONFIG_DEBUG_KMEMLEAK config\n 2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c.\n The purpose is to keep map available so kmemleak can be detected.\n 3. run \u0027./test_progs -t for_each/hash_map \u0026\u0027 and a kmemleak should be reported.",
"id": "GHSA-73cw-j3wh-rf6g",
"modified": "2025-11-10T18:30:31Z",
"published": "2025-05-08T09:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37807"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/11ba7ce076e5903e7bdc1fd1498979c331b3c286"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f1c29aa1934177349c17e3c32e68ec38a7a56df"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7758e308aeda1038aba1944f7302d34161b3effe"
}
],
"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-73GQ-MXP2-9HWR
Vulnerability from github – Published: 2025-09-16 15:32 – Updated: 2025-12-03 18:30In the Linux kernel, the following vulnerability has been resolved:
driver: soc: xilinx: fix memory leak in xlnx_add_cb_for_notify_event()
The kfree() should be called when memory fails to be allocated for cb_data in xlnx_add_cb_for_notify_event(), otherwise there will be a memory leak, so add kfree() to fix it.
{
"affected": [],
"aliases": [
"CVE-2023-53267"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-16T08:15:35Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndriver: soc: xilinx: fix memory leak in xlnx_add_cb_for_notify_event()\n\nThe kfree() should be called when memory fails to be allocated for\ncb_data in xlnx_add_cb_for_notify_event(), otherwise there will be\na memory leak, so add kfree() to fix it.",
"id": "GHSA-73gq-mxp2-9hwr",
"modified": "2025-12-03T18:30:20Z",
"published": "2025-09-16T15:32:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53267"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1bea534991b9b35c41848a397666ada436456beb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9dfb6c784e385f6e61994bb4e16ce12f3e4940be"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d35290addcbac94b076babe0a798a8c043421812"
}
],
"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-73J8-R39C-JXP6
Vulnerability from github – Published: 2024-07-16 15:30 – Updated: 2024-07-24 18:31In the Linux kernel, the following vulnerability has been resolved:
block: release rq qos structures for queue without disk
blkcg_init_queue() may add rq qos structures to request queue, previously blk_cleanup_queue() calls rq_qos_exit() to release them, but commit 8e141f9eb803 ("block: drain file system I/O on del_gendisk") moves rq_qos_exit() into del_gendisk(), so memory leak is caused because queues may not have disk, such as un-present scsi luns, nvme admin queue, ...
Fixes the issue by adding rq_qos_exit() to blk_cleanup_queue() back.
BTW, v5.18 won't need this patch any more since we move blkcg_init_queue()/blkcg_exit_queue() into disk allocation/release handler, and patches have been in for-5.18/block.
{
"affected": [],
"aliases": [
"CVE-2022-48846"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-16T13:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: release rq qos structures for queue without disk\n\nblkcg_init_queue() may add rq qos structures to request queue, previously\nblk_cleanup_queue() calls rq_qos_exit() to release them, but commit\n8e141f9eb803 (\"block: drain file system I/O on del_gendisk\")\nmoves rq_qos_exit() into del_gendisk(), so memory leak is caused\nbecause queues may not have disk, such as un-present scsi luns, nvme\nadmin queue, ...\n\nFixes the issue by adding rq_qos_exit() to blk_cleanup_queue() back.\n\nBTW, v5.18 won\u0027t need this patch any more since we move\nblkcg_init_queue()/blkcg_exit_queue() into disk allocation/release\nhandler, and patches have been in for-5.18/block.",
"id": "GHSA-73j8-r39c-jxp6",
"modified": "2024-07-24T18:31:16Z",
"published": "2024-07-16T15:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48846"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/60c2c8e2ef3a3ec79de8cbc80a06ca0c21df8c29"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d4ad8736ac982111bb0be8306bf19c8207f6600e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/daaca3522a8e67c46e39ef09c1d542e866f85f3b"
}
],
"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-73JC-99JJ-CH5V
Vulnerability from github – Published: 2026-04-03 18:31 – Updated: 2026-05-20 15:35In the Linux kernel, the following vulnerability has been resolved:
sunrpc: fix cache_request leak in cache_release
When a reader's file descriptor is closed while in the middle of reading a cache_request (rp->offset != 0), cache_release() decrements the request's readers count but never checks whether it should free the request.
In cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the cache_request is removed from the queue and freed along with its buffer and cache_head reference. cache_release() lacks this cleanup.
The only other path that frees requests with readers == 0 is cache_dequeue(), but it runs only when CACHE_PENDING transitions from set to clear. If that transition already happened while readers was still non-zero, cache_dequeue() will have skipped the request, and no subsequent call will clean it up.
Add the same cleanup logic from cache_read() to cache_release(): after decrementing readers, check if it reached 0 with CACHE_PENDING clear, and if so, dequeue and free the cache_request.
{
"affected": [],
"aliases": [
"CVE-2026-31400"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-03T16:16:38Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: fix cache_request leak in cache_release\n\nWhen a reader\u0027s file descriptor is closed while in the middle of reading\na cache_request (rp-\u003eoffset != 0), cache_release() decrements the\nrequest\u0027s readers count but never checks whether it should free the\nrequest.\n\nIn cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the\ncache_request is removed from the queue and freed along with its buffer\nand cache_head reference. cache_release() lacks this cleanup.\n\nThe only other path that frees requests with readers == 0 is\ncache_dequeue(), but it runs only when CACHE_PENDING transitions from\nset to clear. If that transition already happened while readers was\nstill non-zero, cache_dequeue() will have skipped the request, and no\nsubsequent call will clean it up.\n\nAdd the same cleanup logic from cache_read() to cache_release(): after\ndecrementing readers, check if it reached 0 with CACHE_PENDING clear,\nand if so, dequeue and free the cache_request.",
"id": "GHSA-73jc-99jj-ch5v",
"modified": "2026-05-20T15:35:22Z",
"published": "2026-04-03T18:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31400"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/17ad31b3a43b72aec3a3d83605891e1397d0d065"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1dfedb293943e491379c9302b428e6f920a73d12"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/301670dcd098c1fe5c2fe90fb3c7a8f4814d2351"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/373457de14281c1fc7cace6fc4c8a267fc176673"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/41f6ba6c98a618043d2cd71030bf9a752dfab8b2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7bcd5e318876ac638c8ceade7a648e76ac8c48e1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be5c35960e5ead70862736161836e2d1bc7352dc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f18c1f2a88ca91357916997cdb0f7adaf14fc497"
}
],
"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.