CWE-362
Allowed-with-ReviewConcurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Abstraction: Class · Status: Draft
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
2901 vulnerabilities reference this CWE, most recent first.
GHSA-9357-692C-CJ9M
Vulnerability from github – Published: 2022-05-14 03:36 – Updated: 2022-05-14 03:36An issue was discovered in secdrv.sys as shipped in Microsoft Windows Vista, Windows 7, Windows 8, and Windows 8.1 before KB3086255, and as shipped in Macrovision SafeDisc. Two carefully timed calls to IOCTL 0xCA002813 can cause a race condition that leads to a use-after-free. When exploited, an unprivileged attacker can run arbitrary code in the kernel.
{
"affected": [],
"aliases": [
"CVE-2018-7249"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-02-26T20:29:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in secdrv.sys as shipped in Microsoft Windows Vista, Windows 7, Windows 8, and Windows 8.1 before KB3086255, and as shipped in Macrovision SafeDisc. Two carefully timed calls to IOCTL 0xCA002813 can cause a race condition that leads to a use-after-free. When exploited, an unprivileged attacker can run arbitrary code in the kernel.",
"id": "GHSA-9357-692c-cj9m",
"modified": "2022-05-14T03:36:17Z",
"published": "2022-05-14T03:36:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7249"
},
{
"type": "WEB",
"url": "https://github.com/Elvin9/NotSecDrv/blob/master/README.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-938F-6JJ9-X227
Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-21 18:33In the Linux kernel, the following vulnerability has been resolved:
nvme-pci: Fix race bug in nvme_poll_irqdisable()
In the following scenario, pdev can be disabled between (1) and (3) by (2). This sets pdev->msix_enabled = 0. Then, pci_irq_vector() will return MSI-X IRQ(>15) for (1) whereas return INTx IRQ(<=15) for (2). This causes IRQ warning because it tries to enable INTx IRQ that has never been disabled before.
To fix this, save IRQ number into a local variable and ensure disable_irq() and enable_irq() operate on the same IRQ number. Even if pci_free_irq_vectors() frees the IRQ concurrently, disable_irq() and enable_irq() on a stale IRQ number is still valid and safe, and the depth accounting reamins balanced.
task 1: nvme_poll_irqdisable() disable_irq(pci_irq_vector(pdev, nvmeq->cq_vector)) ...(1) enable_irq(pci_irq_vector(pdev, nvmeq->cq_vector)) ...(3)
task 2: nvme_reset_work() nvme_dev_disable() pdev->msix_enable = 0; ...(2)
crash log:
------------[ cut here ]------------ Unbalanced enable for IRQ 10 WARNING: kernel/irq/manage.c:753 at __enable_irq+0x102/0x190 kernel/irq/manage.c:753, CPU#1: kworker/1:0H/26 Modules linked in: CPU: 1 UID: 0 PID: 26 Comm: kworker/1:0H Not tainted 6.19.0-dirty #9 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_timeout_work RIP: 0010:__enable_irq+0x107/0x190 kernel/irq/manage.c:753 Code: ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 79 48 8d 3d 2e 7a 3f 05 41 8b 74 24 2c <67> 48 0f b9 3a e8 ef b9 21 00 5b 41 5c 5d e9 46 54 66 03 e8 e1 b9 RSP: 0018:ffffc900001bf550 EFLAGS: 00010046 RAX: 0000000000000007 RBX: 0000000000000000 RCX: ffffffffb20c0e90 RDX: 0000000000000000 RSI: 000000000000000a RDI: ffffffffb74b88f0 RBP: ffffc900001bf560 R08: ffff88800197cf00 R09: 0000000000000001 R10: 0000000000000003 R11: 0000000000000003 R12: ffff8880012a6000 R13: 1ffff92000037eae R14: 000000000000000a R15: 0000000000000293 FS: 0000000000000000(0000) GS:ffff8880b49f7000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555da4a25fa8 CR3: 00000000208e8000 CR4: 00000000000006f0 Call Trace: enable_irq+0x121/0x1e0 kernel/irq/manage.c:797 nvme_poll_irqdisable+0x162/0x1c0 drivers/nvme/host/pci.c:1494 nvme_timeout+0x965/0x14b0 drivers/nvme/host/pci.c:1744 blk_mq_rq_timed_out block/blk-mq.c:1653 [inline] blk_mq_handle_expired+0x227/0x2d0 block/blk-mq.c:1721 bt_iter+0x2fc/0x3a0 block/blk-mq-tag.c:292 __sbitmap_for_each_set include/linux/sbitmap.h:269 [inline] sbitmap_for_each_set include/linux/sbitmap.h:290 [inline] bt_for_each block/blk-mq-tag.c:324 [inline] blk_mq_queue_tag_busy_iter+0x969/0x1e80 block/blk-mq-tag.c:536 blk_mq_timeout_work+0x627/0x870 block/blk-mq.c:1763 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 irq event stamp: 74478 hardirqs last enabled at (74477): [] __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:159 [inline] hardirqs last enabled at (74477): [] _raw_spin_unlock_irq+0x2c/0x60 kernel/locking/spinlock.c:202 hardirqs last disabled at (74478): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (74478): [] _raw_spin_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:162 softirqs last enabled at (74304): [] __do_softirq kernel/softirq.c:656 [inline] softirqs last enabled at (74304): [] invoke_softirq kernel/softirq.c:496 [inline] softirqs last enabled at (74304): [] __irq_exit_rcu+0xdc/0x120 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2026-43448"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-08T15:16:57Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvme-pci: Fix race bug in nvme_poll_irqdisable()\n\nIn the following scenario, pdev can be disabled between (1) and (3) by\n(2). This sets pdev-\u003emsix_enabled = 0. Then, pci_irq_vector() will\nreturn MSI-X IRQ(\u003e15) for (1) whereas return INTx IRQ(\u003c=15) for (2).\nThis causes IRQ warning because it tries to enable INTx IRQ that has\nnever been disabled before.\n\nTo fix this, save IRQ number into a local variable and ensure\ndisable_irq() and enable_irq() operate on the same IRQ number. Even if\npci_free_irq_vectors() frees the IRQ concurrently, disable_irq() and\nenable_irq() on a stale IRQ number is still valid and safe, and the\ndepth accounting reamins balanced.\n\ntask 1:\nnvme_poll_irqdisable()\n disable_irq(pci_irq_vector(pdev, nvmeq-\u003ecq_vector)) ...(1)\n enable_irq(pci_irq_vector(pdev, nvmeq-\u003ecq_vector)) ...(3)\n\ntask 2:\nnvme_reset_work()\n nvme_dev_disable()\n pdev-\u003emsix_enable = 0; ...(2)\n\ncrash log:\n\n------------[ cut here ]------------\nUnbalanced enable for IRQ 10\nWARNING: kernel/irq/manage.c:753 at __enable_irq+0x102/0x190 kernel/irq/manage.c:753, CPU#1: kworker/1:0H/26\nModules linked in:\nCPU: 1 UID: 0 PID: 26 Comm: kworker/1:0H Not tainted 6.19.0-dirty #9 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nWorkqueue: kblockd blk_mq_timeout_work\nRIP: 0010:__enable_irq+0x107/0x190 kernel/irq/manage.c:753\nCode: ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 79 48 8d 3d 2e 7a 3f 05 41 8b 74 24 2c \u003c67\u003e 48 0f b9 3a e8 ef b9 21 00 5b 41 5c 5d e9 46 54 66 03 e8 e1 b9\nRSP: 0018:ffffc900001bf550 EFLAGS: 00010046\nRAX: 0000000000000007 RBX: 0000000000000000 RCX: ffffffffb20c0e90\nRDX: 0000000000000000 RSI: 000000000000000a RDI: ffffffffb74b88f0\nRBP: ffffc900001bf560 R08: ffff88800197cf00 R09: 0000000000000001\nR10: 0000000000000003 R11: 0000000000000003 R12: ffff8880012a6000\nR13: 1ffff92000037eae R14: 000000000000000a R15: 0000000000000293\nFS: 0000000000000000(0000) GS:ffff8880b49f7000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000555da4a25fa8 CR3: 00000000208e8000 CR4: 00000000000006f0\nCall Trace:\n \u003cTASK\u003e\n enable_irq+0x121/0x1e0 kernel/irq/manage.c:797\n nvme_poll_irqdisable+0x162/0x1c0 drivers/nvme/host/pci.c:1494\n nvme_timeout+0x965/0x14b0 drivers/nvme/host/pci.c:1744\n blk_mq_rq_timed_out block/blk-mq.c:1653 [inline]\n blk_mq_handle_expired+0x227/0x2d0 block/blk-mq.c:1721\n bt_iter+0x2fc/0x3a0 block/blk-mq-tag.c:292\n __sbitmap_for_each_set include/linux/sbitmap.h:269 [inline]\n sbitmap_for_each_set include/linux/sbitmap.h:290 [inline]\n bt_for_each block/blk-mq-tag.c:324 [inline]\n blk_mq_queue_tag_busy_iter+0x969/0x1e80 block/blk-mq-tag.c:536\n blk_mq_timeout_work+0x627/0x870 block/blk-mq.c:1763\n process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257\n process_scheduled_works kernel/workqueue.c:3340 [inline]\n worker_thread+0x65c/0xe60 kernel/workqueue.c:3421\n kthread+0x41a/0x930 kernel/kthread.c:463\n ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246\n \u003c/TASK\u003e\nirq event stamp: 74478\nhardirqs last enabled at (74477): [\u003cffffffffb5720a9c\u003e] __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:159 [inline]\nhardirqs last enabled at (74477): [\u003cffffffffb5720a9c\u003e] _raw_spin_unlock_irq+0x2c/0x60 kernel/locking/spinlock.c:202\nhardirqs last disabled at (74478): [\u003cffffffffb57207b5\u003e] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]\nhardirqs last disabled at (74478): [\u003cffffffffb57207b5\u003e] _raw_spin_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:162\nsoftirqs last enabled at (74304): [\u003cffffffffb1e9466c\u003e] __do_softirq kernel/softirq.c:656 [inline]\nsoftirqs last enabled at (74304): [\u003cffffffffb1e9466c\u003e] invoke_softirq kernel/softirq.c:496 [inline]\nsoftirqs last enabled at (74304): [\u003cffffffffb1e9466c\u003e] __irq_exit_rcu+0xdc/0x120\n---truncated---",
"id": "GHSA-938f-6jj9-x227",
"modified": "2026-05-21T18:33:06Z",
"published": "2026-05-08T15:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43448"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/265dbc9bc33c29f60f90be3e0afe1c4067ebb70b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/628773eba024d1107cc9ec157a682cbb42ac912a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/843e913cef4e33723663a899727f685a95ab53fe"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b56c49897bdac5cb49e3495ef421c391628ee9bb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e311d84c62eb76e025e11a44155b402e55950b83"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fc71f409b22ca831a9f87a2712eaa09ef2bb4a5e"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-93F5-RWWH-V8P5
Vulnerability from github – Published: 2025-07-25 15:30 – Updated: 2026-05-12 15:30In the Linux kernel, the following vulnerability has been resolved:
NFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAIN
We found a few different systems hung up in writeback waiting on the same page lock, and one task waiting on the NFS_LAYOUT_DRAIN bit in pnfs_update_layout(), however the pnfs_layout_hdr's plh_outstanding count was zero.
It seems most likely that this is another race between the waiter and waker similar to commit ed0172af5d6f ("SUNRPC: Fix a race to wake a sync task"). Fix it up by applying the advised barrier.
{
"affected": [],
"aliases": [
"CVE-2025-38393"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-25T13:15:28Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAIN\n\nWe found a few different systems hung up in writeback waiting on the same\npage lock, and one task waiting on the NFS_LAYOUT_DRAIN bit in\npnfs_update_layout(), however the pnfs_layout_hdr\u0027s plh_outstanding count\nwas zero.\n\nIt seems most likely that this is another race between the waiter and waker\nsimilar to commit ed0172af5d6f (\"SUNRPC: Fix a race to wake a sync task\").\nFix it up by applying the advised barrier.",
"id": "GHSA-93f5-rwwh-v8p5",
"modified": "2026-05-12T15:30:57Z",
"published": "2025-07-25T15:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38393"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/08287df60bac5b008b6bcdb03053988335d3d282"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f4da20080718f258e189a2c5f515385fa393da6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/864a54c1243ed3ca60baa4bc492dede1361f4c83"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8846fd02c98da8b79e6343a20e6071be6f372180"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8ca65fa71024a1767a59ffbc6a6e2278af84735e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c01776287414ca43412d1319d2877cbad65444ac"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e4b13885e7ef1e64e45268feef1e5f0707c47e72"
},
{
"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:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-93M4-3786-5PHJ
Vulnerability from github – Published: 2025-07-10 09:32 – Updated: 2025-11-18 21:32In the Linux kernel, the following vulnerability has been resolved:
fs/fhandle.c: fix a race in call of has_locked_children()
may_decode_fh() is calling has_locked_children() while holding no locks. That's an oopsable race...
The rest of the callers are safe since they are holding namespace_sem and are guaranteed a positive refcount on the mount in question.
Rename the current has_locked_children() to __has_locked_children(), make it static and switch the fs/namespace.c users to it.
Make has_locked_children() a wrapper for __has_locked_children(), calling the latter under read_seqlock_excl(&mount_lock).
{
"affected": [],
"aliases": [
"CVE-2025-38306"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-10T08:15:29Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/fhandle.c: fix a race in call of has_locked_children()\n\nmay_decode_fh() is calling has_locked_children() while holding no locks.\nThat\u0027s an oopsable race...\n\nThe rest of the callers are safe since they are holding namespace_sem and\nare guaranteed a positive refcount on the mount in question.\n\nRename the current has_locked_children() to __has_locked_children(), make\nit static and switch the fs/namespace.c users to it.\n\nMake has_locked_children() a wrapper for __has_locked_children(), calling\nthe latter under read_seqlock_excl(\u0026mount_lock).",
"id": "GHSA-93m4-3786-5phj",
"modified": "2025-11-18T21:32:29Z",
"published": "2025-07-10T09:32:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38306"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f282cdc1d219c4a557f7009e81bc792820d9d9a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/287c7d34eedd37af1272dfb3b6e8656f4f026424"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6482c3dccbfb8d20e2856ce67c75856859930b3f"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-93R7-H3JV-XG2Q
Vulnerability from github – Published: 2022-05-13 01:46 – Updated: 2022-05-13 01:46Race condition in the sctp_wait_for_sndbuf function in net/sctp/socket.c in the Linux kernel before 4.9.11 allows local users to cause a denial of service (assertion failure and panic) via a multithreaded application that peels off an association in a certain buffer-full state.
{
"affected": [],
"aliases": [
"CVE-2017-5986"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-02-18T21:59:00Z",
"severity": "HIGH"
},
"details": "Race condition in the sctp_wait_for_sndbuf function in net/sctp/socket.c in the Linux kernel before 4.9.11 allows local users to cause a denial of service (assertion failure and panic) via a multithreaded application that peels off an association in a certain buffer-full state.",
"id": "GHSA-93r7-h3jv-xg2q",
"modified": "2022-05-13T01:46:22Z",
"published": "2022-05-13T01:46:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-5986"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/2dcab598484185dea7ec22219c76dcdd59e3cb90"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:1308"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1420276"
},
{
"type": "WEB",
"url": "http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2dcab598484185dea7ec22219c76dcdd59e3cb90"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2017/dsa-3804"
},
{
"type": "WEB",
"url": "http://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.9.11"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2017/02/14/6"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/96222"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-93VX-P2JX-WJ6M
Vulnerability from github – Published: 2024-05-03 15:30 – Updated: 2024-06-03 18:53In the Linux kernel, the following vulnerability has been resolved:
tcp: TX zerocopy should not sense pfmemalloc status
We got a recent syzbot report [1] showing a possible misuse of pfmemalloc page status in TCP zerocopy paths.
Indeed, for pages coming from user space or other layers, using page_is_pfmemalloc() is moot, and possibly could give false positives.
There has been attempts to make page_is_pfmemalloc() more robust, but not using it in the first place in this context is probably better, removing cpu cycles.
Note to stable teams :
You need to backport 84ce071e38a6 ("net: introduce __skb_fill_page_desc_noacc") as a prereq.
Race is more probable after commit c07aea3ef4d4 ("mm: add a signature in struct page") because page_is_pfmemalloc() is now using low order bit from page->lru.next, which can change more often than page->index.
Low order bit should never be set for lru.next (when used as an anchor in LRU list), so KCSAN report is mostly a false positive.
Backporting to older kernel versions seems not necessary.
[1] BUG: KCSAN: data-race in lru_add_fn / tcp_build_frag
write to 0xffffea0004a1d2c8 of 8 bytes by task 18600 on cpu 0: __list_add include/linux/list.h:73 [inline] list_add include/linux/list.h:88 [inline] lruvec_add_folio include/linux/mm_inline.h:105 [inline] lru_add_fn+0x440/0x520 mm/swap.c:228 folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246 folio_batch_add_and_move mm/swap.c:263 [inline] folio_add_lru+0xf1/0x140 mm/swap.c:490 filemap_add_folio+0xf8/0x150 mm/filemap.c:948 __filemap_get_folio+0x510/0x6d0 mm/filemap.c:1981 pagecache_get_page+0x26/0x190 mm/folio-compat.c:104 grab_cache_page_write_begin+0x2a/0x30 mm/folio-compat.c:116 ext4_da_write_begin+0x2dd/0x5f0 fs/ext4/inode.c:2988 generic_perform_write+0x1d4/0x3f0 mm/filemap.c:3738 ext4_buffered_write_iter+0x235/0x3e0 fs/ext4/file.c:270 ext4_file_write_iter+0x2e3/0x1210 call_write_iter include/linux/fs.h:2187 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x468/0x760 fs/read_write.c:578 ksys_write+0xe8/0x1a0 fs/read_write.c:631 __do_sys_write fs/read_write.c:643 [inline] __se_sys_write fs/read_write.c:640 [inline] __x64_sys_write+0x3e/0x50 fs/read_write.c:640 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
read to 0xffffea0004a1d2c8 of 8 bytes by task 18611 on cpu 1: page_is_pfmemalloc include/linux/mm.h:1740 [inline] __skb_fill_page_desc include/linux/skbuff.h:2422 [inline] skb_fill_page_desc include/linux/skbuff.h:2443 [inline] tcp_build_frag+0x613/0xb20 net/ipv4/tcp.c:1018 do_tcp_sendpages+0x3e8/0xaf0 net/ipv4/tcp.c:1075 tcp_sendpage_locked net/ipv4/tcp.c:1140 [inline] tcp_sendpage+0x89/0xb0 net/ipv4/tcp.c:1150 inet_sendpage+0x7f/0xc0 net/ipv4/af_inet.c:833 kernel_sendpage+0x184/0x300 net/socket.c:3561 sock_sendpage+0x5a/0x70 net/socket.c:1054 pipe_to_sendpage+0x128/0x160 fs/splice.c:361 splice_from_pipe_feed fs/splice.c:415 [inline] __splice_from_pipe+0x222/0x4d0 fs/splice.c:559 splice_from_pipe fs/splice.c:594 [inline] generic_splice_sendpage+0x89/0xc0 fs/splice.c:743 do_splice_from fs/splice.c:764 [inline] direct_splice_actor+0x80/0xa0 fs/splice.c:931 splice_direct_to_actor+0x305/0x620 fs/splice.c:886 do_splice_direct+0xfb/0x180 fs/splice.c:974 do_sendfile+0x3bf/0x910 fs/read_write.c:1249 __do_sys_sendfile64 fs/read_write.c:1317 [inline] __se_sys_sendfile64 fs/read_write.c:1303 [inline] __x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1303 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
value changed: 0x0000000000000000 -> 0xffffea0004a1d288
Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 18611 Comm: syz-executor.4 Not tainted 6.0.0-rc2-syzkaller-00248-ge022620b5d05-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022
{
"affected": [],
"aliases": [
"CVE-2022-48689"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-03T15:15:07Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: TX zerocopy should not sense pfmemalloc status\n\nWe got a recent syzbot report [1] showing a possible misuse\nof pfmemalloc page status in TCP zerocopy paths.\n\nIndeed, for pages coming from user space or other layers,\nusing page_is_pfmemalloc() is moot, and possibly could give\nfalse positives.\n\nThere has been attempts to make page_is_pfmemalloc() more robust,\nbut not using it in the first place in this context is probably better,\nremoving cpu cycles.\n\nNote to stable teams :\n\nYou need to backport 84ce071e38a6 (\"net: introduce\n__skb_fill_page_desc_noacc\") as a prereq.\n\nRace is more probable after commit c07aea3ef4d4\n(\"mm: add a signature in struct page\") because page_is_pfmemalloc()\nis now using low order bit from page-\u003elru.next, which can change\nmore often than page-\u003eindex.\n\nLow order bit should never be set for lru.next (when used as an anchor\nin LRU list), so KCSAN report is mostly a false positive.\n\nBackporting to older kernel versions seems not necessary.\n\n[1]\nBUG: KCSAN: data-race in lru_add_fn / tcp_build_frag\n\nwrite to 0xffffea0004a1d2c8 of 8 bytes by task 18600 on cpu 0:\n__list_add include/linux/list.h:73 [inline]\nlist_add include/linux/list.h:88 [inline]\nlruvec_add_folio include/linux/mm_inline.h:105 [inline]\nlru_add_fn+0x440/0x520 mm/swap.c:228\nfolio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246\nfolio_batch_add_and_move mm/swap.c:263 [inline]\nfolio_add_lru+0xf1/0x140 mm/swap.c:490\nfilemap_add_folio+0xf8/0x150 mm/filemap.c:948\n__filemap_get_folio+0x510/0x6d0 mm/filemap.c:1981\npagecache_get_page+0x26/0x190 mm/folio-compat.c:104\ngrab_cache_page_write_begin+0x2a/0x30 mm/folio-compat.c:116\next4_da_write_begin+0x2dd/0x5f0 fs/ext4/inode.c:2988\ngeneric_perform_write+0x1d4/0x3f0 mm/filemap.c:3738\next4_buffered_write_iter+0x235/0x3e0 fs/ext4/file.c:270\next4_file_write_iter+0x2e3/0x1210\ncall_write_iter include/linux/fs.h:2187 [inline]\nnew_sync_write fs/read_write.c:491 [inline]\nvfs_write+0x468/0x760 fs/read_write.c:578\nksys_write+0xe8/0x1a0 fs/read_write.c:631\n__do_sys_write fs/read_write.c:643 [inline]\n__se_sys_write fs/read_write.c:640 [inline]\n__x64_sys_write+0x3e/0x50 fs/read_write.c:640\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nread to 0xffffea0004a1d2c8 of 8 bytes by task 18611 on cpu 1:\npage_is_pfmemalloc include/linux/mm.h:1740 [inline]\n__skb_fill_page_desc include/linux/skbuff.h:2422 [inline]\nskb_fill_page_desc include/linux/skbuff.h:2443 [inline]\ntcp_build_frag+0x613/0xb20 net/ipv4/tcp.c:1018\ndo_tcp_sendpages+0x3e8/0xaf0 net/ipv4/tcp.c:1075\ntcp_sendpage_locked net/ipv4/tcp.c:1140 [inline]\ntcp_sendpage+0x89/0xb0 net/ipv4/tcp.c:1150\ninet_sendpage+0x7f/0xc0 net/ipv4/af_inet.c:833\nkernel_sendpage+0x184/0x300 net/socket.c:3561\nsock_sendpage+0x5a/0x70 net/socket.c:1054\npipe_to_sendpage+0x128/0x160 fs/splice.c:361\nsplice_from_pipe_feed fs/splice.c:415 [inline]\n__splice_from_pipe+0x222/0x4d0 fs/splice.c:559\nsplice_from_pipe fs/splice.c:594 [inline]\ngeneric_splice_sendpage+0x89/0xc0 fs/splice.c:743\ndo_splice_from fs/splice.c:764 [inline]\ndirect_splice_actor+0x80/0xa0 fs/splice.c:931\nsplice_direct_to_actor+0x305/0x620 fs/splice.c:886\ndo_splice_direct+0xfb/0x180 fs/splice.c:974\ndo_sendfile+0x3bf/0x910 fs/read_write.c:1249\n__do_sys_sendfile64 fs/read_write.c:1317 [inline]\n__se_sys_sendfile64 fs/read_write.c:1303 [inline]\n__x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1303\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nvalue changed: 0x0000000000000000 -\u003e 0xffffea0004a1d288\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 1 PID: 18611 Comm: syz-executor.4 Not tainted 6.0.0-rc2-syzkaller-00248-ge022620b5d05-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022",
"id": "GHSA-93vx-p2jx-wj6m",
"modified": "2024-06-03T18:53:46Z",
"published": "2024-05-03T15:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48689"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3261400639463a853ba2b3be8bd009c2a8089775"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6730c48ed6b0cd939fc9b30b2d621ce0b89bea83"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8527c9a6bf8e54fef0a8d3d7d8874a48c725c915"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9446-W3XX-QR8H
Vulnerability from github – Published: 2022-05-17 01:13 – Updated: 2022-05-17 01:13Race condition in the lighttpd module in Cisco IOS XR 5.1 and earlier on Network Convergence System 6000 devices allows remote attackers to cause a denial of service (process reload) by establishing many TCP sessions, aka Bug ID CSCuq45239.
{
"affected": [],
"aliases": [
"CVE-2014-8005"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2014-11-26T02:59:00Z",
"severity": "MODERATE"
},
"details": "Race condition in the lighttpd module in Cisco IOS XR 5.1 and earlier on Network Convergence System 6000 devices allows remote attackers to cause a denial of service (process reload) by establishing many TCP sessions, aka Bug ID CSCuq45239.",
"id": "GHSA-9446-w3xx-qr8h",
"modified": "2022-05-17T01:13:57Z",
"published": "2022-05-17T01:13:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-8005"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/98937"
},
{
"type": "WEB",
"url": "http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2014-8005"
},
{
"type": "WEB",
"url": "http://tools.cisco.com/security/center/viewAlert.x?alertId=36532"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/71287"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1031262"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-948W-PP9C-F274
Vulnerability from github – Published: 2026-07-14 18:32 – Updated: 2026-07-14 18:32Use after free in Windows Runtime allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-50457"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-14T18:17:50Z",
"severity": "HIGH"
},
"details": "Use after free in Windows Runtime allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-948w-pp9c-f274",
"modified": "2026-07-14T18:32:25Z",
"published": "2026-07-14T18:32:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50457"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-50457"
}
],
"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-94VG-M7V6-9C25
Vulnerability from github – Published: 2026-06-02 03:31 – Updated: 2026-06-02 03:31A security flaw has been discovered in Open5GS up to 2.7.6. The impacted element is the function gmm_state_security_mode of the file src/amf/gmm-sm.c of the component NGAP Handover. Performing a manipulation results in race condition. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitability is regarded as difficult. The exploit has been released to the public and may be used for attacks. The pull request to fix this issue awaits acceptance.
{
"affected": [],
"aliases": [
"CVE-2026-10565"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-02T03:16:16Z",
"severity": "LOW"
},
"details": "A security flaw has been discovered in Open5GS up to 2.7.6. The impacted element is the function gmm_state_security_mode of the file src/amf/gmm-sm.c of the component NGAP Handover. Performing a manipulation results in race condition. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitability is regarded as difficult. The exploit has been released to the public and may be used for attacks. The pull request to fix this issue awaits acceptance.",
"id": "GHSA-94vg-m7v6-9c25",
"modified": "2026-06-02T03:31:26Z",
"published": "2026-06-02T03:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10565"
},
{
"type": "WEB",
"url": "https://github.com/open5gs/open5gs/issues/4497"
},
{
"type": "WEB",
"url": "https://github.com/open5gs/open5gs/pull/4501"
},
{
"type": "WEB",
"url": "https://github.com/open5gs/open5gs"
},
{
"type": "WEB",
"url": "https://github.com/user-attachments/files/27111025/N2-SMC-Concurrent.zip"
},
{
"type": "WEB",
"url": "https://vuldb.com/cve/CVE-2026-10565"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/818938"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/367672"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/367672/cti"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P/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-9567-MJRH-X6XX
Vulnerability from github – Published: 2023-04-11 21:30 – Updated: 2023-04-11 21:30Windows DNS Server Remote Code Execution Vulnerability
{
"affected": [],
"aliases": [
"CVE-2023-28308"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-11T21:15:00Z",
"severity": "MODERATE"
},
"details": "Windows DNS Server Remote Code Execution Vulnerability",
"id": "GHSA-9567-mjrh-x6xx",
"modified": "2023-04-11T21:30:58Z",
"published": "2023-04-11T21:30:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28308"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-28308"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.
Mitigation
Use thread-safe capabilities such as the data access abstraction in Spring.
Mitigation
- Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring.
- Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).
Mitigation
When using multithreading and operating on shared variables, only use thread-safe functions.
Mitigation
Use atomic operations on shared variables. Be wary of innocent-looking constructs such as "x++". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read, followed by a computation, followed by a write.
Mitigation
Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.
Mitigation
Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.
Mitigation
Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite loop.
Mitigation
Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or reordering. This does not necessarily solve the synchronization problem, but it can help.
Mitigation MIT-17
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
CAPEC-26: Leveraging Race Conditions
The adversary targets a race condition occurring when multiple processes access and manipulate the same resource concurrently, and the outcome of the execution depends on the particular order in which the access takes place. The adversary can leverage a race condition by "running the race", modifying the resource and modifying the normal execution flow. For instance, a race condition can occur while accessing a file: the adversary can trick the system by replacing the original file with their version and cause the system to read the malicious file.
CAPEC-29: Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions
This attack targets a race condition occurring between the time of check (state) for a resource and the time of use of a resource. A typical example is file access. The adversary can leverage a file access race condition by "running the race", meaning that they would modify the resource between the first time the target program accesses the file and the time the target program uses the file. During that period of time, the adversary could replace or modify the file, causing the application to behave unexpectedly.