Common Weakness Enumeration

CWE-362

Allowed-with-Review

Concurrent 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.

2922 vulnerabilities reference this CWE, most recent first.

GHSA-772Q-FWQP-96RG

Vulnerability from github – Published: 2024-11-05 18:32 – Updated: 2024-11-08 15:31
VLAI
Details

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

nvme-pci: fix race condition between reset and nvme_dev_disable()

nvme_dev_disable() modifies the dev->online_queues field, therefore nvme_pci_update_nr_queues() should avoid racing against it, otherwise we could end up passing invalid values to blk_mq_update_nr_hw_queues().

WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347 pci_irq_get_affinity+0x187/0x210 Workqueue: nvme-reset-wq nvme_reset_work [nvme] RIP: 0010:pci_irq_get_affinity+0x187/0x210 Call Trace: ? blk_mq_pci_map_queues+0x87/0x3c0 ? pci_irq_get_affinity+0x187/0x210 blk_mq_pci_map_queues+0x87/0x3c0 nvme_pci_map_queues+0x189/0x460 [nvme] blk_mq_update_nr_hw_queues+0x2a/0x40 nvme_reset_work+0x1be/0x2a0 [nvme]

Fix the bug by locking the shutdown_lock mutex before using dev->online_queues. Give up if nvme_dev_disable() is running or if it has been executed already.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-50135"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-05T18:15:16Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvme-pci: fix race condition between reset and nvme_dev_disable()\n\nnvme_dev_disable() modifies the dev-\u003eonline_queues field, therefore\nnvme_pci_update_nr_queues() should avoid racing against it, otherwise\nwe could end up passing invalid values to blk_mq_update_nr_hw_queues().\n\n WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347\n          pci_irq_get_affinity+0x187/0x210\n Workqueue: nvme-reset-wq nvme_reset_work [nvme]\n RIP: 0010:pci_irq_get_affinity+0x187/0x210\n Call Trace:\n  \u003cTASK\u003e\n  ? blk_mq_pci_map_queues+0x87/0x3c0\n  ? pci_irq_get_affinity+0x187/0x210\n  blk_mq_pci_map_queues+0x87/0x3c0\n  nvme_pci_map_queues+0x189/0x460 [nvme]\n  blk_mq_update_nr_hw_queues+0x2a/0x40\n  nvme_reset_work+0x1be/0x2a0 [nvme]\n\nFix the bug by locking the shutdown_lock mutex before using\ndev-\u003eonline_queues. Give up if nvme_dev_disable() is running or if\nit has been executed already.",
  "id": "GHSA-772q-fwqp-96rg",
  "modified": "2024-11-08T15:31:12Z",
  "published": "2024-11-05T18:32:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50135"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/26bc0a81f64ce00fc4342c38eeb2eddaad084dd2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4ed32cc0939b64e3d7b48c8c0d63ea038775f304"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b33e49a5f254474b33ce98fd45dd0ffdc247a0be"
    }
  ],
  "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-7768-MFM4-9CMV

Vulnerability from github – Published: 2022-05-24 17:22 – Updated: 2022-05-24 17:22
VLAI
Details

When browsing a malicious page, a race condition in our SharedWorkerService could occur and lead to a potentially exploitable crash. This vulnerability affects Thunderbird < 68.9.0, Firefox < 77, and Firefox ESR < 68.9.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-12405"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362",
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-07-09T15:15:00Z",
    "severity": "LOW"
  },
  "details": "When browsing a malicious page, a race condition in our SharedWorkerService could occur and lead to a potentially exploitable crash. This vulnerability affects Thunderbird \u003c 68.9.0, Firefox \u003c 77, and Firefox ESR \u003c 68.9.",
  "id": "GHSA-7768-mfm4-9cmv",
  "modified": "2022-05-24T17:22:37Z",
  "published": "2022-05-24T17:22:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12405"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1631618"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4421-1"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2020-20"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2020-21"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2020-22"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-77F5-F59V-G352

Vulnerability from github – Published: 2025-03-12 00:31 – Updated: 2025-03-12 00:31
VLAI
Details

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

