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.

2923 vulnerabilities reference this CWE, most recent first.

GHSA-8Q64-WRFR-Q48C

Vulnerability from github – Published: 2021-08-25 20:59 – Updated: 2021-08-24 17:59
VLAI
Summary
Data races in model
Details

Shared data structure in model crate implements Send and Sync traits regardless of the inner type. This allows safe Rust code to trigger a data race, which is undefined behavior in Rust.

Users are advised to treat Shared as an unsafe type. It should not be used outside of the testing context, and care must be taken so that the testing code does not have a data race besides a race condition that is expected to be caught by the test.

Check the Rustonomicon for the difference between a data race and a general race condition.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "model"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-08-09T17:22:47Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "`Shared` data structure in `model` crate implements `Send` and `Sync` traits regardless of the inner type.\nThis allows safe Rust code to trigger a data race, which is undefined behavior in Rust.\n\nUsers are advised to treat `Shared` as an unsafe type.\nIt should not be used outside of the testing context,\nand care must be taken so that the testing code does not have a data race\nbesides a race condition that is expected to be caught by the test.\n\nCheck [the Rustonomicon](https://doc.rust-lang.org/nomicon/races.html) for the difference between\na data race and a general race condition.\n",
  "id": "GHSA-8q64-wrfr-q48c",
  "modified": "2021-08-24T17:59:47Z",
  "published": "2021-08-25T20:59:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/spacejam/model/issues/3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/spacejam/model"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2020-0140.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Data races in model",
  "withdrawn": "2021-08-24T17:59:47Z"
}

GHSA-8Q7V-5P8J-CFCG

Vulnerability from github – Published: 2026-05-13 21:32 – Updated: 2026-07-14 18:31
VLAI
Details

A race condition vulnerability in Palo Alto Networks Prisma® Browser enables a locally authenticated non-admin user to bypass certain access and data control policies.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-0235"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362",
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-13T19:16:56Z",
    "severity": "MODERATE"
  },
  "details": "A race condition vulnerability in Palo Alto Networks Prisma\u00ae Browser enables a locally authenticated non-admin user to bypass certain access and data control policies.",
  "id": "GHSA-8q7v-5p8j-cfcg",
  "modified": "2026-07-14T18:31:45Z",
  "published": "2026-05-13T21:32:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0235"
    },
    {
      "type": "WEB",
      "url": "https://security.paloaltonetworks.com/CVE-2026-0235"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:L/VA:N/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:N/R:U/V:D/RE:M/U:Amber",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-8QQF-QHMM-W3CM

Vulnerability from github – Published: 2022-05-24 17:17 – Updated: 2023-02-02 15:30
VLAI
Details

The fix for CVE-2019-11599, affecting the Linux kernel before 5.0.10 was not complete. A local user could use this flaw to obtain sensitive information, cause a denial of service, or possibly have other unspecified impacts by triggering a race condition with mmget_not_zero or get_task_mm calls.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-14898"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-05-08T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The fix for CVE-2019-11599, affecting the Linux kernel before 5.0.10 was not complete. A local user could use this flaw to obtain sensitive information, cause a denial of service, or possibly have other unspecified impacts by triggering a race condition with mmget_not_zero or get_task_mm calls.",
  "id": "GHSA-8qqf-qhmm-w3cm",
  "modified": "2023-02-02T15:30:27Z",
  "published": "2022-05-24T17:17:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14898"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0328"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0339"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0374"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0375"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2019-14898"
    },
    {
      "type": "WEB",
      "url": "https://bugs.chromium.org/p/project-zero/issues/detail?id=1790"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1774671"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-14898"
    },
    {
      "type": "WEB",
      "url": "https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.114"
    },
    {
      "type": "WEB",
      "url": "https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.37"
    },
    {
      "type": "WEB",
      "url": "https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.0.10"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20200608-0001"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
    }
  ],
  "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-8QVJ-HVVG-8W4C

