CWE-362
Allowed-with-ReviewConcurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Abstraction: Class · Status: Draft
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
3230 vulnerabilities reference this CWE, most recent first.
GHSA-4W59-2W8Q-GHQ2
Vulnerability from github – Published: 2023-08-11 03:30 – Updated: 2024-04-04 06:50Race condition in firmware for some Intel(R) Ethernet Controllers and Adapters E810 Series before version 1.7.2.4 may allow an authenticated user to potentially enable denial of service via local access.
{
"affected": [],
"aliases": [
"CVE-2023-22276"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-421"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-11T03:15:16Z",
"severity": "MODERATE"
},
"details": "Race condition in firmware for some Intel(R) Ethernet Controllers and Adapters E810 Series before version 1.7.2.4 may allow an authenticated user to potentially enable denial of service via local access.",
"id": "GHSA-4w59-2w8q-ghq2",
"modified": "2024-04-04T06:50:31Z",
"published": "2023-08-11T03:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22276"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20230915-0007"
},
{
"type": "WEB",
"url": "http://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00835.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4W5G-R898-RJ85
Vulnerability from github – Published: 2025-07-25 15:30 – Updated: 2025-12-16 18:31In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix a race between renames and directory logging
We have a race between a rename and directory inode logging that if it happens and we crash/power fail before the rename completes, the next time the filesystem is mounted, the log replay code will end up deleting the file that was being renamed.
This is best explained following a step by step analysis of an interleaving of steps that lead into this situation.
Consider the initial conditions:
1) We are at transaction N;
2) We have directories A and B created in a past transaction (< N);
3) We have inode X corresponding to a file that has 2 hardlinks, one in directory A and the other in directory B, so we'll name them as "A/foo_link1" and "B/foo_link2". Both hard links were persisted in a past transaction (< N);
4) We have inode Y corresponding to a file that as a single hard link and is located in directory A, we'll name it as "A/bar". This file was also persisted in a past transaction (< N).
The steps leading to a file loss are the following and for all of them we are under transaction N:
1) Link "A/foo_link1" is removed, so inode's X last_unlink_trans field is updated to N, through btrfs_unlink() -> btrfs_record_unlink_dir();
2) Task A starts a rename for inode Y, with the goal of renaming from "A/bar" to "A/baz", so we enter btrfs_rename();
3) Task A inserts the new BTRFS_INODE_REF_KEY for inode Y by calling btrfs_insert_inode_ref();
4) Because the rename happens in the same directory, we don't set the last_unlink_trans field of directoty A's inode to the current transaction id, that is, we don't cal btrfs_record_unlink_dir();
5) Task A then removes the entries from directory A (BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items) when calling __btrfs_unlink_inode() (actually the dir index item is added as a delayed item, but the effect is the same);
6) Now before task A adds the new entry "A/baz" to directory A by calling btrfs_add_link(), another task, task B is logging inode X;
7) Task B starts a fsync of inode X and after logging inode X, at btrfs_log_inode_parent() it calls btrfs_log_all_parents(), since inode X has a last_unlink_trans value of N, set at in step 1;
8) At btrfs_log_all_parents() we search for all parent directories of inode X using the commit root, so we find directories A and B and log them. Bu when logging direct A, we don't have a dir index item for inode Y anymore, neither the old name "A/bar" nor for the new name "A/baz" since the rename has deleted the old name but has not yet inserted the new name - task A hasn't called yet btrfs_add_link() to do that.
Note that logging directory A doesn't fallback to a transaction
commit because its last_unlink_trans has a lower value than the
current transaction's id (see step 4);
9) Task B finishes logging directories A and B and gets back to btrfs_sync_file() where it calls btrfs_sync_log() to persist the log tree;
10) Task B successfully persisted the log tree, btrfs_sync_log() completed with success, and a power failure happened.
We have a log tree without any directory entry for inode Y, so the
log replay code deletes the entry for inode Y, name "A/bar", from the
subvolume tree since it doesn't exist in the log tree and the log
tree is authorative for its index (we logged a BTRFS_DIR_LOG_INDEX_KEY
item that covers the index range for the dentry that corresponds to
"A/bar").
Since there's no other hard link for inode Y and the log replay code
deletes the name "A/bar", the file is lost.
The issue wouldn't happen if task B synced the log only after task A called btrfs_log_new_name(), which would update the log with the new name for inode Y ("A/bar").
Fix this by pinning the log root during renames before removing the old directory entry, and unpinning af ---truncated---
{
"affected": [],
"aliases": [
"CVE-2025-38365"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-25T13:15:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix a race between renames and directory logging\n\nWe have a race between a rename and directory inode logging that if it\nhappens and we crash/power fail before the rename completes, the next time\nthe filesystem is mounted, the log replay code will end up deleting the\nfile that was being renamed.\n\nThis is best explained following a step by step analysis of an interleaving\nof steps that lead into this situation.\n\nConsider the initial conditions:\n\n1) We are at transaction N;\n\n2) We have directories A and B created in a past transaction (\u003c N);\n\n3) We have inode X corresponding to a file that has 2 hardlinks, one in\n directory A and the other in directory B, so we\u0027ll name them as\n \"A/foo_link1\" and \"B/foo_link2\". Both hard links were persisted in a\n past transaction (\u003c N);\n\n4) We have inode Y corresponding to a file that as a single hard link and\n is located in directory A, we\u0027ll name it as \"A/bar\". This file was also\n persisted in a past transaction (\u003c N).\n\nThe steps leading to a file loss are the following and for all of them we\nare under transaction N:\n\n 1) Link \"A/foo_link1\" is removed, so inode\u0027s X last_unlink_trans field\n is updated to N, through btrfs_unlink() -\u003e btrfs_record_unlink_dir();\n\n 2) Task A starts a rename for inode Y, with the goal of renaming from\n \"A/bar\" to \"A/baz\", so we enter btrfs_rename();\n\n 3) Task A inserts the new BTRFS_INODE_REF_KEY for inode Y by calling\n btrfs_insert_inode_ref();\n\n 4) Because the rename happens in the same directory, we don\u0027t set the\n last_unlink_trans field of directoty A\u0027s inode to the current\n transaction id, that is, we don\u0027t cal btrfs_record_unlink_dir();\n\n 5) Task A then removes the entries from directory A (BTRFS_DIR_ITEM_KEY\n and BTRFS_DIR_INDEX_KEY items) when calling __btrfs_unlink_inode()\n (actually the dir index item is added as a delayed item, but the\n effect is the same);\n\n 6) Now before task A adds the new entry \"A/baz\" to directory A by\n calling btrfs_add_link(), another task, task B is logging inode X;\n\n 7) Task B starts a fsync of inode X and after logging inode X, at\n btrfs_log_inode_parent() it calls btrfs_log_all_parents(), since\n inode X has a last_unlink_trans value of N, set at in step 1;\n\n 8) At btrfs_log_all_parents() we search for all parent directories of\n inode X using the commit root, so we find directories A and B and log\n them. Bu when logging direct A, we don\u0027t have a dir index item for\n inode Y anymore, neither the old name \"A/bar\" nor for the new name\n \"A/baz\" since the rename has deleted the old name but has not yet\n inserted the new name - task A hasn\u0027t called yet btrfs_add_link() to\n do that.\n\n Note that logging directory A doesn\u0027t fallback to a transaction\n commit because its last_unlink_trans has a lower value than the\n current transaction\u0027s id (see step 4);\n\n 9) Task B finishes logging directories A and B and gets back to\n btrfs_sync_file() where it calls btrfs_sync_log() to persist the log\n tree;\n\n10) Task B successfully persisted the log tree, btrfs_sync_log() completed\n with success, and a power failure happened.\n\n We have a log tree without any directory entry for inode Y, so the\n log replay code deletes the entry for inode Y, name \"A/bar\", from the\n subvolume tree since it doesn\u0027t exist in the log tree and the log\n tree is authorative for its index (we logged a BTRFS_DIR_LOG_INDEX_KEY\n item that covers the index range for the dentry that corresponds to\n \"A/bar\").\n\n Since there\u0027s no other hard link for inode Y and the log replay code\n deletes the name \"A/bar\", the file is lost.\n\nThe issue wouldn\u0027t happen if task B synced the log only after task A\ncalled btrfs_log_new_name(), which would update the log with the new name\nfor inode Y (\"A/bar\").\n\nFix this by pinning the log root during renames before removing the old\ndirectory entry, and unpinning af\n---truncated---",
"id": "GHSA-4w5g-r898-rj85",
"modified": "2025-12-16T18:31:30Z",
"published": "2025-07-25T15:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38365"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2088895d5903082bb9021770b919e733c57edbc1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3ca864de852bc91007b32d2a0d48993724f4abad"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/51bd363c7010d033d3334daf457c824484bf9bf0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8c6874646c21bd820cf475e2874e62c133954023"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aeeae8feeaae4445a86f9815273e81f902dc1f5b"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4WCM-FJH2-X4HG
Vulnerability from github – Published: 2026-04-14 18:30 – Updated: 2026-04-14 18:30Concurrent execution using shared resource with improper synchronization ('race condition') in Windows User Interface Core allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-32163"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-14T18:17:18Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows User Interface Core allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-4wcm-fjh2-x4hg",
"modified": "2026-04-14T18:30:41Z",
"published": "2026-04-14T18:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32163"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-32163"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4WP4-8C2W-49HV
Vulnerability from github – Published: 2026-02-10 06:30 – Updated: 2026-02-10 06:30A race condition vulnerability exists in the SAP Commerce cloud. Because of this when an attacker adds products to a cart, it may result in a cart entry being created with erroneous product value which could be checked out. This leads to high impact on data integrity, with no impact on data confidentiality or availability of the application.
{
"affected": [],
"aliases": [
"CVE-2026-23684"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-366"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-10T04:16:02Z",
"severity": "MODERATE"
},
"details": "A race condition vulnerability exists in the SAP Commerce cloud. Because of this when an attacker adds products to a cart, it may result in a cart entry being created with erroneous product value which could be checked out. This leads to high impact on data integrity, with no impact on data confidentiality or availability of the application.",
"id": "GHSA-4wp4-8c2w-49hv",
"modified": "2026-02-10T06:30:38Z",
"published": "2026-02-10T06:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23684"
},
{
"type": "WEB",
"url": "https://me.sap.com/notes/3689543"
},
{
"type": "WEB",
"url": "https://url.sap/sapsecuritypatchday"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4WPH-PWC5-WP7G
Vulnerability from github – Published: 2022-12-13 21:30 – Updated: 2022-12-13 21:30Windows Error Reporting Elevation of Privilege Vulnerability.
{
"affected": [],
"aliases": [
"CVE-2022-44669"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-13T19:15:00Z",
"severity": "HIGH"
},
"details": "Windows Error Reporting Elevation of Privilege Vulnerability.",
"id": "GHSA-4wph-pwc5-wp7g",
"modified": "2022-12-13T21:30:26Z",
"published": "2022-12-13T21:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-44669"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-44669"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-44669"
}
],
"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-4WQW-J3VX-3HWJ
Vulnerability from github – Published: 2022-05-24 19:06 – Updated: 2022-05-24 19:06There is a multiple threads race condition vulnerability in Huawei product. A race condition exists for concurrent I/O read by multiple threads. An attacker with the root permission can exploit this vulnerability by performing some operations. Successful exploitation of this vulnerability may cause the system to crash. Affected product versions include: ManageOne 6.5.1.SPC200, 8.0.0,8.0.0-LCND81, 8.0.0.SPC100, 8.0.1,8.0.RC2, 8.0.RC3, 8.0.RC3.SPC100;SMC2.0 V600R019C10SPC700,V600R019C10SPC702, V600R019C10SPC703,V600R019C10SPC800, V600R019C10SPC900, V600R019C10SPC910, V600R019C10SPC920, V600R019C10SPC921, V600R019C10SPC922, V600R019C10SPC930, V600R019C10SPC931
{
"affected": [],
"aliases": [
"CVE-2021-22340"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-29T19:15:00Z",
"severity": "MODERATE"
},
"details": "There is a multiple threads race condition vulnerability in Huawei product. A race condition exists for concurrent I/O read by multiple threads. An attacker with the root permission can exploit this vulnerability by performing some operations. Successful exploitation of this vulnerability may cause the system to crash. Affected product versions include: ManageOne 6.5.1.SPC200, 8.0.0,8.0.0-LCND81, 8.0.0.SPC100, 8.0.1,8.0.RC2, 8.0.RC3, 8.0.RC3.SPC100;SMC2.0 V600R019C10SPC700,V600R019C10SPC702, V600R019C10SPC703,V600R019C10SPC800, V600R019C10SPC900, V600R019C10SPC910, V600R019C10SPC920, V600R019C10SPC921, V600R019C10SPC922, V600R019C10SPC930, V600R019C10SPC931",
"id": "GHSA-4wqw-j3vx-3hwj",
"modified": "2022-05-24T19:06:29Z",
"published": "2022-05-24T19:06:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22340"
},
{
"type": "WEB",
"url": "https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20210428-01-racecondition-en"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-4X5X-V34X-MQXM
Vulnerability from github – Published: 2025-05-24 03:30 – Updated: 2025-05-24 03:30In the anode crate 0.1.0 for Rust, data races can occur in unlock in SpinLock.
{
"affected": [],
"aliases": [
"CVE-2025-48753"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-24T03:15:23Z",
"severity": "LOW"
},
"details": "In the anode crate 0.1.0 for Rust, data races can occur in unlock in SpinLock.",
"id": "GHSA-4x5x-v34x-mqxm",
"modified": "2025-05-24T03:30:19Z",
"published": "2025-05-24T03:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48753"
},
{
"type": "WEB",
"url": "https://github.com/obsidiandynamics/anode/issues/1"
},
{
"type": "WEB",
"url": "https://crates.io/crates/anode"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-4X89-4XJG-WJV4
Vulnerability from github – Published: 2022-05-14 03:54 – Updated: 2025-04-12 13:07Race condition in the snd_pcm_period_elapsed function in sound/core/pcm_lib.c in the ALSA subsystem in the Linux kernel before 4.7 allows local users to cause a denial of service (use-after-free) or possibly have unspecified other impact via a crafted SNDRV_PCM_TRIGGER_START command.
{
"affected": [],
"aliases": [
"CVE-2016-9794"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-12-28T07:59:00Z",
"severity": "HIGH"
},
"details": "Race condition in the snd_pcm_period_elapsed function in sound/core/pcm_lib.c in the ALSA subsystem in the Linux kernel before 4.7 allows local users to cause a denial of service (use-after-free) or possibly have unspecified other impact via a crafted SNDRV_PCM_TRIGGER_START command.",
"id": "GHSA-4x89-4xjg-wjv4",
"modified": "2025-04-12T13:07:48Z",
"published": "2022-05-14T03:54:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-9794"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/3aa02cb664c5fb1042958c8d1aa8c35055a2ebc4"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1401494"
},
{
"type": "WEB",
"url": "https://patchwork.kernel.org/patch/8752621"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2017-05-01"
},
{
"type": "WEB",
"url": "http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3aa02cb664c5fb1042958c8d1aa8c35055a2ebc4"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-12/msg00057.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-12/msg00062.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-12/msg00072.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-12/msg00075.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-12/msg00081.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-12/msg00088.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-12/msg00091.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2574.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/12/03/2"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/94654"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4X9F-4X9P-28W2
Vulnerability from github – Published: 2025-07-28 12:30 – Updated: 2025-11-19 18:31In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix race between cache write completion and ALL_QUEUED being set
When netfslib is issuing subrequests, the subrequests start processing immediately and may complete before we reach the end of the issuing function. At the end of the issuing function we set NETFS_RREQ_ALL_QUEUED to indicate to the collector that we aren't going to issue any more subreqs and that it can do the final notifications and cleanup.
Now, this isn't a problem if the request is synchronous (NETFS_RREQ_OFFLOAD_COLLECTION is unset) as the result collection will be done in-thread and we're guaranteed an opportunity to run the collector.
However, if the request is asynchronous, collection is primarily triggered by the termination of subrequests queuing it on a workqueue. Now, a race can occur here if the app thread sets ALL_QUEUED after the last subrequest terminates.
This can happen most easily with the copy2cache code (as used by Ceph) where, in the collection routine of a read request, an asynchronous write request is spawned to copy data to the cache. Folios are added to the write request as they're unlocked, but there may be a delay before ALL_QUEUED is set as the write subrequests may complete before we get there.
If all the write subreqs have finished by the ALL_QUEUED point, no further events happen and the collection never happens, leaving the request hanging.
Fix this by queuing the collector after setting ALL_QUEUED. This is a bit heavy-handed and it may be sufficient to do it only if there are no extant subreqs.
Also add a tracepoint to cross-reference both requests in a copy-to-request operation and add a trace to the netfs_rreq tracepoint to indicate the setting of ALL_QUEUED.
{
"affected": [],
"aliases": [
"CVE-2025-38492"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-28T12:15:31Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix race between cache write completion and ALL_QUEUED being set\n\nWhen netfslib is issuing subrequests, the subrequests start processing\nimmediately and may complete before we reach the end of the issuing\nfunction. At the end of the issuing function we set NETFS_RREQ_ALL_QUEUED\nto indicate to the collector that we aren\u0027t going to issue any more subreqs\nand that it can do the final notifications and cleanup.\n\nNow, this isn\u0027t a problem if the request is synchronous\n(NETFS_RREQ_OFFLOAD_COLLECTION is unset) as the result collection will be\ndone in-thread and we\u0027re guaranteed an opportunity to run the collector.\n\nHowever, if the request is asynchronous, collection is primarily triggered\nby the termination of subrequests queuing it on a workqueue. Now, a race\ncan occur here if the app thread sets ALL_QUEUED after the last subrequest\nterminates.\n\nThis can happen most easily with the copy2cache code (as used by Ceph)\nwhere, in the collection routine of a read request, an asynchronous write\nrequest is spawned to copy data to the cache. Folios are added to the\nwrite request as they\u0027re unlocked, but there may be a delay before\nALL_QUEUED is set as the write subrequests may complete before we get\nthere.\n\nIf all the write subreqs have finished by the ALL_QUEUED point, no further\nevents happen and the collection never happens, leaving the request\nhanging.\n\nFix this by queuing the collector after setting ALL_QUEUED. This is a bit\nheavy-handed and it may be sufficient to do it only if there are no extant\nsubreqs.\n\nAlso add a tracepoint to cross-reference both requests in a copy-to-request\noperation and add a trace to the netfs_rreq tracepoint to indicate the\nsetting of ALL_QUEUED.",
"id": "GHSA-4x9f-4x9p-28w2",
"modified": "2025-11-19T18:31:17Z",
"published": "2025-07-28T12:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38492"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/110188a13c4853bd4c342e600ced4dfd26c3feb5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/89635eae076cd8eaa5cb752f66538c9dc6c9fdc3"
}
],
"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-4XC2-JWRR-PXH9
Vulnerability from github – Published: 2025-10-01 12:30 – Updated: 2026-01-16 21:30In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix disconnect vs accept race
Despite commit 0ad529d9fd2b ("mptcp: fix possible divide by zero in recvmsg()"), the mptcp protocol is still prone to a race between disconnect() (or shutdown) and accept.
The root cause is that the mentioned commit checks the msk-level flag, but mptcp_stream_accept() does acquire the msk-level lock, as it can rely directly on the first subflow lock.
As reported by Christoph than can lead to a race where an msk socket is accepted after that mptcp_subflow_queue_clean() releases the listener socket lock and just before it takes destructive actions leading to the following splat:
BUG: kernel NULL pointer dereference, address: 0000000000000012 PGD 5a4ca067 P4D 5a4ca067 PUD 37d4c067 PMD 0 Oops: 0000 [#1] PREEMPT SMP CPU: 2 PID: 10955 Comm: syz-executor.5 Not tainted 6.5.0-rc1-gdc7b257ee5dd #37 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 RIP: 0010:mptcp_stream_accept+0x1ee/0x2f0 include/net/inet_sock.h:330 Code: 0a 09 00 48 8b 1b 4c 39 e3 74 07 e8 bc 7c 7f fe eb a1 e8 b5 7c 7f fe 4c 8b 6c 24 08 eb 05 e8 a9 7c 7f fe 49 8b 85 d8 09 00 00 <0f> b6 40 12 88 44 24 07 0f b6 6c 24 07 bf 07 00 00 00 89 ee e8 89 RSP: 0018:ffffc90000d07dc0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff888037e8d020 RCX: ffff88803b093300 RDX: 0000000000000000 RSI: ffffffff833822c5 RDI: ffffffff8333896a RBP: 0000607f82031520 R08: ffff88803b093300 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000003e83 R12: ffff888037e8d020 R13: ffff888037e8c680 R14: ffff888009af7900 R15: ffff888009af6880 FS: 00007fc26d708640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 0000000066bc5001 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: do_accept+0x1ae/0x260 net/socket.c:1872 __sys_accept4+0x9b/0x110 net/socket.c:1913 __do_sys_accept4 net/socket.c:1954 [inline] __se_sys_accept4 net/socket.c:1951 [inline] __x64_sys_accept4+0x20/0x30 net/socket.c:1951 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x47/0xa0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Address the issue by temporary removing the pending request socket from the accept queue, so that racing accept() can't touch them.
After depleting the msk - the ssk still exists, as plain TCP sockets, re-insert them into the accept queue, so that later inet_csk_listen_stop() will complete the tcp socket disposal.
{
"affected": [],
"aliases": [
"CVE-2023-53490"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-01T12:15:52Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix disconnect vs accept race\n\nDespite commit 0ad529d9fd2b (\"mptcp: fix possible divide by zero in\nrecvmsg()\"), the mptcp protocol is still prone to a race between\ndisconnect() (or shutdown) and accept.\n\nThe root cause is that the mentioned commit checks the msk-level\nflag, but mptcp_stream_accept() does acquire the msk-level lock,\nas it can rely directly on the first subflow lock.\n\nAs reported by Christoph than can lead to a race where an msk\nsocket is accepted after that mptcp_subflow_queue_clean() releases\nthe listener socket lock and just before it takes destructive\nactions leading to the following splat:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000012\nPGD 5a4ca067 P4D 5a4ca067 PUD 37d4c067 PMD 0\nOops: 0000 [#1] PREEMPT SMP\nCPU: 2 PID: 10955 Comm: syz-executor.5 Not tainted 6.5.0-rc1-gdc7b257ee5dd #37\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014\nRIP: 0010:mptcp_stream_accept+0x1ee/0x2f0 include/net/inet_sock.h:330\nCode: 0a 09 00 48 8b 1b 4c 39 e3 74 07 e8 bc 7c 7f fe eb a1 e8 b5 7c 7f fe 4c 8b 6c 24 08 eb 05 e8 a9 7c 7f fe 49 8b 85 d8 09 00 00 \u003c0f\u003e b6 40 12 88 44 24 07 0f b6 6c 24 07 bf 07 00 00 00 89 ee e8 89\nRSP: 0018:ffffc90000d07dc0 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: ffff888037e8d020 RCX: ffff88803b093300\nRDX: 0000000000000000 RSI: ffffffff833822c5 RDI: ffffffff8333896a\nRBP: 0000607f82031520 R08: ffff88803b093300 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000003e83 R12: ffff888037e8d020\nR13: ffff888037e8c680 R14: ffff888009af7900 R15: ffff888009af6880\nFS: 00007fc26d708640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000012 CR3: 0000000066bc5001 CR4: 0000000000370ee0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u003cTASK\u003e\n do_accept+0x1ae/0x260 net/socket.c:1872\n __sys_accept4+0x9b/0x110 net/socket.c:1913\n __do_sys_accept4 net/socket.c:1954 [inline]\n __se_sys_accept4 net/socket.c:1951 [inline]\n __x64_sys_accept4+0x20/0x30 net/socket.c:1951\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x47/0xa0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n\nAddress the issue by temporary removing the pending request socket\nfrom the accept queue, so that racing accept() can\u0027t touch them.\n\nAfter depleting the msk - the ssk still exists, as plain TCP sockets,\nre-insert them into the accept queue, so that later inet_csk_listen_stop()\nwill complete the tcp socket disposal.",
"id": "GHSA-4xc2-jwrr-pxh9",
"modified": "2026-01-16T21:30:30Z",
"published": "2025-10-01T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53490"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/511b90e39250135a7f900f1c3afbce25543018a2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b2b4c84eb7149f34c0f25f17042d095ba5357d68"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ded9f5551ce5cafa3c41c794428c27a0d0a00542"
}
],
"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
In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.
Mitigation
Use thread-safe capabilities such as the data access abstraction in Spring.
Mitigation
- Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring.
- Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).
Mitigation
When using multithreading and operating on shared variables, only use thread-safe functions.
Mitigation
Use atomic operations on shared variables. Be wary of innocent-looking constructs such as "x++". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read, followed by a computation, followed by a write.
Mitigation
Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.
Mitigation
Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.
Mitigation
Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite loop.
Mitigation
Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or reordering. This does not necessarily solve the synchronization problem, but it can help.
Mitigation MIT-17
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
CAPEC-26: Leveraging Race Conditions
The adversary targets a race condition occurring when multiple processes access and manipulate the same resource concurrently, and the outcome of the execution depends on the particular order in which the access takes place. The adversary can leverage a race condition by "running the race", modifying the resource and modifying the normal execution flow. For instance, a race condition can occur while accessing a file: the adversary can trick the system by replacing the original file with their version and cause the system to read the malicious file.
CAPEC-29: Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions
This attack targets a race condition occurring between the time of check (state) for a resource and the time of use of a resource. A typical example is file access. The adversary can leverage a file access race condition by "running the race", meaning that they would modify the resource between the first time the target program accesses the file and the time the target program uses the file. During that period of time, the adversary could replace or modify the file, causing the application to behave unexpectedly.