sysctl: Fix data races in proc_douintvec().

A sysctl variable is accessed concurrently, and there is always a chance of data-race. So, all readers and writers need some basic protection to avoid load/store-tearing.

This patch changes proc_douintvec() to use READ_ONCE() and WRITE_ONCE() internally to fix data-races on the sysctl side. For now, proc_douintvec() itself is tolerant to a data-race, but we still need to add annotations on the other subsystem's side.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-49641"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:01:39Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsysctl: Fix data races in proc_douintvec().\n\nA sysctl variable is accessed concurrently, and there is always a chance\nof data-race.  So, all readers and writers need some basic protection to\navoid load/store-tearing.\n\nThis patch changes proc_douintvec() to use READ_ONCE() and WRITE_ONCE()\ninternally to fix data-races on the sysctl side.  For now, proc_douintvec()\nitself is tolerant to a data-race, but we still need to add annotations on\nthe other subsystem\u0027s side.",
  "id": "GHSA-77f5-f59v-g352",
  "modified": "2025-03-12T00:31:48Z",
  "published": "2025-03-12T00:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49641"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4762b532ec9539755aab61445d5da6e1926ccb99"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/630c76850d554d7140232e71b5d1663e88cffb54"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d335db59f7fb3353f56e52371f1ee796ae9c8f09"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d5d54714e329f646bd7af4994fc427d88ee68936"
    }
  ],
  "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-77G8-PQ4G-F4JV

Vulnerability from github – Published: 2022-05-24 17:29 – Updated: 2022-10-01 00:00
VLAI
Details

An issue was discovered in Xen through 4.14.x. There is a race condition when migrating timers between x86 HVM vCPUs. When migrating timers of x86 HVM guests between its vCPUs, the locking model used allows for a second vCPU of the same guest (also operating on the timers) to release a lock that it didn't acquire. The most likely effect of the issue is a hang or crash of the hypervisor, i.e., a Denial of Service (DoS). All versions of Xen are affected. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only x86 HVM guests can leverage the vulnerability. x86 PV and PVH cannot leverage the vulnerability. Only guests with more than one vCPU can exploit the vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-25604"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-09-23T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Xen through 4.14.x. There is a race condition when migrating timers between x86 HVM vCPUs. When migrating timers of x86 HVM guests between its vCPUs, the locking model used allows for a second vCPU of the same guest (also operating on the timers) to release a lock that it didn\u0027t acquire. The most likely effect of the issue is a hang or crash of the hypervisor, i.e., a Denial of Service (DoS). All versions of Xen are affected. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only x86 HVM guests can leverage the vulnerability. x86 PV and PVH cannot leverage the vulnerability. Only guests with more than one vCPU can exploit the vulnerability.",
  "id": "GHSA-77g8-pq4g-f4jv",
  "modified": "2022-10-01T00:00:25Z",
  "published": "2022-05-24T17:29:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25604"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4JRXMKEMQRQYWYEPHVBIWUEAVQ3LU4FN"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DA633Y3G5KX7MKRN4PFEGM3IVTJMBEOM"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RJZERRBJN6E6STDCHT4JHP4MI6TKBCJE"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202011-06"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2020/dsa-4769"
    },
    {
      "type": "WEB",
      "url": "https://xenbits.xen.org/xsa/advisory-336.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-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-77M6-X95J-75R5

Vulnerability from github – Published: 2021-08-25 20:58 – Updated: 2023-06-13 22:07
VLAI
Summary
Data races in ticketed_lock
Details

Affected versions of this crate unconditionally implemented Send for ReadTicket & WriteTicket. This allows to send non-Send T to other threads. This can allows creating data races by cloning types with internal mutability and sending them to other threads (as T of ReadTicket/WriteTicket). Such data races can cause memory corruption or other undefined behavior. The flaw was corrected in commit a986a93 by adding T: Send bounds to Send impls of ReadTicket/WriteTicket.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "ticketed_lock"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-36439"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-119",
      "CWE-362"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-08-09T22:40:34Z",
    "nvd_published_at": "2021-08-08T06:15:00Z",
    "severity": "HIGH"
  },
  "details": "Affected versions of this crate unconditionally implemented Send for ReadTicket\u003cT\u003e \u0026 WriteTicket\u003cT\u003e. This allows to send non-Send T to other threads. This can allows creating data races by cloning types with internal mutability and sending them to other threads (as T of ReadTicket\u003cT\u003e/WriteTicket\u003cT\u003e). Such data races can cause memory corruption or other undefined behavior. The flaw was corrected in commit `a986a93` by adding T: Send bounds to Send impls of ReadTicket\u003cT\u003e/WriteTicket\u003cT\u003e.",
  "id": "GHSA-77m6-x95j-75r5",
  "modified": "2023-06-13T22:07:15Z",
  "published": "2021-08-25T20:58:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36439"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kvark/ticketed_lock/issues/7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kvark/ticketed_lock/commit/a986a9335d591fa5c826157d1674d47aa525357f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kvark/ticketed_lock"
    },
    {
      "type": "WEB",
      "url": "https://raw.githubusercontent.com/rustsec/advisory-db/main/crates/ticketed_lock/RUSTSEC-2020-0119.md"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2020-0119.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Data races in ticketed_lock"
}