Vulnerability from github – Published: 2022-01-05 00:00 – Updated: 2023-08-08 15:31
VLAI
Details

In vow driver, there is a possible memory corruption due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS05837742; Issue ID: ALPS05837742.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-20013"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-04T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In vow driver, there is a possible memory corruption due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS05837742; Issue ID: ALPS05837742.",
  "id": "GHSA-8qvj-hvvg-8w4c",
  "modified": "2023-08-08T15:31:30Z",
  "published": "2022-01-05T00:00:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20013"
    },
    {
      "type": "WEB",
      "url": "https://corp.mediatek.com/product-security-bulletin/January-2022"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8QWR-XCGG-6RCV

Vulnerability from github – Published: 2022-05-02 03:29 – Updated: 2022-05-02 03:29
VLAI
Details

Race condition in PulseAudio 0.9.9, 0.9.10, and 0.9.14 allows local users to gain privileges via vectors involving creation of a hard link, related to the application setting LD_BIND_NOW to 1, and then calling execv on the target of the /proc/self/exe symlink.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2009-1894"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2009-07-17T16:30:00Z",
    "severity": "HIGH"
  },
  "details": "Race condition in PulseAudio 0.9.9, 0.9.10, and 0.9.14 allows local users to gain privileges via vectors involving creation of a hard link, related to the application setting LD_BIND_NOW to 1, and then calling execv on the target of the /proc/self/exe symlink.",
  "id": "GHSA-8qwr-xcgg-6rcv",
  "modified": "2022-05-02T03:29:37Z",
  "published": "2022-05-02T03:29:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2009-1894"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2009-1894"
    },
    {
      "type": "WEB",
      "url": "https://admin.fedoraproject.org/updates/pulseaudio-0.9.10-1.el5.2"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=510071"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/51804"
    },
    {
      "type": "WEB",
      "url": "http://blog.cr0.org/2009/07/old-school-local-root-vulnerability-in.html"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/35868"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/35886"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/35896"
    },
    {
      "type": "WEB",
      "url": "http://security.gentoo.org/glsa/glsa-200907-13.xml"
    },
    {
      "type": "WEB",
      "url": "http://taviso.decsystem.org/research.html"
    },
    {
      "type": "WEB",
      "url": "http://www.akitasecurity.nl/advisory.php?id=AK20090602"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2009/dsa-1838"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDVSA-2009:152"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDVSA-2009:171"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/505052/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/35721"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/usn-804-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-8QXJ-9W4F-X6Q7

Vulnerability from github – Published: 2025-03-04 09:30 – Updated: 2025-03-04 09:30
VLAI
Details

Multi-thread problem vulnerability in the package management module Impact: Successful exploitation of this vulnerability may affect availability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-58048"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-04T08:15:35Z",
    "severity": "MODERATE"
  },
  "details": "Multi-thread problem vulnerability in the package management module\nImpact: Successful exploitation of this vulnerability may affect availability.",
  "id": "GHSA-8qxj-9w4f-x6q7",
  "modified": "2025-03-04T09:30:39Z",
  "published": "2025-03-04T09:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58048"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2025/3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8R38-JRWH-8GRW

Vulnerability from github – Published: 2023-01-12 06:30 – Updated: 2023-01-20 18:30
VLAI
Details

An issue has been discovered in GitLab CE/EE affecting all versions before 15.5.7, all versions starting from 15.6 before 15.6.4, all versions starting from 15.7 before 15.7.2. A race condition can lead to verified email forgery and takeover of third-party accounts when using GitLab as an OAuth provider.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-4037"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-12T04:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue has been discovered in GitLab CE/EE affecting all versions before 15.5.7, all versions starting from 15.6 before 15.6.4, all versions starting from 15.7 before 15.7.2. A race condition can lead to verified email forgery and takeover of third-party accounts when using GitLab as an OAuth provider.",
  "id": "GHSA-8r38-jrwh-8grw",
  "modified": "2023-01-20T18:30:23Z",
  "published": "2023-01-12T06:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4037"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1772543"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-4037.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/382957"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8R49-FWCV-VHR4

