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.

2921 vulnerabilities reference this CWE, most recent first.

GHSA-J3G9-72CW-7WCP

Vulnerability from github – Published: 2024-02-27 12:31 – Updated: 2024-04-10 15:30
VLAI
Details

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

net/smc: fix kernel panic caused by race of smc_sock

A crash occurs when smc_cdc_tx_handler() tries to access smc_sock but smc_release() has already freed it.

[ 4570.695099] BUG: unable to handle page fault for address: 000000002eae9e88 [ 4570.696048] #PF: supervisor write access in kernel mode [ 4570.696728] #PF: error_code(0x0002) - not-present page [ 4570.697401] PGD 0 P4D 0 [ 4570.697716] Oops: 0002 [#1] PREEMPT SMP NOPTI [ 4570.698228] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.16.0-rc4+ #111 [ 4570.699013] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8c24b4c 04/0 [ 4570.699933] RIP: 0010:_raw_spin_lock+0x1a/0x30 <...> [ 4570.711446] Call Trace: [ 4570.711746] [ 4570.711992] smc_cdc_tx_handler+0x41/0xc0 [ 4570.712470] smc_wr_tx_tasklet_fn+0x213/0x560 [ 4570.712981] ? smc_cdc_tx_dismisser+0x10/0x10 [ 4570.713489] tasklet_action_common.isra.17+0x66/0x140 [ 4570.714083] __do_softirq+0x123/0x2f4 [ 4570.714521] irq_exit_rcu+0xc4/0xf0 [ 4570.714934] common_interrupt+0xba/0xe0

Though smc_cdc_tx_handler() checked the existence of smc connection, smc_release() may have already dismissed and released the smc socket before smc_cdc_tx_handler() further visits it.

smc_cdc_tx_handler() |smc_release() if (!conn) | | |smc_cdc_tx_dismiss_slots() | smc_cdc_tx_dismisser() | |sock_put(&smc->sk) <- last sock_put, | smc_sock freed bh_lock_sock(&smc->sk) (panic) |

To make sure we won't receive any CDC messages after we free the smc_sock, add a refcount on the smc_connection for inflight CDC message(posted to the QP but haven't received related CQE), and don't release the smc_connection until all the inflight CDC messages haven been done, for both success or failed ones.

Using refcount on CDC messages brings another problem: when the link is going to be destroyed, smcr_link_clear() will reset the QP, which then remove all the pending CQEs related to the QP in the CQ. To make sure all the CQEs will always come back so the refcount on the smc_connection can always reach 0, smc_ib_modify_qp_reset() was replaced by smc_ib_modify_qp_error(). And remove the timeout in smc_wr_tx_wait_no_pending_sends() since we need to wait for all pending WQEs done, or we may encounter use-after- free when handling CQEs.

