CWE-416
AllowedUse After Free
Abstraction: Variant · Status: Stable
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
9858 vulnerabilities reference this CWE, most recent first.
GHSA-C77M-WH63-VHCH
Vulnerability from github – Published: 2024-07-23 09:30 – Updated: 2025-11-04 00:30In the Linux kernel, the following vulnerability has been resolved:
filelock: Remove locks reliably when fcntl/close race is detected
When fcntl_setlk() races with close(), it removes the created lock with do_lock_file_wait(). However, LSMs can allow the first do_lock_file_wait() that created the lock while denying the second do_lock_file_wait() that tries to remove the lock. Separately, posix_lock_file() could also fail to remove a lock due to GFP_KERNEL allocation failure (when splitting a range in the middle).
After the bug has been triggered, use-after-free reads will occur in lock_get_status() when userspace reads /proc/locks. This can likely be used to read arbitrary kernel memory, but can't corrupt kernel memory.
Fix it by calling locks_remove_posix() instead, which is designed to reliably get rid of POSIX locks associated with the given file and files_struct and is also used by filp_flush().
{
"affected": [],
"aliases": [
"CVE-2024-41012"
],
"database_specific": {
"cwe_ids": [
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-23T08:15:01Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfilelock: Remove locks reliably when fcntl/close race is detected\n\nWhen fcntl_setlk() races with close(), it removes the created lock with\ndo_lock_file_wait().\nHowever, LSMs can allow the first do_lock_file_wait() that created the lock\nwhile denying the second do_lock_file_wait() that tries to remove the lock.\nSeparately, posix_lock_file() could also fail to\nremove a lock due to GFP_KERNEL allocation failure (when splitting a range\nin the middle).\n\nAfter the bug has been triggered, use-after-free reads will occur in\nlock_get_status() when userspace reads /proc/locks. This can likely be used\nto read arbitrary kernel memory, but can\u0027t corrupt kernel memory.\n\nFix it by calling locks_remove_posix() instead, which is designed to\nreliably get rid of POSIX locks associated with the given file and\nfiles_struct and is also used by filp_flush().",
"id": "GHSA-c77m-wh63-vhch",
"modified": "2025-11-04T00:30:58Z",
"published": "2024-07-23T09:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41012"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3cad1bc010416c6dd780643476bc59ed742436b9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/52c87ab18c76c14d7209646ccb3283b3f5d87b22"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5661b9c7ec189406c2dde00837aaa4672efb6240"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5f5d0799eb0a01d550c21b7894e26b2d9db55763"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b6d223942c34057fdfd8f149e763fa823731b224"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d30ff33040834c3b9eee29740acd92f9c7ba2250"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dc2ce1dfceaa0767211a9d963ddb029ab21c4235"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ef8fc41cd6f95f9a4a3470f085aecf350569a0b3"
},
{
"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:H/PR:L/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C7CR-CH33-3XR3
Vulnerability from github – Published: 2025-09-22 21:30 – Updated: 2026-06-19 15:33In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work
The brcmf_btcoex_detach() only shuts down the btcoex timer, if the flag timer_on is false. However, the brcmf_btcoex_timerfunc(), which runs as timer handler, sets timer_on to false. This creates critical race conditions:
1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc() is executing, it may observe timer_on as false and skip the call to timer_shutdown_sync().
2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info worker after the cancel_work_sync() has been executed, resulting in use-after-free bugs.
The use-after-free bugs occur in two distinct scenarios, depending on the timing of when the brcmf_btcoex_info struct is freed relative to the execution of its worker thread.
Scenario 1: Freed before the worker is scheduled
The brcmf_btcoex_info is deallocated before the worker is scheduled. A race condition can occur when schedule_work(&bt_local->work) is called after the target memory has been freed. The sequence of events is detailed below:
CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | kfree(cfg->btcoex); // FREE | | schedule_work(&bt_local->work); // USE
Scenario 2: Freed after the worker is scheduled
The brcmf_btcoex_info is freed after the worker has been scheduled but before or during its execution. In this case, statements within the brcmf_btcoex_handler() — such as the container_of macro and subsequent dereferences of the brcmf_btcoex_info object will cause a use-after-free access. The following timeline illustrates this scenario:
CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | schedule_work(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmf_btcoex_handler() // Worker / | btci = container_of(....); // USE The kfree() above could | ... also occur at any point | btci-> // USE during the worker's execution| / |
To resolve the race conditions, drop the conditional check and call timer_shutdown_sync() directly. It can deactivate the timer reliably, regardless of its current state. Once stopped, the timer_on state is then set to false.
{
"affected": [],
"aliases": [
"CVE-2025-39863"
],
"database_specific": {
"cwe_ids": [
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-19T16:15:45Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work\n\nThe brcmf_btcoex_detach() only shuts down the btcoex timer, if the\nflag timer_on is false. However, the brcmf_btcoex_timerfunc(), which\nruns as timer handler, sets timer_on to false. This creates critical\nrace conditions:\n\n1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc()\nis executing, it may observe timer_on as false and skip the call to\ntimer_shutdown_sync().\n\n2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info\nworker after the cancel_work_sync() has been executed, resulting in\nuse-after-free bugs.\n\nThe use-after-free bugs occur in two distinct scenarios, depending on\nthe timing of when the brcmf_btcoex_info struct is freed relative to\nthe execution of its worker thread.\n\nScenario 1: Freed before the worker is scheduled\n\nThe brcmf_btcoex_info is deallocated before the worker is scheduled.\nA race condition can occur when schedule_work(\u0026bt_local-\u003ework) is\ncalled after the target memory has been freed. The sequence of events\nis detailed below:\n\nCPU0 | CPU1\nbrcmf_btcoex_detach | brcmf_btcoex_timerfunc\n | bt_local-\u003etimer_on = false;\n if (cfg-\u003ebtcoex-\u003etimer_on) |\n ... |\n cancel_work_sync(); |\n ... |\n kfree(cfg-\u003ebtcoex); // FREE |\n | schedule_work(\u0026bt_local-\u003ework); // USE\n\nScenario 2: Freed after the worker is scheduled\n\nThe brcmf_btcoex_info is freed after the worker has been scheduled\nbut before or during its execution. In this case, statements within\nthe brcmf_btcoex_handler() \u2014 such as the container_of macro and\nsubsequent dereferences of the brcmf_btcoex_info object will cause\na use-after-free access. The following timeline illustrates this\nscenario:\n\nCPU0 | CPU1\nbrcmf_btcoex_detach | brcmf_btcoex_timerfunc\n | bt_local-\u003etimer_on = false;\n if (cfg-\u003ebtcoex-\u003etimer_on) |\n ... |\n cancel_work_sync(); |\n ... | schedule_work(); // Reschedule\n |\n kfree(cfg-\u003ebtcoex); // FREE | brcmf_btcoex_handler() // Worker\n /* | btci = container_of(....); // USE\n The kfree() above could | ...\n also occur at any point | btci-\u003e // USE\n during the worker\u0027s execution|\n */ |\n\nTo resolve the race conditions, drop the conditional check and call\ntimer_shutdown_sync() directly. It can deactivate the timer reliably,\nregardless of its current state. Once stopped, the timer_on state is\nthen set to false.",
"id": "GHSA-c7cr-ch33-3xr3",
"modified": "2026-06-19T15:33:07Z",
"published": "2025-09-22T21:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39863"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2f6fbc8e04ca1d1d5c560be694199f847229c625"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e789f8475f6c857c88de5c5bf4b24b11a477dd7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9cb83d4be0b9b697eae93d321e0da999f9cdfcfc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ae58f70bde0433f27ef4b388ab50634736607bf6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c75600e69e66a751cc046cd9c407b942f298d852"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f1150153c4e5940fe49ab51136343c5b4fe49d63"
}
],
"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-C7GF-37RM-RPG6
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-07-14 12:31In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix use-after-free in iomap inline data write path
The inline data buffer head (dibh) is being released prematurely in gfs2_iomap_begin() via release_metapath() while iomap->inline_data still points to dibh->b_data. This causes a use-after-free when iomap_write_end_inline() later attempts to write to the inline data area.
The bug sequence: 1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode metadata into dibh 2. Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode) 3. Calls release_metapath() which calls brelse(dibh), dropping refcount to 0 4. kswapd reclaims the page (~39ms later in the syzbot report) 5. iomap_write_end_inline() tries to memcpy() to iomap->inline_data 6. KASAN detects use-after-free write to freed memory
Fix by storing dibh in iomap->private and incrementing its refcount with get_bh() in gfs2_iomap_begin(). The buffer is then properly released in gfs2_iomap_end() after the inline write completes, ensuring the page stays alive for the entire iomap operation.
Note: A C reproducer is not available for this issue. The fix is based on analysis of the KASAN report and code review showing the buffer head is freed before use.
[agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid leaks in gfs2_iomap_get() and gfs2_iomap_alloc().]
{
"affected": [],
"aliases": [
"CVE-2026-45984"
],
"database_specific": {
"cwe_ids": [
"CWE-416",
"CWE-826"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:15Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Fix use-after-free in iomap inline data write path\n\nThe inline data buffer head (dibh) is being released prematurely in\ngfs2_iomap_begin() via release_metapath() while iomap-\u003einline_data\nstill points to dibh-\u003eb_data. This causes a use-after-free when\niomap_write_end_inline() later attempts to write to the inline data\narea.\n\nThe bug sequence:\n1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode\n metadata into dibh\n2. Sets iomap-\u003einline_data = dibh-\u003eb_data + sizeof(struct gfs2_dinode)\n3. Calls release_metapath() which calls brelse(dibh), dropping refcount\n to 0\n4. kswapd reclaims the page (~39ms later in the syzbot report)\n5. iomap_write_end_inline() tries to memcpy() to iomap-\u003einline_data\n6. KASAN detects use-after-free write to freed memory\n\nFix by storing dibh in iomap-\u003eprivate and incrementing its refcount\nwith get_bh() in gfs2_iomap_begin(). The buffer is then properly\nreleased in gfs2_iomap_end() after the inline write completes,\nensuring the page stays alive for the entire iomap operation.\n\nNote: A C reproducer is not available for this issue. The fix is based\non analysis of the KASAN report and code review showing the buffer head\nis freed before use.\n\n[agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid\nleaks in gfs2_iomap_get() and gfs2_iomap_alloc().]",
"id": "GHSA-c7gf-37rm-rpg6",
"modified": "2026-07-14T12:31:12Z",
"published": "2026-05-27T15:33:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45984"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-45984.json"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/faddeb848305e79db89ee0479bb0e33380656321"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d87268326b277af3665237ac76a73dd9fa8e21b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/87d4954b5c59735a99ea98cb208d47130f6dce7d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/815ddd27c0c7171a99fe802fdb19098ddef8b19d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/764c3c84b5683e608f43735c803a5f415046686c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6d76febba07c40bcf358f63216d36ea68cf1c215"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1cae1bafdf9caa9b462b19af06b1a06902e4e142"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1403989d1b502f4a2c0d0b42ccf1c25748442eff"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2481922"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-45984"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:38902"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36767"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36049"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:35894"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:33743"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:27789"
}
],
"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-C7H3-7F54-949M
Vulnerability from github – Published: 2025-07-18 09:30 – Updated: 2025-11-18 15:30In the Linux kernel, the following vulnerability has been resolved:
eventpoll: don't decrement ep refcount while still holding the ep mutex
Jann Horn points out that epoll is decrementing the ep refcount and then doing a
mutex_unlock(&ep->mtx);
afterwards. That's very wrong, because it can lead to a use-after-free.
That pattern is actually fine for the very last reference, because the code in question will delay the actual call to "ep_free(ep)" until after it has unlocked the mutex.
But it's wrong for the much subtler "next to last" case when somebody else may also be dropping their reference and free the ep while we're still using the mutex.
Note that this is true even if that other user is also using the same ep mutex: mutexes, unlike spinlocks, can not be used for object ownership, even if they guarantee mutual exclusion.
A mutex "unlock" operation is not atomic, and as one user is still accessing the mutex as part of unlocking it, another user can come in and get the now released mutex and free the data structure while the first user is still cleaning up.
See our mutex documentation in Documentation/locking/mutex-design.rst, in particular the section [1] about semantics:
"mutex_unlock() may access the mutex structure even after it has
internally released the lock already - so it's not safe for
another context to acquire the mutex and assume that the
mutex_unlock() context is not using the structure anymore"
So if we drop our ep ref before the mutex unlock, but we weren't the last one, we may then unlock the mutex, another user comes in, drops their reference and releases the 'ep' as it now has no users - all while the mutex_unlock() is still accessing it.
Fix this by simply moving the ep refcount dropping to outside the mutex: the refcount itself is atomic, and doesn't need mutex protection (that's the whole point of refcounts: unlike mutexes, they are inherently about object lifetimes).
{
"affected": [],
"aliases": [
"CVE-2025-38349"
],
"database_specific": {
"cwe_ids": [
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-18T08:15:27Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\neventpoll: don\u0027t decrement ep refcount while still holding the ep mutex\n\nJann Horn points out that epoll is decrementing the ep refcount and then\ndoing a\n\n mutex_unlock(\u0026ep-\u003emtx);\n\nafterwards. That\u0027s very wrong, because it can lead to a use-after-free.\n\nThat pattern is actually fine for the very last reference, because the\ncode in question will delay the actual call to \"ep_free(ep)\" until after\nit has unlocked the mutex.\n\nBut it\u0027s wrong for the much subtler \"next to last\" case when somebody\n*else* may also be dropping their reference and free the ep while we\u0027re\nstill using the mutex.\n\nNote that this is true even if that other user is also using the same ep\nmutex: mutexes, unlike spinlocks, can not be used for object ownership,\neven if they guarantee mutual exclusion.\n\nA mutex \"unlock\" operation is not atomic, and as one user is still\naccessing the mutex as part of unlocking it, another user can come in\nand get the now released mutex and free the data structure while the\nfirst user is still cleaning up.\n\nSee our mutex documentation in Documentation/locking/mutex-design.rst,\nin particular the section [1] about semantics:\n\n\t\"mutex_unlock() may access the mutex structure even after it has\n\t internally released the lock already - so it\u0027s not safe for\n\t another context to acquire the mutex and assume that the\n\t mutex_unlock() context is not using the structure anymore\"\n\nSo if we drop our ep ref before the mutex unlock, but we weren\u0027t the\nlast one, we may then unlock the mutex, another user comes in, drops\n_their_ reference and releases the \u0027ep\u0027 as it now has no users - all\nwhile the mutex_unlock() is still accessing it.\n\nFix this by simply moving the ep refcount dropping to outside the mutex:\nthe refcount itself is atomic, and doesn\u0027t need mutex protection (that\u0027s\nthe whole _point_ of refcounts: unlike mutexes, they are inherently\nabout object lifetimes).",
"id": "GHSA-c7h3-7f54-949m",
"modified": "2025-11-18T15:30:41Z",
"published": "2025-07-18T09:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38349"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/521e9ff0b67c66a17d6f9593dfccafaa984aae4c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/605c18698ecfa99165f36b7f59d3ed503e169814"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6dee745bd0aec9d399df674256e7b1ecdb615444"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8c2e52ebbe885c7eeaabd3b7ddcdc1246fc400d2"
},
{
"type": "WEB",
"url": "https://project-zero.issues.chromium.org/issues/430541637"
}
],
"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-C7HV-342M-6J93
Vulnerability from github – Published: 2022-05-24 19:04 – Updated: 2022-05-24 19:04Use after free issue when importing a DMA buffer by using the CPU address of the buffer due to attachment is not cleaned up properly in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables
{
"affected": [],
"aliases": [
"CVE-2020-11239"
],
"database_specific": {
"cwe_ids": [
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-09T05:15:00Z",
"severity": "HIGH"
},
"details": "Use after free issue when importing a DMA buffer by using the CPU address of the buffer due to attachment is not cleaned up properly in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice \u0026 Music, Snapdragon Wearables",
"id": "GHSA-c7hv-342m-6j93",
"modified": "2022-05-24T19:04:43Z",
"published": "2022-05-24T19:04:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11239"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins/january-2021-bulletin"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-C7J6-57M2-GXXG
Vulnerability from github – Published: 2022-05-13 01:31 – Updated: 2022-05-13 01:31This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Foxit Reader 9.0.1.1049. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of the textColor Field attribute. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code under the context of the current process. Was ZDI-CAN-5433.
{
"affected": [],
"aliases": [
"CVE-2018-9960"
],
"database_specific": {
"cwe_ids": [
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-05-17T15:29:00Z",
"severity": "HIGH"
},
"details": "This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Foxit Reader 9.0.1.1049. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of the textColor Field attribute. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code under the context of the current process. Was ZDI-CAN-5433.",
"id": "GHSA-c7j6-57m2-gxxg",
"modified": "2022-05-13T01:31:38Z",
"published": "2022-05-13T01:31:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-9960"
},
{
"type": "WEB",
"url": "https://www.foxitsoftware.com/support/security-bulletins.php"
},
{
"type": "WEB",
"url": "https://zerodayinitiative.com/advisories/ZDI-18-344"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C7M2-HHFC-83RM
Vulnerability from github – Published: 2026-04-29 00:30 – Updated: 2026-04-29 15:30Use after free in Cast in Google Chrome prior to 147.0.7727.138 allowed an attacker on the local network segment to potentially exploit heap corruption via malicious network traffic. (Chromium security severity: High)
{
"affected": [],
"aliases": [
"CVE-2026-7338"
],
"database_specific": {
"cwe_ids": [
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-28T23:16:21Z",
"severity": "HIGH"
},
"details": "Use after free in Cast in Google Chrome prior to 147.0.7727.138 allowed an attacker on the local network segment to potentially exploit heap corruption via malicious network traffic. (Chromium security severity: High)",
"id": "GHSA-c7m2-hhfc-83rm",
"modified": "2026-04-29T15:30:37Z",
"published": "2026-04-29T00:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7338"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/04/stable-channel-update-for-desktop_28.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/502449857"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C7PR-H9W8-3PXX
Vulnerability from github – Published: 2022-05-13 01:26 – Updated: 2022-05-13 01:26Use-after-free vulnerability in the WebSockets implementation in Google Chrome before 11.0.696.57 allows remote attackers to cause a denial of service or possibly have unspecified other impact via unknown vectors.
{
"affected": [],
"aliases": [
"CVE-2011-1449"
],
"database_specific": {
"cwe_ids": [
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2011-05-03T22:55:00Z",
"severity": "MODERATE"
},
"details": "Use-after-free vulnerability in the WebSockets implementation in Google Chrome before 11.0.696.57 allows remote attackers to cause a denial of service or possibly have unspecified other impact via unknown vectors.",
"id": "GHSA-c7pr-h9w8-3pxx",
"modified": "2022-05-13T01:26:16Z",
"published": "2022-05-13T01:26:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2011-1449"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/67156"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A14478"
},
{
"type": "WEB",
"url": "http://code.google.com/p/chromium/issues/detail?id=77346"
},
{
"type": "WEB",
"url": "http://googlechromereleases.blogspot.com/2011/04/chrome-stable-update.html"
},
{
"type": "WEB",
"url": "http://lists.apple.com/archives/Security-announce/2011//Oct/msg00000.html"
},
{
"type": "WEB",
"url": "http://lists.apple.com/archives/Security-announce/2011//Oct/msg00001.html"
},
{
"type": "WEB",
"url": "http://lists.apple.com/archives/security-announce/2011//Jul/msg00002.html"
},
{
"type": "WEB",
"url": "http://support.apple.com/kb/HT4808"
},
{
"type": "WEB",
"url": "http://support.apple.com/kb/HT4981"
},
{
"type": "WEB",
"url": "http://support.apple.com/kb/HT4999"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-C7VF-6CH7-MWVJ
Vulnerability from github – Published: 2025-09-10 00:31 – Updated: 2025-09-10 00:31Substance3D - Modeler versions 1.22.2 and earlier are affected by a Use After Free vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. Scope is unchanged.
{
"affected": [],
"aliases": [
"CVE-2025-54258"
],
"database_specific": {
"cwe_ids": [
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-09T22:15:33Z",
"severity": "HIGH"
},
"details": "Substance3D - Modeler versions 1.22.2 and earlier are affected by a Use After Free vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. Scope is unchanged.",
"id": "GHSA-c7vf-6ch7-mwvj",
"modified": "2025-09-10T00:31:01Z",
"published": "2025-09-10T00:31:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54258"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/substance3d-modeler/apsb25-92.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C7VW-6RWX-XWR2
Vulnerability from github – Published: 2024-01-02 09:30 – Updated: 2024-01-02 09:30in OpenHarmony v3.2.2 and prior versions allow a local attacker cause multimedia audio crash through modify a released pointer.
{
"affected": [],
"aliases": [
"CVE-2023-49142"
],
"database_specific": {
"cwe_ids": [
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-02T08:15:10Z",
"severity": "MODERATE"
},
"details": "\nin OpenHarmony v3.2.2 and prior versions allow a local attacker cause multimedia audio crash through modify a released pointer.",
"id": "GHSA-c7vw-6rwx-xwr2",
"modified": "2024-01-02T09:30:29Z",
"published": "2024-01-02T09:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49142"
},
{
"type": "WEB",
"url": "https://gitee.com/openharmony/security/blob/master/zh/security-disclosure/2024/2024-01.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
Mitigation
Strategy: Language Selection
Choose a language that provides automatic memory management.
Mitigation
Strategy: Attack Surface Reduction
When freeing pointers, be sure to set them to NULL once they are freed. However, the utilization of multiple or complex data structures may lower the usefulness of this strategy.
No CAPEC attack patterns related to this CWE.