Vulnerability from github – Published: 2025-03-18 21:32 – Updated: 2025-03-18 21:32
VLAI
Details

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

xsk: Fix race at socket teardown

Fix a race in the xsk socket teardown code that can lead to a NULL pointer dereference splat. The current xsk unbind code in xsk_unbind_dev() starts by setting xs->state to XSK_UNBOUND, sets xs->dev to NULL and then waits for any NAPI processing to terminate using synchronize_net(). After that, the release code starts to tear down the socket state and free allocated memory.

BUG: kernel NULL pointer dereference, address: 00000000000000c0 PGD 8000000932469067 P4D 8000000932469067 PUD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G I 5.16.0+ #2 Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015 RIP: 0010:__xsk_sendmsg+0x2c/0x690 [...] RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258 RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800 RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800 R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000 FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0 Call Trace: ? aa_sk_perm+0x43/0x1b0 xsk_sendmsg+0xf0/0x110 sock_sendmsg+0x65/0x70 __sys_sendto+0x113/0x190 ? debug_smp_processor_id+0x17/0x20 ? fpregs_assert_state_consistent+0x23/0x50 ? exit_to_user_mode_prepare+0xa5/0x1d0 __x64_sys_sendto+0x29/0x30 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae

There are two problems with the current code. First, setting xs->dev to NULL before waiting for all users to stop using the socket is not correct. The entry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg() are all guarded by a test that xs->state is in the state XSK_BOUND and if not, it returns right away. But one process might have passed this test but still have not gotten to the point in which it uses xs->dev in the code. In this interim, a second process executing xsk_unbind_dev() might have set xs->dev to NULL which will lead to a crash for the first process. The solution here is just to get rid of this NULL assignment since it is not used anymore. Before commit 42fddcc7c64b ("xsk: use state member for socket synchronization"), xs->dev was the gatekeeper to admit processes into the data plane functions, but it was replaced with the state variable xs->state in the aforementioned commit.