For IB device removal routine, we need to wait for all the QPs on that device been destroyed before we can destroy CQs on the device, or the refcount on smc_connection won't reach 0 and smc_sock cannot be released.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-46925"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-27T10:15:07Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix kernel panic caused by race of smc_sock\n\nA crash occurs when smc_cdc_tx_handler() tries to access smc_sock\nbut smc_release() has already freed it.\n\n[ 4570.695099] BUG: unable to handle page fault for address: 000000002eae9e88\n[ 4570.696048] #PF: supervisor write access in kernel mode\n[ 4570.696728] #PF: error_code(0x0002) - not-present page\n[ 4570.697401] PGD 0 P4D 0\n[ 4570.697716] Oops: 0002 [#1] PREEMPT SMP NOPTI\n[ 4570.698228] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.16.0-rc4+ #111\n[ 4570.699013] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8c24b4c 04/0\n[ 4570.699933] RIP: 0010:_raw_spin_lock+0x1a/0x30\n\u003c...\u003e\n[ 4570.711446] Call Trace:\n[ 4570.711746]  \u003cIRQ\u003e\n[ 4570.711992]  smc_cdc_tx_handler+0x41/0xc0\n[ 4570.712470]  smc_wr_tx_tasklet_fn+0x213/0x560\n[ 4570.712981]  ? smc_cdc_tx_dismisser+0x10/0x10\n[ 4570.713489]  tasklet_action_common.isra.17+0x66/0x140\n[ 4570.714083]  __do_softirq+0x123/0x2f4\n[ 4570.714521]  irq_exit_rcu+0xc4/0xf0\n[ 4570.714934]  common_interrupt+0xba/0xe0\n\nThough smc_cdc_tx_handler() checked the existence of smc connection,\nsmc_release() may have already dismissed and released the smc socket\nbefore smc_cdc_tx_handler() further visits it.\n\nsmc_cdc_tx_handler()           |smc_release()\nif (!conn)                     |\n                               |\n                               |smc_cdc_tx_dismiss_slots()\n                               |      smc_cdc_tx_dismisser()\n                               |\n                               |sock_put(\u0026smc-\u003esk) \u003c- last sock_put,\n                               |                      smc_sock freed\nbh_lock_sock(\u0026smc-\u003esk) (panic) |\n\nTo make sure we won\u0027t receive any CDC messages after we free the\nsmc_sock, add a refcount on the smc_connection for inflight CDC\nmessage(posted to the QP but haven\u0027t received related CQE), and\ndon\u0027t release the smc_connection until all the inflight CDC messages\nhaven been done, for both success or failed ones.\n\nUsing refcount on CDC messages brings another problem: when the link\nis going to be destroyed, smcr_link_clear() will reset the QP, which\nthen remove all the pending CQEs related to the QP in the CQ. To make\nsure all the CQEs will always come back so the refcount on the\nsmc_connection can always reach 0, smc_ib_modify_qp_reset() was replaced\nby smc_ib_modify_qp_error().\nAnd remove the timeout in smc_wr_tx_wait_no_pending_sends() since we\nneed to wait for all pending WQEs done, or we may encounter use-after-\nfree when handling CQEs.\n\nFor IB device removal routine, we need to wait for all the QPs on that\ndevice been destroyed before we can destroy CQs on the device, or\nthe refcount on smc_connection won\u0027t reach 0 and smc_sock cannot be\nreleased.",
  "id": "GHSA-j3g9-72cw-7wcp",
  "modified": "2024-04-10T15:30:32Z",
  "published": "2024-02-27T12:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46925"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/349d43127dac00c15231e8ffbcaabd70f7b0e544"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b85f751d71ae8e2a15e9bda98852ea9af35282eb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e8a5988a85c719ce7205cb00dcf0716dcf611332"
    }
  ],
  "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-J3X6-VG5F-VX5P

Vulnerability from github – Published: 2022-09-27 00:00 – Updated: 2025-05-21 18:32
VLAI
Details