GHSA-77P3-MMMP-FJJ2

Vulnerability from github – Published: 2026-05-06 12:30 – Updated: 2026-05-12 21:31
VLAI
Details

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

io_uring/zcrx: fix user_ref race between scrub and refill paths

The io_zcrx_put_niov_uref() function uses a non-atomic check-then-decrement pattern (atomic_read followed by separate atomic_dec) to manipulate user_refs. This is serialized against other callers by rq_lock, but io_zcrx_scrub() modifies the same counter with atomic_xchg() WITHOUT holding rq_lock.

On SMP systems, the following race exists:

CPU0 (refill, holds rq_lock) CPU1 (scrub, no rq_lock) put_niov_uref: atomic_read(uref) - 1 // window opens atomic_xchg(uref, 0) - 1 return_niov_freelist(niov) [PUSH #1] // window closes atomic_dec(uref) - wraps to -1 returns true return_niov(niov) return_niov_freelist(niov) [PUSH #2: DOUBLE-FREE]

The same niov is pushed to the freelist twice, causing free_count to exceed nr_iovs. Subsequent freelist pushes then perform an out-of-bounds write (a u32 value) past the kvmalloc'd freelist array into the adjacent slab object.

Fix this by replacing the non-atomic read-then-dec in io_zcrx_put_niov_uref() with an atomic_try_cmpxchg loop that atomically tests and decrements user_refs. This makes the operation safe against concurrent atomic_xchg from scrub without requiring scrub to acquire rq_lock.

[pavel: removed a warning and a comment]

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-43121"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-06T12:16:28Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/zcrx: fix user_ref race between scrub and refill paths\n\nThe io_zcrx_put_niov_uref() function uses a non-atomic\ncheck-then-decrement pattern (atomic_read followed by separate\natomic_dec) to manipulate user_refs. This is serialized against other\ncallers by rq_lock, but io_zcrx_scrub() modifies the same counter with\natomic_xchg() WITHOUT holding rq_lock.\n\nOn SMP systems, the following race exists:\n\n  CPU0 (refill, holds rq_lock)          CPU1 (scrub, no rq_lock)\n  put_niov_uref:\n    atomic_read(uref) - 1\n    // window opens\n                                        atomic_xchg(uref, 0) - 1\n                                        return_niov_freelist(niov) [PUSH #1]\n    // window closes\n    atomic_dec(uref) - wraps to -1\n    returns true\n    return_niov(niov)\n    return_niov_freelist(niov)           [PUSH #2: DOUBLE-FREE]\n\nThe same niov is pushed to the freelist twice, causing free_count to\nexceed nr_iovs. Subsequent freelist pushes then perform an out-of-bounds\nwrite (a u32 value) past the kvmalloc\u0027d freelist array into the adjacent\nslab object.\n\nFix this by replacing the non-atomic read-then-dec in\nio_zcrx_put_niov_uref() with an atomic_try_cmpxchg loop that atomically\ntests and decrements user_refs. This makes the operation safe against\nconcurrent atomic_xchg from scrub without requiring scrub to acquire\nrq_lock.\n\n[pavel: removed a warning and a comment]",
  "id": "GHSA-77p3-mmmp-fjj2",
  "modified": "2026-05-12T21:31:26Z",
  "published": "2026-05-06T12:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43121"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/003049b1c4fb8aabb93febb7d1e49004f6ad653b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/485dc691257b96e6d3bdc25b0eff2daadcc5c46c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a94f096e28bfc7975163a6b80f1c8f323efe317a"
    }
  ],
  "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-77QF-55VF-5V3V