The second problem is that synchronize_net() does not wait for any process in xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that the state they rely on might be cleaned up prematurely. This can happen when the notifier gets called (at driver unload for example) as it uses xsk_unbind_dev(). Solve this by extending the RCU critical region from just the ndo_xsk_wakeup to the whole functions mentioned above, so that both the test of xs->state == XSK_BOUND and the last use of any member of xs is covered by the RCU critical section. This will guarantee that when synchronize_net() completes, there will be no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() and state can be cleaned up safely. Note that we need to drop the RCU lock for the skb xmit path as it uses functions that might sleep. Due to this, we have to retest the xs->state after we grab the mutex that protects the skb xmit code from, among a number of things, an xsk_unbind_dev() being executed from the notifier at the same time.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-49215"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362",
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:00:58Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nxsk: Fix race at socket teardown\n\nFix a race in the xsk socket teardown code that can lead to a NULL pointer\ndereference splat. The current xsk unbind code in xsk_unbind_dev() starts by\nsetting xs-\u003estate to XSK_UNBOUND, sets xs-\u003edev to NULL and then waits for any\nNAPI processing to terminate using synchronize_net(). After that, the release\ncode starts to tear down the socket state and free allocated memory.\n\n  BUG: kernel NULL pointer dereference, address: 00000000000000c0\n  PGD 8000000932469067 P4D 8000000932469067 PUD 0\n  Oops: 0000 [#1] PREEMPT SMP PTI\n  CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G          I       5.16.0+ #2\n  Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015\n  RIP: 0010:__xsk_sendmsg+0x2c/0x690\n  [...]\n  RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246\n  RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258\n  RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800\n  RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000\n  R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800\n  R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000\n  FS:  00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0\n  Call Trace:\n  \u003cTASK\u003e\n  ? aa_sk_perm+0x43/0x1b0\n  xsk_sendmsg+0xf0/0x110\n  sock_sendmsg+0x65/0x70\n  __sys_sendto+0x113/0x190\n  ? debug_smp_processor_id+0x17/0x20\n  ? fpregs_assert_state_consistent+0x23/0x50\n  ? exit_to_user_mode_prepare+0xa5/0x1d0\n  __x64_sys_sendto+0x29/0x30\n  do_syscall_64+0x3b/0xc0\n  entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nThere are two problems with the current code. First, setting xs-\u003edev to NULL\nbefore waiting for all users to stop using the socket is not correct. The\nentry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg()\nare all guarded by a test that xs-\u003estate is in the state XSK_BOUND and if not,\nit returns right away. But one process might have passed this test but still\nhave not gotten to the point in which it uses xs-\u003edev in the code. In this\ninterim, a second process executing xsk_unbind_dev() might have set xs-\u003edev to\nNULL which will lead to a crash for the first process. The solution here is\njust to get rid of this NULL assignment since it is not used anymore. Before\ncommit 42fddcc7c64b (\"xsk: use state member for socket synchronization\"),\nxs-\u003edev was the gatekeeper to admit processes into the data plane functions,\nbut it was replaced with the state variable xs-\u003estate in the aforementioned\ncommit.\n\nThe second problem is that synchronize_net() does not wait for any process in\nxsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that the\nstate they rely on might be cleaned up prematurely. This can happen when the\nnotifier gets called (at driver unload for example) as it uses xsk_unbind_dev().\nSolve this by extending the RCU critical region from just the ndo_xsk_wakeup\nto the whole functions mentioned above, so that both the test of xs-\u003estate ==\nXSK_BOUND and the last use of any member of xs is covered by the RCU critical\nsection. This will guarantee that when synchronize_net() completes, there will\nbe no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() and\nstate can be cleaned up safely. Note that we need to drop the RCU lock for the\nskb xmit path as it uses functions that might sleep. Due to this, we have to\nretest the xs-\u003estate after we grab the mutex that protects the skb xmit code\nfrom, among a number of things, an xsk_unbind_dev() being executed from the\nnotifier at the same time.",
  "id": "GHSA-8r49-fwcv-vhr4",
  "modified": "2025-03-18T21:32:00Z",
  "published": "2025-03-18T21:32:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49215"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/18b1ab7aa76bde181bdb1ab19a87fa9523c32f21"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8a2dea162b92c322f3e42eae0c4a74b8d20aa7a9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ad7219cd8751bd258b9d1e69ae0654ec00f71875"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d1579253ffce39986e7a6ab757ac93b2680a665f"
    }
  ],
  "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-8R4R-8C3P-6R95

Vulnerability from github – Published: 2024-10-21 18:30 – Updated: 2025-11-04 00:31
VLAI
Details

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

tracing/timerlat: Fix a race during cpuhp processing

There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally:

ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220
WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0
Modules linked in:
CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:debug_print_object+0x7d/0xb0
...
Call Trace:
 <TASK>
 ? __warn+0x7c/0x110
 ? debug_print_object+0x7d/0xb0
 ? report_bug+0xf1/0x1d0
 ? prb_read_valid+0x17/0x20
 ? handle_bug+0x3f/0x70
 ? exc_invalid_op+0x13/0x60
 ? asm_exc_invalid_op+0x16/0x20
 ? debug_print_object+0x7d/0xb0
 ? debug_print_object+0x7d/0xb0
 ? __pfx_timerlat_irq+0x10/0x10
 __debug_object_init+0x110/0x150
 hrtimer_init+0x1d/0x60
 timerlat_main+0xab/0x2d0
 ? __pfx_timerlat_main+0x10/0x10
 kthread+0xb7/0xe0
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x2d/0x40
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
 </TASK>

After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU:

T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() |