Use after free in SplitScreen in Google Chrome on Chrome OS, Lacros prior to 105.0.5195.52 allowed a remote attacker who convinced a user to engage in specific UI interactions to potentially exploit heap corruption via a crafted HTML page.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-3049"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362",
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-09-26T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "Use after free in SplitScreen in Google Chrome on Chrome OS, Lacros prior to 105.0.5195.52 allowed a remote attacker who convinced a user to engage in specific UI interactions to potentially exploit heap corruption via a crafted HTML page.",
  "id": "GHSA-j3x6-vg5f-vx5p",
  "modified": "2025-05-21T18:32:58Z",
  "published": "2022-09-27T00:00:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3049"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2022/08/stable-channel-update-for-desktop_30.html"
    },
    {
      "type": "WEB",
      "url": "https://crbug.com/1316892"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/T4NMJURTG5RO3TGD7ZMIQ6Z4ZZ3SAVYE"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/T4NMJURTG5RO3TGD7ZMIQ6Z4ZZ3SAVYE"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202209-23"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J48G-PW4C-X8JM

Vulnerability from github – Published: 2026-03-25 12:30 – Updated: 2026-04-24 18:30
VLAI
Details

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

cxl: Fix race of nvdimm_bus object when creating nvdimm objects

Found issue during running of cxl-translate.sh unit test. Adding a 3s sleep right before the test seems to make the issue reproduce fairly consistently. The cxl_translate module has dependency on cxl_acpi and causes orphaned nvdimm objects to reprobe after cxl_acpi is removed. The nvdimm_bus object is registered by the cxl_nvb object when cxl_acpi_probe() is called. With the nvdimm_bus object missing, __nd_device_register() will trigger NULL pointer dereference when accessing the dev->parent that points to &nvdimm_bus->dev.

[ 192.884510] BUG: kernel NULL pointer dereference, address: 000000000000006c [ 192.895383] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20250812-19.fc42 08/12/2025 [ 192.897721] Workqueue: cxl_port cxl_bus_rescan_queue [cxl_core] [ 192.899459] RIP: 0010:kobject_get+0xc/0x90 [ 192.924871] Call Trace: [ 192.925959] [ 192.926976] ? pm_runtime_init+0xb9/0xe0 [ 192.929712] __nd_device_register.part.0+0x4d/0xc0 [libnvdimm] [ 192.933314] __nvdimm_create+0x206/0x290 [libnvdimm] [ 192.936662] cxl_nvdimm_probe+0x119/0x1d0 [cxl_pmem] [ 192.940245] cxl_bus_probe+0x1a/0x60 [cxl_core] [ 192.943349] really_probe+0xde/0x380

This patch also relies on the previous change where devm_cxl_add_nvdimm_bridge() is called from drivers/cxl/pmem.c instead of drivers/cxl/core.c to ensure the dependency of cxl_acpi on cxl_pmem.

  1. Set probe_type of cxl_nvb to PROBE_FORCE_SYNCHRONOUS to ensure the driver is probed synchronously when add_device() is called.
  2. Add a check in __devm_cxl_add_nvdimm_bridge() to ensure that the cxl_nvb driver is attached during cxl_acpi_probe().
  3. Take the cxl_root uport_dev lock and the cxl_nvb->dev lock in devm_cxl_add_nvdimm() before checking nvdimm_bus is valid.
  4. Set cxl_nvdimm flag to CXL_NVD_F_INVALIDATED so cxl_nvdimm_probe() will exit with -EBUSY.

The removal of cxl_nvdimm devices should prevent any orphaned devices from probing once the nvdimm_bus is gone.

[ dj: Fixed 0-day reported kdoc issue. ] [ dj: Fix cxl_nvb reference leak on error. Gregory (kreview-0811365) ]

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-23348"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-25T11:16:33Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncxl: Fix race of nvdimm_bus object when creating nvdimm objects\n\nFound issue during running of cxl-translate.sh unit test. Adding a 3s\nsleep right before the test seems to make the issue reproduce fairly\nconsistently. The cxl_translate module has dependency on cxl_acpi and\ncauses orphaned nvdimm objects to reprobe after cxl_acpi is removed.\nThe nvdimm_bus object is registered by the cxl_nvb object when\ncxl_acpi_probe() is called. With the nvdimm_bus object missing,\n__nd_device_register() will trigger NULL pointer dereference when\naccessing the dev-\u003eparent that points to \u0026nvdimm_bus-\u003edev.\n\n[  192.884510] BUG: kernel NULL pointer dereference, address: 000000000000006c\n[  192.895383] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20250812-19.fc42 08/12/2025\n[  192.897721] Workqueue: cxl_port cxl_bus_rescan_queue [cxl_core]\n[  192.899459] RIP: 0010:kobject_get+0xc/0x90\n[  192.924871] Call Trace:\n[  192.925959]  \u003cTASK\u003e\n[  192.926976]  ? pm_runtime_init+0xb9/0xe0\n[  192.929712]  __nd_device_register.part.0+0x4d/0xc0 [libnvdimm]\n[  192.933314]  __nvdimm_create+0x206/0x290 [libnvdimm]\n[  192.936662]  cxl_nvdimm_probe+0x119/0x1d0 [cxl_pmem]\n[  192.940245]  cxl_bus_probe+0x1a/0x60 [cxl_core]\n[  192.943349]  really_probe+0xde/0x380\n\nThis patch also relies on the previous change where\ndevm_cxl_add_nvdimm_bridge() is called from drivers/cxl/pmem.c instead\nof drivers/cxl/core.c to ensure the dependency of cxl_acpi on cxl_pmem.\n\n1. Set probe_type of cxl_nvb to PROBE_FORCE_SYNCHRONOUS to ensure the\n   driver is probed synchronously when add_device() is called.\n2. Add a check in __devm_cxl_add_nvdimm_bridge() to ensure that the\n   cxl_nvb driver is attached during cxl_acpi_probe().\n3. Take the cxl_root uport_dev lock and the cxl_nvb-\u003edev lock in\n   devm_cxl_add_nvdimm() before checking nvdimm_bus is valid.\n4. Set cxl_nvdimm flag to CXL_NVD_F_INVALIDATED so cxl_nvdimm_probe()\n   will exit with -EBUSY.\n\nThe removal of cxl_nvdimm devices should prevent any orphaned devices\nfrom probing once the nvdimm_bus is gone.\n\n[ dj: Fixed 0-day reported kdoc issue. ]\n[ dj: Fix cxl_nvb reference leak on error. Gregory (kreview-0811365) ]",
  "id": "GHSA-j48g-pw4c-x8jm",
  "modified": "2026-04-24T18:30:40Z",
  "published": "2026-03-25T12:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23348"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5b230daeee420833287cc77314439903e5312f10"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5fc4e150c5ada5f7d20d8f9f1b351f10481fbdf7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/96a1fd0d84b17360840f344826897fa71049870e"
    }
  ],
  "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-J48M-H7XQ-2XPJ