Vulnerability from github – Published: 2025-10-01 12:30 – Updated: 2026-01-16 21:30
VLAI
Details

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

wifi: rtw89: fix potential race condition between napi_init and napi_enable

A race condition can happen if netdev is registered, but NAPI isn't initialized yet, and meanwhile user space starts the netdev that will enable NAPI. Then, it hits BUG_ON():

kernel BUG at net/core/dev.c:6423! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 417 Comm: iwd Not tainted 6.2.7-slab-dirty #3 eb0f5a8a9d91 Hardware name: LENOVO 21DL/LNVNB161216, BIOS JPCN20WW(V1.06) 09/20/2022 RIP: 0010:napi_enable+0x3f/0x50 Code: 48 89 c2 48 83 e2 f6 f6 81 89 08 00 00 02 74 0d 48 83 ... RSP: 0018:ffffada1414f3548 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa01425802080 RCX: 0000000000000000 RDX: 00000000000002ff RSI: ffffada14e50c614 RDI: ffffa01425808dc0 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000100 R12: ffffa01425808f58 R13: 0000000000000000 R14: ffffa01423498940 R15: 0000000000000001 FS: 00007f5577c0a740(0000) GS:ffffa0169fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5577a19972 CR3: 0000000125a7a000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: rtw89_pci_ops_start+0x1c/0x70 [rtw89_pci 6cbc75429515c181cbc386478d5cfb32ffc5a0f8] rtw89_core_start+0xbe/0x160 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22] rtw89_ops_start+0x26/0x40 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22] drv_start+0x42/0x100 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2] ieee80211_do_open+0x311/0x7d0 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2] ieee80211_open+0x6a/0x90 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2] __dev_open+0xe0/0x180 __dev_change_flags+0x1da/0x250 dev_change_flags+0x26/0x70 do_setlink+0x37c/0x12c0 ? ep_poll_callback+0x246/0x290 ? __nla_validate_parse+0x61/0xd00 ? __wake_up_common_lock+0x8f/0xd0