To fix this, skip online processing if the CPU is already offline.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-49866"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-21T18:15:06Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing/timerlat: Fix a race during cpuhp processing\n\nThere is another found exception that the \"timerlat/1\" thread was\nscheduled on CPU0, and lead to timer corruption finally:\n\n```\nODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220\nWARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0\nModules linked in:\nCPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\nRIP: 0010:debug_print_object+0x7d/0xb0\n...\nCall Trace:\n \u003cTASK\u003e\n ? __warn+0x7c/0x110\n ? debug_print_object+0x7d/0xb0\n ? report_bug+0xf1/0x1d0\n ? prb_read_valid+0x17/0x20\n ? handle_bug+0x3f/0x70\n ? exc_invalid_op+0x13/0x60\n ? asm_exc_invalid_op+0x16/0x20\n ? debug_print_object+0x7d/0xb0\n ? debug_print_object+0x7d/0xb0\n ? __pfx_timerlat_irq+0x10/0x10\n __debug_object_init+0x110/0x150\n hrtimer_init+0x1d/0x60\n timerlat_main+0xab/0x2d0\n ? __pfx_timerlat_main+0x10/0x10\n kthread+0xb7/0xe0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x2d/0x40\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u003c/TASK\u003e\n```\n\nAfter tracing the scheduling event, it was discovered that the migration\nof the \"timerlat/1\" thread was performed during thread creation. Further\nanalysis confirmed that it is because the CPU online processing for\nosnoise is implemented through workers, which is asynchronous with the\noffline processing. When the worker was scheduled to create a thread, the\nCPU may has already been removed from the cpu_online_mask during the offline\nprocess, resulting in the inability to select the right CPU:\n\nT1                       | T2\n[CPUHP_ONLINE]           | cpu_device_down()\nosnoise_hotplug_workfn() |\n                         |     cpus_write_lock()\n                         |     takedown_cpu(1)\n                         |     cpus_write_unlock()\n[CPUHP_OFFLINE]          |\n    cpus_read_lock()     |\n    start_kthread(1)     |\n    cpus_read_unlock()   |\n\nTo fix this, skip online processing if the CPU is already offline.",
  "id": "GHSA-8r4r-8c3p-6r95",
  "modified": "2025-11-04T00:31:40Z",
  "published": "2024-10-21T18:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49866"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/322920b53dc11f9c2b33397eb3ae5bc6a175b60d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/829e0c9f0855f26b3ae830d17b24aec103f7e915"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a0d9c0cd5856191e095cf43a2e141b73945b7716"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a6e9849063a6c8f4cb2f652a437e44e3ed24356c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ce25f33ba89d6eefef64157655d318444580fa14"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f72b451dc75578f644a3019c1489e9ae2c14e6c4"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8R5M-9XX4-3V9J

Vulnerability from github – Published: 2025-05-01 15:31 – Updated: 2025-05-07 15:31
VLAI
Details

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

netfilter: nf_tables: netlink notifier might race to release objects

commit release path is invoked via call_rcu and it runs lockless to release the objects after rcu grace period. The netlink notifier handler might win race to remove objects that the transaction context is still referencing from the commit release path.

Call rcu_barrier() to ensure pending rcu callbacks run to completion if the list of transactions to be destroyed is not empty.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-49920"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-01T15:16:17Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: netlink notifier might race to release objects\n\ncommit release path is invoked via call_rcu and it runs lockless to\nrelease the objects after rcu grace period. The netlink notifier handler\nmight win race to remove objects that the transaction context is still\nreferencing from the commit release path.\n\nCall rcu_barrier() to ensure pending rcu callbacks run to completion\nif the list of transactions to be destroyed is not empty.",
  "id": "GHSA-8r5m-9xx4-3v9j",
  "modified": "2025-05-07T15:31:27Z",
  "published": "2025-05-01T15:31:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49920"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1ffe7100411a8b9015115ce124cd6c9c9da6f8e3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d4bc8271db21ea9f1c86a1ca4d64999f184d4aae"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e40b7c44d19e327ad8b49a491ef1fa8dcc4566e0"
    }
  ],
  "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"
    }
  ]
}

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.