Vulnerability from github – Published: 2026-07-01 21:59 – Updated: 2026-07-01 21:59
VLAI
Summary
goshs: Share-link ?token=… redemption races past download limit
Details

Share-link ?token=… redemption races past download limit

Ecosystem: Go Package: goshs.de/goshs/v2 (github.com/patrickhener/goshs) Affected: <= v2.0.9 (every release that shipped the share-link feature)

Summary

ShareHandler reads the share token's DownloadLimit under RLock, releases the lock, serves the file, then re-acquires the lock to increment the counter. Concurrent requests all read the same Downloaded/DownloadLimit snapshot, all pass the check, and all are served — exceeding the operator's intended cap.

Details

httpserver/handler.go:968-1018:

fs.sharedLinksMu.RLock()
entry, ok := fs.SharedLinks[token]
fs.sharedLinksMu.RUnlock()                       // <-- released here

if entry.DownloadLimit > 0 || entry.DownloadLimit == -1 {
    // ...serve file...                          // <-- whole transfer happens unlocked
}

fs.sharedLinksMu.Lock()                          // <-- re-acquired only now
current.Downloaded++
if current.Downloaded >= current.DownloadLimit { delete(fs.SharedLinks, token) }
fs.sharedLinksMu.Unlock()

Between line 978 (RUnlock) and line 1008 (Lock), any number of goroutines can interleave and each observes the same pre-increment limit.

Proof of concept

goshs -p 18000 -d /tmp/r -b admin:pw &
echo data > /tmp/r/f.txt

# operator issues a one-shot share
SHARE=$(curl -su admin:pw "http://localhost:18000/f.txt?share&limit=1")
TK=$(echo "$SHARE" | sed -n 's/.*token=\([^"]*\)".*/\1/p')

# attacker races two redemptions
curl -so /dev/null -w "%{http_code}\n" "http://localhost:18000/?token=$TK" & \
curl -so /dev/null -w "%{http_code}\n" "http://localhost:18000/?token=$TK" & \
wait
# observed: 200 / 200 (both succeed) -> limit=1 redeemed twice

Reproduced 5/5 times in a row on a 2026-era M-series Mac during verification.

Impact

A "single-use" share intended to deliver a one-shot secret can be redeemed N times by N concurrent clients. Combined with any token-leak vector (mail forwarding, browser history, intercepted link, etc.) this multiplies the exfiltration window.

Suggested fix

Reserve under the write lock before serving — refund only if the serve fails:

