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.
3263 vulnerabilities reference this CWE, most recent first.
GHSA-5H86-F54V-652H
Vulnerability from github – Published: 2022-05-17 00:19 – Updated: 2022-05-17 00:19In android for MSM, Firefox OS for MSM, QRD Android, with all Android releases from CAF using the Linux kernel, due to a race condition in the function audio_effects_shared_ioctl(), memory corruption can occur.
{
"affected": [],
"aliases": [
"CVE-2017-11025"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-11-16T22:29:00Z",
"severity": "HIGH"
},
"details": "In android for MSM, Firefox OS for MSM, QRD Android, with all Android releases from CAF using the Linux kernel, due to a race condition in the function audio_effects_shared_ioctl(), memory corruption can occur.",
"id": "GHSA-5h86-f54v-652h",
"modified": "2022-05-17T00:19:35Z",
"published": "2022-05-17T00:19:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-11025"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2017-11-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5HF6-7GXX-55WG
Vulnerability from github – Published: 2022-05-02 04:01 – Updated: 2022-05-02 04:01Absolute Computrace Agent, as distributed on certain Dell Inspiron systems through 2009, has a race condition with the Dell Client Configuration Utility (DCCU), which allows privileged local users to change Computrace Agent's activation/deactivation status to the factory default via a crafted TaskResult.xml file.
{
"affected": [],
"aliases": [
"CVE-2009-5152"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-05-11T19:29:00Z",
"severity": "MODERATE"
},
"details": "Absolute Computrace Agent, as distributed on certain Dell Inspiron systems through 2009, has a race condition with the Dell Client Configuration Utility (DCCU), which allows privileged local users to change Computrace Agent\u0027s activation/deactivation status to the factory default via a crafted TaskResult.xml file.",
"id": "GHSA-5hf6-7gxx-55wg",
"modified": "2022-05-02T04:01:42Z",
"published": "2022-05-02T04:01:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-5152"
},
{
"type": "WEB",
"url": "https://www.coresecurity.com/system/files/publications/2016/05/Paper-Deactivate-the-Rootkit-AOrtega-ASacco.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5HGG-XQ5W-5M82
Vulnerability from github – Published: 2022-04-29 03:01 – Updated: 2025-04-03 04:06Opera offers an Open button to verify that a user wishes to execute a downloaded file, which allows user-assisted remote attackers to construct a race condition that tricks a user into clicking Open via a request for a different mouse or keyboard action very shortly before the Open dialog appears. NOTE: this is a different issue than CVE-2005-2407.
{
"affected": [],
"aliases": [
"CVE-2004-2659"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2004-12-31T05:00:00Z",
"severity": "MODERATE"
},
"details": "Opera offers an Open button to verify that a user wishes to execute a downloaded file, which allows user-assisted remote attackers to construct a race condition that tricks a user into clicking Open via a request for a different mouse or keyboard action very shortly before the Open dialog appears. NOTE: this is a different issue than CVE-2005-2407.",
"id": "GHSA-5hgg-xq5w-5m82",
"modified": "2025-04-03T04:06:20Z",
"published": "2022-04-29T03:01:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2004-2659"
},
{
"type": "WEB",
"url": "http://archives.neohapsis.com/archives/fulldisclosure/2004-07/0264.html"
},
{
"type": "WEB",
"url": "http://www.squarefree.com/2004/07/01/race-conditions-in-security-dialogs"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-5HJ2-HCR5-W3XF
Vulnerability from github – Published: 2022-05-24 16:55 – Updated: 2023-02-01 00:30In FreeBSD 12.0-STABLE before r351264, 12.0-RELEASE before 12.0-RELEASE-p10, 11.3-STABLE before r351265, 11.3-RELEASE before 11.3-RELEASE-p3, and 11.2-RELEASE before 11.2-RELEASE-p14, the kernel driver for /dev/midistat implements a read handler that is not thread-safe. A multi-threaded program can exploit races in the handler to copy out kernel memory outside the boundaries of midistat's data buffer.
{
"affected": [],
"aliases": [
"CVE-2019-5612"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-08-30T09:15:00Z",
"severity": "HIGH"
},
"details": "In FreeBSD 12.0-STABLE before r351264, 12.0-RELEASE before 12.0-RELEASE-p10, 11.3-STABLE before r351265, 11.3-RELEASE before 11.3-RELEASE-p3, and 11.2-RELEASE before 11.2-RELEASE-p14, the kernel driver for /dev/midistat implements a read handler that is not thread-safe. A multi-threaded program can exploit races in the handler to copy out kernel memory outside the boundaries of midistat\u0027s data buffer.",
"id": "GHSA-5hj2-hcr5-w3xf",
"modified": "2023-02-01T00:30:29Z",
"published": "2022-05-24T16:55:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-5612"
},
{
"type": "WEB",
"url": "https://security.FreeBSD.org/advisories/FreeBSD-SA-19:23.midi.asc"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20190910-0002"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5J6G-RHRC-X47F
Vulnerability from github – Published: 2022-05-17 03:11 – Updated: 2022-05-17 03:11Race condition in arch/x86/kvm/x86.c in the Linux kernel before 3.17.4 allows guest OS users to cause a denial of service (guest OS crash) via a crafted application that performs an MMIO transaction or a PIO transaction to trigger a guest userspace emulation error report, a similar issue to CVE-2010-5313.
{
"affected": [],
"aliases": [
"CVE-2014-7842"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2014-11-30T01:59:00Z",
"severity": "MODERATE"
},
"details": "Race condition in arch/x86/kvm/x86.c in the Linux kernel before 3.17.4 allows guest OS users to cause a denial of service (guest OS crash) via a crafted application that performs an MMIO transaction or a PIO transaction to trigger a guest userspace emulation error report, a similar issue to CVE-2010-5313.",
"id": "GHSA-5j6g-rhrc-x47f",
"modified": "2022-05-17T03:11:32Z",
"published": "2022-05-17T03:11:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-7842"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/a2b9e6c1a35afcc0973acb72e591c714e78885ff"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1163762"
},
{
"type": "WEB",
"url": "https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.17.4"
},
{
"type": "WEB",
"url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git%3Ba=commit%3Bh=a2b9e6c1a35afcc0973acb72e591c714e78885ff"
},
{
"type": "WEB",
"url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a2b9e6c1a35afcc0973acb72e591c714e78885ff"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2015-03/msg00010.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2015-03/msg00025.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2015-04/msg00000.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2015-04/msg00015.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-0855.html"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/62305"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/62326"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/62336"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2014/11/13/7"
},
{
"type": "WEB",
"url": "http://www.oracle.com/technetwork/topics/security/linuxbulletinapr2016-2952096.html"
},
{
"type": "WEB",
"url": "http://www.oracle.com/technetwork/topics/security/linuxbulletinjan2016-2867209.html"
},
{
"type": "WEB",
"url": "http://www.oracle.com/technetwork/topics/security/linuxbulletinoct2015-2719645.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/71078"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-5JWG-RGW9-77G5
Vulnerability from github – Published: 2022-05-14 03:38 – Updated: 2022-05-14 03:38In all Qualcomm products with Android releases from CAF using the Linux kernel, a race condition exists in a GPU Driver which can potentially lead to a Use After Free condition.
{
"affected": [],
"aliases": [
"CVE-2017-15829"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-02-23T23:29:00Z",
"severity": "HIGH"
},
"details": "In all Qualcomm products with Android releases from CAF using the Linux kernel, a race condition exists in a GPU Driver which can potentially lead to a Use After Free condition.",
"id": "GHSA-5jwg-rgw9-77g5",
"modified": "2022-05-14T03:38:54Z",
"published": "2022-05-14T03:38:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-15829"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2018-02-01"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/102974"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5M3G-GPVQ-34JP
Vulnerability from github – Published: 2025-01-19 12:31 – Updated: 2026-05-12 15:30In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_fs: Remove WARN_ON in functionfs_bind
This commit addresses an issue related to below kernel panic where panic_on_warn is enabled. It is caused by the unnecessary use of WARN_ON in functionsfs_bind, which easily leads to the following scenarios.
1.adb_write in adbd 2. UDC write via configfs ================= =====================
->usb_ffs_open_thread() ->UDC write ->open_functionfs() ->configfs_write_iter() ->adb_open() ->gadget_dev_desc_UDC_store() ->adb_write() ->usb_gadget_register_driver_owner ->driver_register() ->StartMonitor() ->bus_add_driver() ->adb_read() ->gadget_bind_driver() ->configfs_composite_bind() ->usb_add_function() ->open_functionfs() ->ffs_func_bind() ->adb_open() ->functionfs_bind() state !=FFS_ACTIVE>
The adb_open, adb_read, and adb_write operations are invoked from the daemon, but trying to bind the function is a process that is invoked by UDC write through configfs, which opens up the possibility of a race condition between the two paths. In this race scenario, the kernel panic occurs due to the WARN_ON from functionfs_bind when panic_on_warn is enabled. This commit fixes the kernel panic by removing the unnecessary WARN_ON.
Kernel panic - not syncing: kernel: panic_on_warn set ... [ 14.542395] Call trace: [ 14.542464] ffs_func_bind+0x1c8/0x14a8 [ 14.542468] usb_add_function+0xcc/0x1f0 [ 14.542473] configfs_composite_bind+0x468/0x588 [ 14.542478] gadget_bind_driver+0x108/0x27c [ 14.542483] really_probe+0x190/0x374 [ 14.542488] __driver_probe_device+0xa0/0x12c [ 14.542492] driver_probe_device+0x3c/0x220 [ 14.542498] __driver_attach+0x11c/0x1fc [ 14.542502] bus_for_each_dev+0x104/0x160 [ 14.542506] driver_attach+0x24/0x34 [ 14.542510] bus_add_driver+0x154/0x270 [ 14.542514] driver_register+0x68/0x104 [ 14.542518] usb_gadget_register_driver_owner+0x48/0xf4 [ 14.542523] gadget_dev_desc_UDC_store+0xf8/0x144 [ 14.542526] configfs_write_iter+0xf0/0x138
{
"affected": [],
"aliases": [
"CVE-2024-57913"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-19T12:15:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_fs: Remove WARN_ON in functionfs_bind\n\nThis commit addresses an issue related to below kernel panic where\npanic_on_warn is enabled. It is caused by the unnecessary use of WARN_ON\nin functionsfs_bind, which easily leads to the following scenarios.\n\n1.adb_write in adbd 2. UDC write via configfs\n =================\t =====================\n\n-\u003eusb_ffs_open_thread() -\u003eUDC write\n -\u003eopen_functionfs() -\u003econfigfs_write_iter()\n -\u003eadb_open() -\u003egadget_dev_desc_UDC_store()\n -\u003eadb_write() -\u003eusb_gadget_register_driver_owner\n -\u003edriver_register()\n-\u003eStartMonitor() -\u003ebus_add_driver()\n -\u003eadb_read() -\u003egadget_bind_driver()\n\u003ctimes-out without BIND event\u003e -\u003econfigfs_composite_bind()\n -\u003eusb_add_function()\n-\u003eopen_functionfs() -\u003effs_func_bind()\n -\u003eadb_open() -\u003efunctionfs_bind()\n \u003cffs-\u003estate !=FFS_ACTIVE\u003e\n\nThe adb_open, adb_read, and adb_write operations are invoked from the\ndaemon, but trying to bind the function is a process that is invoked by\nUDC write through configfs, which opens up the possibility of a race\ncondition between the two paths. In this race scenario, the kernel panic\noccurs due to the WARN_ON from functionfs_bind when panic_on_warn is\nenabled. This commit fixes the kernel panic by removing the unnecessary\nWARN_ON.\n\nKernel panic - not syncing: kernel: panic_on_warn set ...\n[ 14.542395] Call trace:\n[ 14.542464] ffs_func_bind+0x1c8/0x14a8\n[ 14.542468] usb_add_function+0xcc/0x1f0\n[ 14.542473] configfs_composite_bind+0x468/0x588\n[ 14.542478] gadget_bind_driver+0x108/0x27c\n[ 14.542483] really_probe+0x190/0x374\n[ 14.542488] __driver_probe_device+0xa0/0x12c\n[ 14.542492] driver_probe_device+0x3c/0x220\n[ 14.542498] __driver_attach+0x11c/0x1fc\n[ 14.542502] bus_for_each_dev+0x104/0x160\n[ 14.542506] driver_attach+0x24/0x34\n[ 14.542510] bus_add_driver+0x154/0x270\n[ 14.542514] driver_register+0x68/0x104\n[ 14.542518] usb_gadget_register_driver_owner+0x48/0xf4\n[ 14.542523] gadget_dev_desc_UDC_store+0xf8/0x144\n[ 14.542526] configfs_write_iter+0xf0/0x138",
"id": "GHSA-5m3g-gpvq-34jp",
"modified": "2026-05-12T15:30:44Z",
"published": "2025-01-19T12:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57913"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/19fc1c83454ca9d5699e39633ec79ce26355251c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e4d32cc145955d5c56c5498a3ff057e4aafa9d1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/82f60f3600aecd9ffcd0fbc4e193694511c85b47"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a8b6a18b9b66cc4c016d63132b59ce5383f7cdd2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bfe60030fcd976e3546e1f73d6d0eb3fea26442e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dfc51e48bca475bbee984e90f33fdc537ce09699"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ea6a1498742430eb2effce0d1439ff29ef37dd7d"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.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-5M5F-J2WX-5R78
Vulnerability from github – Published: 2025-03-18 21:31 – Updated: 2025-03-18 21:31In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: fix race between xmit and reset
There is a race between reset and the transmit paths that can lead to ibmvnic_xmit() accessing an scrq after it has been freed in the reset path. It can result in a crash like:
Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x00000000
Faulting instruction address: 0xc0080000016189f8
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP [c0080000016189f8] ibmvnic_xmit+0x60/0xb60 [ibmvnic]
LR [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280
Call Trace:
[c008000001618f08] ibmvnic_xmit+0x570/0xb60 [ibmvnic] (unreliable)
[c000000000c0046c] dev_hard_start_xmit+0x11c/0x280
[c000000000c9cfcc] sch_direct_xmit+0xec/0x330
[c000000000bfe640] __dev_xmit_skb+0x3a0/0x9d0
[c000000000c00ad4] __dev_queue_xmit+0x394/0x730
[c008000002db813c] __bond_start_xmit+0x254/0x450 [bonding]
[c008000002db8378] bond_start_xmit+0x40/0xc0 [bonding]
[c000000000c0046c] dev_hard_start_xmit+0x11c/0x280
[c000000000c00ca4] __dev_queue_xmit+0x564/0x730
[c000000000cf97e0] neigh_hh_output+0xd0/0x180
[c000000000cfa69c] ip_finish_output2+0x31c/0x5c0
[c000000000cfd244] __ip_queue_xmit+0x194/0x4f0
[c000000000d2a3c4] __tcp_transmit_skb+0x434/0x9b0
[c000000000d2d1e0] __tcp_retransmit_skb+0x1d0/0x6a0
[c000000000d2d984] tcp_retransmit_skb+0x34/0x130
[c000000000d310e8] tcp_retransmit_timer+0x388/0x6d0
[c000000000d315ec] tcp_write_timer_handler+0x1bc/0x330
[c000000000d317bc] tcp_write_timer+0x5c/0x200
[c000000000243270] call_timer_fn+0x50/0x1c0
[c000000000243704] __run_timers.part.0+0x324/0x460
[c000000000243894] run_timer_softirq+0x54/0xa0
[c000000000ea713c] __do_softirq+0x15c/0x3e0
[c000000000166258] __irq_exit_rcu+0x158/0x190
[c000000000166420] irq_exit+0x20/0x40
[c00000000002853c] timer_interrupt+0x14c/0x2b0
[c000000000009a00] decrementer_common_virt+0x210/0x220
--- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2c
The immediate cause of the crash is the access of tx_scrq in the following snippet during a reset, where the tx_scrq can be either NULL or an address that will soon be invalid:
ibmvnic_xmit()
{
...
tx_scrq = adapter->tx_scrq[queue_num];
txq = netdev_get_tx_queue(netdev, queue_num);
ind_bufp = &tx_scrq->ind_buf;
if (test_bit(0, &adapter->resetting)) {
...
}
But beyond that, the call to ibmvnic_xmit() itself is not safe during a reset and the reset path attempts to avoid this by stopping the queue in ibmvnic_cleanup(). However just after the queue was stopped, an in-flight ibmvnic_complete_tx() could have restarted the queue even as the reset is progressing.
Since the queue was restarted we could get a call to ibmvnic_xmit() which can then access the bad tx_scrq (or other fields).
We cannot however simply have ibmvnic_complete_tx() check the ->resetting bit and skip starting the queue. This can race at the "back-end" of a good reset which just restarted the queue but has not cleared the ->resetting bit yet. If we skip restarting the queue due to ->resetting being true, the queue would remain stopped indefinitely potentially leading to transmit timeouts.
IOW ->resetting is too broad for this purpose. Instead use a new flag that indicates whether or not the queues are active. Only the open/ reset paths control when the queues are active. ibmvnic_complete_tx() and others wake up the queue only if the queue is marked active.
So we will have: A. reset/open thread in ibmvnic_cleanup() and __ibmvnic_open()
->resetting = true
->tx_queues_active = false
disable tx queues
...
->tx_queues_active = true
start tx queues
B. Tx interrupt in ibmvnic_complete_tx():
if (->tx_queues_active)
netif_wake_subqueue();
To ensure that ->tx_queues_active and state of the queues are consistent, we need a lock which:
- must also be taken in the interrupt path (ibmvnic_complete_tx())
- shared across the multiple
---truncated---
{
"affected": [],
"aliases": [
"CVE-2022-49201"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:00:57Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nibmvnic: fix race between xmit and reset\n\nThere is a race between reset and the transmit paths that can lead to\nibmvnic_xmit() accessing an scrq after it has been freed in the reset\npath. It can result in a crash like:\n\n\tKernel attempted to read user page (0) - exploit attempt? (uid: 0)\n\tBUG: Kernel NULL pointer dereference on read at 0x00000000\n\tFaulting instruction address: 0xc0080000016189f8\n\tOops: Kernel access of bad area, sig: 11 [#1]\n\t...\n\tNIP [c0080000016189f8] ibmvnic_xmit+0x60/0xb60 [ibmvnic]\n\tLR [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280\n\tCall Trace:\n\t[c008000001618f08] ibmvnic_xmit+0x570/0xb60 [ibmvnic] (unreliable)\n\t[c000000000c0046c] dev_hard_start_xmit+0x11c/0x280\n\t[c000000000c9cfcc] sch_direct_xmit+0xec/0x330\n\t[c000000000bfe640] __dev_xmit_skb+0x3a0/0x9d0\n\t[c000000000c00ad4] __dev_queue_xmit+0x394/0x730\n\t[c008000002db813c] __bond_start_xmit+0x254/0x450 [bonding]\n\t[c008000002db8378] bond_start_xmit+0x40/0xc0 [bonding]\n\t[c000000000c0046c] dev_hard_start_xmit+0x11c/0x280\n\t[c000000000c00ca4] __dev_queue_xmit+0x564/0x730\n\t[c000000000cf97e0] neigh_hh_output+0xd0/0x180\n\t[c000000000cfa69c] ip_finish_output2+0x31c/0x5c0\n\t[c000000000cfd244] __ip_queue_xmit+0x194/0x4f0\n\t[c000000000d2a3c4] __tcp_transmit_skb+0x434/0x9b0\n\t[c000000000d2d1e0] __tcp_retransmit_skb+0x1d0/0x6a0\n\t[c000000000d2d984] tcp_retransmit_skb+0x34/0x130\n\t[c000000000d310e8] tcp_retransmit_timer+0x388/0x6d0\n\t[c000000000d315ec] tcp_write_timer_handler+0x1bc/0x330\n\t[c000000000d317bc] tcp_write_timer+0x5c/0x200\n\t[c000000000243270] call_timer_fn+0x50/0x1c0\n\t[c000000000243704] __run_timers.part.0+0x324/0x460\n\t[c000000000243894] run_timer_softirq+0x54/0xa0\n\t[c000000000ea713c] __do_softirq+0x15c/0x3e0\n\t[c000000000166258] __irq_exit_rcu+0x158/0x190\n\t[c000000000166420] irq_exit+0x20/0x40\n\t[c00000000002853c] timer_interrupt+0x14c/0x2b0\n\t[c000000000009a00] decrementer_common_virt+0x210/0x220\n\t--- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2c\n\nThe immediate cause of the crash is the access of tx_scrq in the following\nsnippet during a reset, where the tx_scrq can be either NULL or an address\nthat will soon be invalid:\n\n\tibmvnic_xmit()\n\t{\n\t\t...\n\t\ttx_scrq = adapter-\u003etx_scrq[queue_num];\n\t\ttxq = netdev_get_tx_queue(netdev, queue_num);\n\t\tind_bufp = \u0026tx_scrq-\u003eind_buf;\n\n\t\tif (test_bit(0, \u0026adapter-\u003eresetting)) {\n\t\t...\n\t}\n\nBut beyond that, the call to ibmvnic_xmit() itself is not safe during a\nreset and the reset path attempts to avoid this by stopping the queue in\nibmvnic_cleanup(). However just after the queue was stopped, an in-flight\nibmvnic_complete_tx() could have restarted the queue even as the reset is\nprogressing.\n\nSince the queue was restarted we could get a call to ibmvnic_xmit() which\ncan then access the bad tx_scrq (or other fields).\n\nWe cannot however simply have ibmvnic_complete_tx() check the -\u003eresetting\nbit and skip starting the queue. This can race at the \"back-end\" of a good\nreset which just restarted the queue but has not cleared the -\u003eresetting\nbit yet. If we skip restarting the queue due to -\u003eresetting being true,\nthe queue would remain stopped indefinitely potentially leading to transmit\ntimeouts.\n\nIOW -\u003eresetting is too broad for this purpose. Instead use a new flag\nthat indicates whether or not the queues are active. Only the open/\nreset paths control when the queues are active. ibmvnic_complete_tx()\nand others wake up the queue only if the queue is marked active.\n\nSo we will have:\n\tA. reset/open thread in ibmvnic_cleanup() and __ibmvnic_open()\n\n\t\t-\u003eresetting = true\n\t\t-\u003etx_queues_active = false\n\t\tdisable tx queues\n\t\t...\n\t\t-\u003etx_queues_active = true\n\t\tstart tx queues\n\n\tB. Tx interrupt in ibmvnic_complete_tx():\n\n\t\tif (-\u003etx_queues_active)\n\t\t\tnetif_wake_subqueue();\n\nTo ensure that -\u003etx_queues_active and state of the queues are consistent,\nwe need a lock which:\n\n\t- must also be taken in the interrupt path (ibmvnic_complete_tx())\n\t- shared across the multiple\n---truncated---",
"id": "GHSA-5m5f-j2wx-5r78",
"modified": "2025-03-18T21:31:59Z",
"published": "2025-03-18T21:31:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49201"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1bd58abf595b6cf1ba6dd47ec887c4c009155fc9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4219196d1f662cb10a462eb9e076633a3fc31a15"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/475f9cce98b63bc145b4efa66fa51175d4cb345f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8507c6ade73cdbbbda5c3d31d67f52f2e1cf03fe"
}
],
"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-5M7X-C2V2-7479
Vulnerability from github – Published: 2022-05-17 00:56 – Updated: 2022-05-17 00:56Race condition in Google Chrome before 25.0.1364.152 allows remote attackers to cause a denial of service or possibly have unspecified other impact via vectors related to the handling of media threads.
{
"affected": [],
"aliases": [
"CVE-2013-0907"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2013-03-05T21:55:00Z",
"severity": "HIGH"
},
"details": "Race condition in Google Chrome before 25.0.1364.152 allows remote attackers to cause a denial of service or possibly have unspecified other impact via vectors related to the handling of media threads.",
"id": "GHSA-5m7x-c2v2-7479",
"modified": "2022-05-17T00:56:48Z",
"published": "2022-05-17T00:56:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-0907"
},
{
"type": "WEB",
"url": "https://code.google.com/p/chromium/issues/detail?id=174150"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A16633"
},
{
"type": "WEB",
"url": "http://googlechromereleases.blogspot.com/2013/03/stable-channel-update_4.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-5M8P-58J9-6JM9
Vulnerability from github – Published: 2026-10-06 21:31 – Updated: 2026-10-06 21:31Race condition in V8 in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to potentially execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High)
{
"affected": [],
"aliases": [
"CVE-2026-106255"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-06T19:17:52Z",
"severity": "HIGH"
},
"details": "Race condition in V8 in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to potentially execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High)",
"id": "GHSA-5m8p-58j9-6jm9",
"modified": "2026-10-06T21:31:44Z",
"published": "2026-10-06T21:31:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106255"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/10/stable-channel-update-for-desktop_086471744.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/559780376"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
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.