To fix this, follow Jonas' suggestion to switch the order of these functions and move register netdev to be the last step of PCI probe. Also, correct the error handling of rtw89_core_register_hw().

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-53452"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-01T12:15:43Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw89: fix potential race condition between napi_init and napi_enable\n\nA race condition can happen if netdev is registered, but NAPI isn\u0027t\ninitialized yet, and meanwhile user space starts the netdev that will\nenable NAPI. Then, it hits BUG_ON():\n\n kernel BUG at net/core/dev.c:6423!\n invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 0 PID: 417 Comm: iwd Not tainted 6.2.7-slab-dirty #3 eb0f5a8a9d91\n Hardware name: LENOVO 21DL/LNVNB161216, BIOS JPCN20WW(V1.06) 09/20/2022\n RIP: 0010:napi_enable+0x3f/0x50\n Code: 48 89 c2 48 83 e2 f6 f6 81 89 08 00 00 02 74 0d 48 83 ...\n RSP: 0018:ffffada1414f3548 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: ffffa01425802080 RCX: 0000000000000000\n RDX: 00000000000002ff RSI: ffffada14e50c614 RDI: ffffa01425808dc0\n RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000001 R11: 0000000000000100 R12: ffffa01425808f58\n R13: 0000000000000000 R14: ffffa01423498940 R15: 0000000000000001\n FS:  00007f5577c0a740(0000) GS:ffffa0169fc00000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f5577a19972 CR3: 0000000125a7a000 CR4: 0000000000750ef0\n PKRU: 55555554\n Call Trace:\n  \u003cTASK\u003e\n  rtw89_pci_ops_start+0x1c/0x70 [rtw89_pci 6cbc75429515c181cbc386478d5cfb32ffc5a0f8]\n  rtw89_core_start+0xbe/0x160 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22]\n  rtw89_ops_start+0x26/0x40 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22]\n  drv_start+0x42/0x100 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2]\n  ieee80211_do_open+0x311/0x7d0 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2]\n  ieee80211_open+0x6a/0x90 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2]\n  __dev_open+0xe0/0x180\n  __dev_change_flags+0x1da/0x250\n  dev_change_flags+0x26/0x70\n  do_setlink+0x37c/0x12c0\n  ? ep_poll_callback+0x246/0x290\n  ? __nla_validate_parse+0x61/0xd00\n  ? __wake_up_common_lock+0x8f/0xd0\n\nTo fix this, follow Jonas\u0027 suggestion to switch the order of these\nfunctions and move register netdev to be the last step of PCI probe.\nAlso, correct the error handling of rtw89_core_register_hw().",
  "id": "GHSA-77qf-55vf-5v3v",
  "modified": "2026-01-16T21:30:29Z",
  "published": "2025-10-01T12:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53452"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/39712c8aeb79691bcec8bd6ff658cde1651e0803"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/47515664ecfbde11425dff121f298ae4499425c9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/aa48073c2f993e1b0c0bc66b03ae105cac0130bc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b1b90c7df08ef385f95827ee3aee87bddd1ef5c5"
    }
  ],
  "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-77RM-8JVR-HFGM

Vulnerability from github – Published: 2024-09-16 18:31 – Updated: 2025-11-04 00:31
VLAI
Details

A race condition in UEFI firmware for some Intel(R) processors may allow a privileged user to potentially enable escalation of privilege via local access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-41833"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-16T17:15:59Z",
    "severity": "HIGH"
  },
  "details": "A race condition in UEFI firmware for some Intel(R) processors may allow a privileged user to potentially enable escalation of privilege via local access.",
  "id": "GHSA-77rm-8jvr-hfgm",
  "modified": "2025-11-04T00:31:25Z",
  "published": "2024-09-16T18:31:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41833"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20241011-0009"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01071.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/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-78P8-M8PR-GVC2

Vulnerability from github – Published: 2025-09-19 00:30 – Updated: 2025-09-19 00:30
VLAI
Details

Concurrent execution using shared resource with improper synchronization ('race condition') in Microsoft Graphics Component allows an authorized attacker to elevate privileges locally.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-59216"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-18T22:15:49Z",
    "severity": "HIGH"
  },
  "details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Microsoft Graphics Component allows an authorized attacker to elevate privileges locally.",
  "id": "GHSA-78p8-m8pr-gvc2",
  "modified": "2025-09-19T00:30:58Z",
  "published": "2025-09-19T00:30:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59216"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-59216"
    }
  ],
  "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-78Q2-767Q-6X6V

Vulnerability from github – Published: 2024-12-12 03:33 – Updated: 2024-12-12 03:33
VLAI
Details

Lightweight Directory Access Protocol (LDAP) Client Remote Code Execution Vulnerability

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-49124"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-12T02:04:39Z",
    "severity": "HIGH"
  },
  "details": "Lightweight Directory Access Protocol (LDAP) Client Remote Code Execution Vulnerability",
  "id": "GHSA-78q2-767q-6x6v",
  "modified": "2024-12-12T03:33:05Z",
  "published": "2024-12-12T03:33:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49124"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-49124"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design

In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.

Mitigation
Architecture and Design

Use thread-safe capabilities such as the data access abstraction in Spring.

Mitigation
Architecture and Design
  • 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
Implementation

When using multithreading and operating on shared variables, only use thread-safe functions.

Mitigation
Implementation

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
Implementation

Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.

Mitigation
Implementation

Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.

Mitigation
Implementation

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
Implementation

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
Architecture and Design Operation

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.