fs.sharedLinksMu.Lock()
entry, ok := fs.SharedLinks[token]
if !ok || time.Now().After(entry.Expires) ||
   (entry.DownloadLimit != -1 && entry.Downloaded >= entry.DownloadLimit) {
    fs.sharedLinksMu.Unlock(); http.NotFound(w, r); return
}
entry.Downloaded++
if entry.DownloadLimit != -1 && entry.Downloaded >= entry.DownloadLimit {
    delete(fs.SharedLinks, token)
} else {
    fs.SharedLinks[token] = entry
}
fs.sharedLinksMu.Unlock()
// ...serve...

Add a regression test that races two requests against a limit=1 token and asserts exactly one 200.

Reporter: Nishant Verma. Reproduced against goshs v2.0.9 (commit 8fc1e91) on 2026-05-27.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.0.9"
      },
      "package": {
        "ecosystem": "Go",
        "name": "goshs.de/goshs/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-50139"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-01T21:59:08Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "# Share-link `?token=\u2026` redemption races past download limit\n\n**Ecosystem:** Go\n**Package:** `goshs.de/goshs/v2` (`github.com/patrickhener/goshs`)\n**Affected:** `\u003c= v2.0.9` (every release that shipped the share-link feature)\n\n## Summary\n\n`ShareHandler` reads the share token\u0027s `DownloadLimit` under `RLock`, releases the lock, serves the file, then re-acquires the lock to increment the counter. Concurrent requests all read the same `Downloaded`/`DownloadLimit` snapshot, all pass the check, and all are served \u2014 exceeding the operator\u0027s intended cap.\n\n## Details\n\n[`httpserver/handler.go:968-1018`](https://github.com/patrickhener/goshs/blob/v2.0.9/httpserver/handler.go#L968-L1018):\n\n```go\nfs.sharedLinksMu.RLock()\nentry, ok := fs.SharedLinks[token]\nfs.sharedLinksMu.RUnlock()                       // \u003c-- released here\n\nif entry.DownloadLimit \u003e 0 || entry.DownloadLimit == -1 {\n    // ...serve file...                          // \u003c-- whole transfer happens unlocked\n}\n\nfs.sharedLinksMu.Lock()                          // \u003c-- re-acquired only now\ncurrent.Downloaded++\nif current.Downloaded \u003e= current.DownloadLimit { delete(fs.SharedLinks, token) }\nfs.sharedLinksMu.Unlock()\n```\n\nBetween line 978 (`RUnlock`) and line 1008 (`Lock`), any number of goroutines can interleave and each observes the same pre-increment limit.\n\n## Proof of concept\n\n```bash\ngoshs -p 18000 -d /tmp/r -b admin:pw \u0026\necho data \u003e /tmp/r/f.txt\n\n# operator issues a one-shot share\nSHARE=$(curl -su admin:pw \"http://localhost:18000/f.txt?share\u0026limit=1\")\nTK=$(echo \"$SHARE\" | sed -n \u0027s/.*token=\\([^\"]*\\)\".*/\\1/p\u0027)\n\n# attacker races two redemptions\ncurl -so /dev/null -w \"%{http_code}\\n\" \"http://localhost:18000/?token=$TK\" \u0026 \\\ncurl -so /dev/null -w \"%{http_code}\\n\" \"http://localhost:18000/?token=$TK\" \u0026 \\\nwait\n# observed: 200 / 200 (both succeed) -\u003e limit=1 redeemed twice\n```\n\nReproduced 5/5 times in a row on a 2026-era M-series Mac during verification.\n\n## Impact\n\nA \"single-use\" share intended to deliver a one-shot secret can be redeemed N times by N concurrent clients. Combined with any token-leak vector (mail forwarding, browser history, intercepted link, etc.) this multiplies the exfiltration window.\n\n## Suggested fix\n\nReserve under the write lock *before* serving \u2014 refund only if the serve fails:\n\n```go\nfs.sharedLinksMu.Lock()\nentry, ok := fs.SharedLinks[token]\nif !ok || time.Now().After(entry.Expires) ||\n   (entry.DownloadLimit != -1 \u0026\u0026 entry.Downloaded \u003e= entry.DownloadLimit) {\n    fs.sharedLinksMu.Unlock(); http.NotFound(w, r); return\n}\nentry.Downloaded++\nif entry.DownloadLimit != -1 \u0026\u0026 entry.Downloaded \u003e= entry.DownloadLimit {\n    delete(fs.SharedLinks, token)\n} else {\n    fs.SharedLinks[token] = entry\n}\nfs.sharedLinksMu.Unlock()\n// ...serve...\n```\n\nAdd a regression test that races two requests against a `limit=1` token and asserts exactly one `200`.\n\nReporter: Nishant Verma. Reproduced against `goshs v2.0.9` (commit `8fc1e91`) on 2026-05-27.",
  "id": "GHSA-j48m-h7xq-2xpj",
  "modified": "2026-07-01T21:59:08Z",
  "published": "2026-07-01T21:59:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/patrickhener/goshs/security/advisories/GHSA-j48m-h7xq-2xpj"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/patrickhener/goshs"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "goshs: Share-link ?token=\u2026 redemption races past download limit"
}

GHSA-J4GV-C6JH-PVHM

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

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

nouveau: lock the client object tree.

It appears the client object tree has no locking unless I've missed something else. Fix races around adding/removing client objects, mostly vram bar mappings.

4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI [ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 [ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 [ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau] [ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 <48> 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe [ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206 [ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58 [ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400 [ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000 [ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0 [ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007 [ 4562.099528] FS: 00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000 [ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0 [ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4562.099544] Call Trace: [ 4562.099555] [ 4562.099573] ? die_addr+0x36/0x90 [ 4562.099583] ? exc_general_protection+0x246/0x4a0 [ 4562.099593] ? asm_exc_general_protection+0x26/0x30 [ 4562.099600] ? nvkm_object_search+0x1d/0x70 [nouveau] [ 4562.099730] nvkm_ioctl+0xa1/0x250 [nouveau] [ 4562.099861] nvif_object_map_handle+0xc8/0x180 [nouveau] [ 4562.099986] nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau] [ 4562.100156] ? dma_resv_test_signaled+0x26/0xb0 [ 4562.100163] ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm] [ 4562.100182] ? __mutex_unlock_slowpath+0x2a/0x270 [ 4562.100189] nouveau_ttm_fault+0x69/0xb0 [nouveau] [ 4562.100356] __do_fault+0x32/0x150 [ 4562.100362] do_fault+0x7c/0x560 [ 4562.100369] __handle_mm_fault+0x800/0xc10 [ 4562.100382] handle_mm_fault+0x17c/0x3e0 [ 4562.100388] do_user_addr_fault+0x208/0x860 [ 4562.100395] exc_page_fault+0x7f/0x200 [ 4562.100402] asm_exc_page_fault+0x26/0x30 [ 4562.100412] RIP: 0033:0x9b9870 [ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 <44> 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7 [ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246 [ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000 [ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066 [ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000 [ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff [ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 4562.100446] [ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink ---truncated---

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-27062"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-01T13:15:50Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnouveau: lock the client object tree.\n\nIt appears the client object tree has no locking unless I\u0027ve missed\nsomething else. Fix races around adding/removing client objects,\nmostly vram bar mappings.\n\n 4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI\n[ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27\n[ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021\n[ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau]\n[ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 \u003c48\u003e 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe\n[ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206\n[ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58\n[ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400\n[ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000\n[ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0\n[ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007\n[ 4562.099528] FS:  00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000\n[ 4562.099534] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0\n[ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 4562.099544] Call Trace:\n[ 4562.099555]  \u003cTASK\u003e\n[ 4562.099573]  ? die_addr+0x36/0x90\n[ 4562.099583]  ? exc_general_protection+0x246/0x4a0\n[ 4562.099593]  ? asm_exc_general_protection+0x26/0x30\n[ 4562.099600]  ? nvkm_object_search+0x1d/0x70 [nouveau]\n[ 4562.099730]  nvkm_ioctl+0xa1/0x250 [nouveau]\n[ 4562.099861]  nvif_object_map_handle+0xc8/0x180 [nouveau]\n[ 4562.099986]  nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau]\n[ 4562.100156]  ? dma_resv_test_signaled+0x26/0xb0\n[ 4562.100163]  ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm]\n[ 4562.100182]  ? __mutex_unlock_slowpath+0x2a/0x270\n[ 4562.100189]  nouveau_ttm_fault+0x69/0xb0 [nouveau]\n[ 4562.100356]  __do_fault+0x32/0x150\n[ 4562.100362]  do_fault+0x7c/0x560\n[ 4562.100369]  __handle_mm_fault+0x800/0xc10\n[ 4562.100382]  handle_mm_fault+0x17c/0x3e0\n[ 4562.100388]  do_user_addr_fault+0x208/0x860\n[ 4562.100395]  exc_page_fault+0x7f/0x200\n[ 4562.100402]  asm_exc_page_fault+0x26/0x30\n[ 4562.100412] RIP: 0033:0x9b9870\n[ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 \u003c44\u003e 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7\n[ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246\n[ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000\n[ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066\n[ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000\n[ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff\n[ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[ 4562.100446]  \u003c/TASK\u003e\n[ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink \n---truncated---",
  "id": "GHSA-j4gv-c6jh-pvhm",
  "modified": "2024-11-05T18:31:58Z",
  "published": "2024-05-01T15:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27062"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6887314f5356389fc219b8152e951ac084a10ef7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/96c8751844171af4b3898fee3857ee180586f589"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b7cc4ff787a572edf2c55caeffaa88cd801eb135"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J4R9-G979-RC2X

Vulnerability from github – Published: 2026-07-19 06:30 – Updated: 2026-07-19 06:30
VLAI
Details

A flaw has been found in django-tastypie up to 0.15.1. The affected element is the function CacheThrottle/CacheDBThrottle of the file tastypie/throttle.py. This manipulation causes race condition. The attack may be initiated remotely. The complexity of an attack is rather high. The exploitability is described as difficult. The project was informed of the problem early through an issue report but has not responded yet.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-16208"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-19T04:17:03Z",
    "severity": "LOW"
  },
  "details": "A flaw has been found in django-tastypie up to 0.15.1. The affected element is the function CacheThrottle/CacheDBThrottle of the file tastypie/throttle.py. This manipulation causes race condition. The attack may be initiated remotely. The complexity of an attack is rather high. The exploitability is described as difficult. The project was informed of the problem early through an issue report but has not responded yet.",
  "id": "GHSA-j4r9-g979-rc2x",
  "modified": "2026-07-19T06:30:23Z",
  "published": "2026-07-19T06:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-16208"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django-tastypie/django-tastypie/issues/1700"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django-tastypie/django-tastypie"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/cve/CVE-2026-16208"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/857925"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/380024"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/380024/cti"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-J4WC-X6GV-2P4C

Vulnerability from github – Published: 2025-03-14 00:30 – Updated: 2025-03-14 00:30
VLAI
Details

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

af_unix: Fix a data-race in unix_dgram_peer_wake_me().

unix_dgram_poll() calls unix_dgram_peer_wake_me() without other's lock held and check if its receive queue is full. Here we need to use unix_recvq_full_lockless() instead of unix_recvq_full(), otherwise KCSAN will report a data-race.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-49344"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:01:11Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Fix a data-race in unix_dgram_peer_wake_me().\n\nunix_dgram_poll() calls unix_dgram_peer_wake_me() without `other`\u0027s\nlock held and check if its receive queue is full.  Here we need to\nuse unix_recvq_full_lockless() instead of unix_recvq_full(), otherwise\nKCSAN will report a data-race.",
  "id": "GHSA-j4wc-x6gv-2p4c",
  "modified": "2025-03-14T00:30:51Z",
  "published": "2025-03-14T00:30:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49344"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/556720013c36c193d9cbfb06e7b33e51f0c39fbf"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/662a80946ce13633ae90a55379f1346c10f0c432"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/71e8bfc7f838cabc60cba24e09ca84c4f8321ab2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8801eb3ccd2e4e3b1a01449383e3321ae6dbd9d6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/95f0ba806277733bf6024e23e27e1be773701cca"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c61848500a3fd6867dfa4834b8c7f97133eceb9f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c926ae58f24f7bd55aa2ea4add9f952032507913"
    }
  ],
  "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-J52X-JWVH-C5GG

Vulnerability from github – Published: 2022-05-24 16:49 – Updated: 2024-04-04 01:10
VLAI
Details

modules/luksbootkeyfile/main.py in Calamares through 3.2.4 has a race condition between the time when the LUKS encryption keyfile is created and when secure permissions are set.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-13178"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-07-02T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "modules/luksbootkeyfile/main.py in Calamares through 3.2.4 has a race condition between the time when the LUKS encryption keyfile is created and when secure permissions are set.",
  "id": "GHSA-j52x-jwvh-c5gg",
  "modified": "2024-04-04T01:10:30Z",
  "published": "2022-05-24T16:49:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-13178"
    },
    {
      "type": "WEB",
      "url": "https://github.com/calamares/calamares/issues/1190"
    },
    {
      "type": "WEB",
      "url": "https://github.com/calamares/calamares/issues/1191"
    },
    {
      "type": "WEB",
      "url": "https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835095"
    },
    {
      "type": "WEB",
      "url": "https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835096"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1726565"
    },
    {
      "type": "WEB",
      "url": "https://calamares.io/calamares-3.2.11-is-out"
    },
    {
      "type": "WEB",
      "url": "https://calamares.io/calamares-cve-2019"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/Q57BOTBA2J5U4GVKUP7N2PD5H7B3BVUU"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/R2ZDQRGBGRVRW5LPJWKUNS3M66LZ3KYC"
    },
    {
      "type": "WEB",
      "url": "https://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption"
    },
    {
      "type": "WEB",
      "url": "https://www.pavelkogan.com/2015/01/25/linux-mint-encryption"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-12/msg00017.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-12/msg00020.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-12/msg00021.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J54F-WWR3-4RXM

Vulnerability from github – Published: 2025-03-10 21:31 – Updated: 2025-03-10 21:31
VLAI
Details

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

tcp: Fix a data-race around sysctl_tcp_probe_interval.

While reading sysctl_tcp_probe_interval, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-49593"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:01:34Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: Fix a data-race around sysctl_tcp_probe_interval.\n\nWhile reading sysctl_tcp_probe_interval, it can be changed concurrently.\nThus, we need to add READ_ONCE() to its reader.",
  "id": "GHSA-j54f-wwr3-4rxm",
  "modified": "2025-03-10T21:31:11Z",
  "published": "2025-03-10T21:31:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49593"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2a85388f1d94a9f8b5a529118a2c5eaa0520d85c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/73a11588751a2c13f25d9da8117efc9a79b1843f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/80dabd089086e6553b7acfcff2ec223bdada87a1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b14cc8afbbcbc6dce4797913c0b85266b897f541"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b3798d3519eda9c409bb0815b0102f27ec42468d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c61aede097d350d890fa1edc9521b0072e14a0b8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e6b6f027e2854a51f345a5e3e808d7a88001d4f8"
    }
  ],
  "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-J55M-HP7R-R977

Vulnerability from github – Published: 2022-05-17 04:15 – Updated: 2022-05-17 04:15
VLAI
Details

Race condition in the SSL implementation on Cisco Intrusion Prevention System (IPS) devices allows remote attackers to cause a denial of service by making many management-interface HTTPS connections during the key-regeneration phase of an upgrade, aka Bug ID CSCui25688.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2015-0631"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2015-02-21T11:59:00Z",
    "severity": "HIGH"
  },
  "details": "Race condition in the SSL implementation on Cisco Intrusion Prevention System (IPS) devices allows remote attackers to cause a denial of service by making many management-interface HTTPS connections during the key-regeneration phase of an upgrade, aka Bug ID CSCui25688.",
  "id": "GHSA-j55m-hp7r-r977",
  "modified": "2022-05-17T04:15:16Z",
  "published": "2022-05-17T04:15:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-0631"
    },
    {
      "type": "WEB",
      "url": "http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2015-0631"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/72700"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1031780"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

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.