CWE-667
Allowed-with-ReviewImproper Locking
Abstraction: Class · Status: Draft
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
733 vulnerabilities reference this CWE, most recent first.
GHSA-69RM-W9QJ-3X45
Vulnerability from github – Published: 2025-06-17 15:31 – Updated: 2025-12-11 18:30A flaw was found in the X server's request handling. Non-zero 'bytes to ignore' in a client's request can cause the server to skip processing another client's request, potentially leading to a denial of service.
{
"affected": [],
"aliases": [
"CVE-2025-49178"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-17T15:15:45Z",
"severity": "MODERATE"
},
"details": "A flaw was found in the X server\u0027s request handling. Non-zero \u0027bytes to ignore\u0027 in a client\u0027s request can cause the server to skip processing another client\u0027s request, potentially leading to a denial of service.",
"id": "GHSA-69rm-w9qj-3x45",
"modified": "2025-12-11T18:30:32Z",
"published": "2025-06-17T15:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49178"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:10376"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:10377"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:10378"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:10381"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:10410"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:9303"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:9304"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:9305"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:9306"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:9392"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:9964"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2025-49178"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2369977"
},
{
"type": "WEB",
"url": "https://gitlab.freedesktop.org/xorg/xserver/-/commit/d55c54cecb5e83eaa2d56bed5cc4461f9ba318c2"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/06/msg00028.html"
},
{
"type": "WEB",
"url": "https://www.x.org/wiki/Development/Security"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:10258"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:10342"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:10343"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:10344"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:10346"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:10347"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:10348"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:10349"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:10350"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:10351"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:10352"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:10355"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:10356"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:10360"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:10370"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:10374"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:10375"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6CPQ-CWGW-5G63
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-14 21:30In the Linux kernel, the following vulnerability has been resolved:
USB: gadget: Fix obscure lockdep violation for udc_mutex
A recent commit expanding the scope of the udc_lock mutex in the gadget core managed to cause an obscure and slightly bizarre lockdep violation. In abbreviated form:
====================================================== WARNING: possible circular locking dependency detected 5.19.0-rc7+ #12510 Not tainted
udevadm/312 is trying to acquire lock: ffff80000aae1058 (udc_lock){+.+.}-{3:3}, at: usb_udc_uevent+0x54/0xe0
but task is already holding lock: ffff000002277548 (kn->active#4){++++}-{0:0}, at: kernfs_seq_start+0x34/0xe0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (kn->active#4){++++}-{0:0}: lock_acquire+0x68/0x84 __kernfs_remove+0x268/0x380 kernfs_remove_by_name_ns+0x58/0xac sysfs_remove_file_ns+0x18/0x24 device_del+0x15c/0x440
-> #2 (device_links_lock){+.+.}-{3:3}: lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 device_link_remove+0x3c/0xa0 _regulator_put.part.0+0x168/0x190 regulator_put+0x3c/0x54 devm_regulator_release+0x14/0x20
-> #1 (regulator_list_mutex){+.+.}-{3:3}: lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 regulator_lock_dependent+0x54/0x284 regulator_enable+0x34/0x80 phy_power_on+0x24/0x130 __dwc2_lowlevel_hw_enable+0x100/0x130 dwc2_lowlevel_hw_enable+0x18/0x40 dwc2_hsotg_udc_start+0x6c/0x2f0 gadget_bind_driver+0x124/0x1f4
-> #0 (udc_lock){+.+.}-{3:3}: __lock_acquire+0x1298/0x20cc lock_acquire.part.0+0xe0/0x230 lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 usb_udc_uevent+0x54/0xe0
Evidently this was caused by the scope of udc_mutex being too large. The mutex is only meant to protect udc->driver along with a few other things. As far as I can tell, there's no reason for the mutex to be held while the gadget core calls a gadget driver's ->bind or ->unbind routine, or while a UDC is being started or stopped. (This accounts for link #1 in the chain above, where the mutex is held while the dwc2_hsotg_udc is started as part of driver probing.)
Gadget drivers' ->disconnect callbacks are problematic. Even though usb_gadget_disconnect() will now acquire the udc_mutex, there's a window in usb_gadget_bind_driver() between the times when the mutex is released and the ->bind callback is invoked. If a disconnect occurred during that window, we could call the driver's ->disconnect routine before its ->bind routine. To prevent this from happening, it will be necessary to prevent a UDC from connecting while it has no gadget driver. This should be done already but it doesn't seem to be; currently usb_gadget_connect() has no check for this. Such a check will have to be added later.
Some degree of mutual exclusion is required in soft_connect_store(), which can dereference udc->driver at arbitrary times since it is a sysfs callback. The solution here is to acquire the gadget's device lock rather than the udc_mutex. Since the driver core guarantees that the device lock is always held during driver binding and unbinding, this will make the accesses in soft_connect_store() mutually exclusive with any changes to udc->driver.
Lastly, it turns out there is one place which should hold the udc_mutex but currently does not: The function_show() routine needs protection while it dereferences udc->driver. The missing lock and unlock calls are added.
{
"affected": [],
"aliases": [
"CVE-2022-49943"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:21Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: gadget: Fix obscure lockdep violation for udc_mutex\n\nA recent commit expanding the scope of the udc_lock mutex in the\ngadget core managed to cause an obscure and slightly bizarre lockdep\nviolation. In abbreviated form:\n\n======================================================\nWARNING: possible circular locking dependency detected\n5.19.0-rc7+ #12510 Not tainted\n------------------------------------------------------\nudevadm/312 is trying to acquire lock:\nffff80000aae1058 (udc_lock){+.+.}-{3:3}, at: usb_udc_uevent+0x54/0xe0\n\nbut task is already holding lock:\nffff000002277548 (kn-\u003eactive#4){++++}-{0:0}, at: kernfs_seq_start+0x34/0xe0\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u003e #3 (kn-\u003eactive#4){++++}-{0:0}:\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 lock_acquire+0x68/0x84\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 __kernfs_remove+0x268/0x380\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 kernfs_remove_by_name_ns+0x58/0xac\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 sysfs_remove_file_ns+0x18/0x24\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 device_del+0x15c/0x440\n\n-\u003e #2 (device_links_lock){+.+.}-{3:3}:\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 lock_acquire+0x68/0x84\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 __mutex_lock+0x9c/0x430\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 mutex_lock_nested+0x38/0x64\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 device_link_remove+0x3c/0xa0\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 _regulator_put.part.0+0x168/0x190\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 regulator_put+0x3c/0x54\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 devm_regulator_release+0x14/0x20\n\n-\u003e #1 (regulator_list_mutex){+.+.}-{3:3}:\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 lock_acquire+0x68/0x84\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 __mutex_lock+0x9c/0x430\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 mutex_lock_nested+0x38/0x64\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 regulator_lock_dependent+0x54/0x284\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 regulator_enable+0x34/0x80\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 phy_power_on+0x24/0x130\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 __dwc2_lowlevel_hw_enable+0x100/0x130\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 dwc2_lowlevel_hw_enable+0x18/0x40\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 dwc2_hsotg_udc_start+0x6c/0x2f0\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 gadget_bind_driver+0x124/0x1f4\n\n-\u003e #0 (udc_lock){+.+.}-{3:3}:\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 __lock_acquire+0x1298/0x20cc\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 lock_acquire.part.0+0xe0/0x230\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 lock_acquire+0x68/0x84\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 __mutex_lock+0x9c/0x430\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 mutex_lock_nested+0x38/0x64\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 usb_udc_uevent+0x54/0xe0\n\nEvidently this was caused by the scope of udc_mutex being too large.\nThe mutex is only meant to protect udc-\u003edriver along with a few other\nthings. As far as I can tell, there\u0027s no reason for the mutex to be\nheld while the gadget core calls a gadget driver\u0027s -\u003ebind or -\u003eunbind\nroutine, or while a UDC is being started or stopped. (This accounts\nfor link #1 in the chain above, where the mutex is held while the\ndwc2_hsotg_udc is started as part of driver probing.)\n\nGadget drivers\u0027 -\u003edisconnect callbacks are problematic. Even though\nusb_gadget_disconnect() will now acquire the udc_mutex, there\u0027s a\nwindow in usb_gadget_bind_driver() between the times when the mutex is\nreleased and the -\u003ebind callback is invoked. If a disconnect occurred\nduring that window, we could call the driver\u0027s -\u003edisconnect routine\nbefore its -\u003ebind routine. To prevent this from happening, it will be\nnecessary to prevent a UDC from connecting while it has no gadget\ndriver. This should be done already but it doesn\u0027t seem to be;\ncurrently usb_gadget_connect() has no check for this. Such a check\nwill have to be added later.\n\nSome degree of mutual exclusion is required in soft_connect_store(),\nwhich can dereference udc-\u003edriver at arbitrary times since it is a\nsysfs callback. The solution here is to acquire the gadget\u0027s device\nlock rather than the udc_mutex. Since the driver core guarantees that\nthe device lock is always held during driver binding and unbinding,\nthis will make the accesses in soft_connect_store() mutually exclusive\nwith any changes to udc-\u003edriver.\n\nLastly, it turns out there is one place which should hold the\nudc_mutex but currently does not: The function_show() routine needs\nprotection while it dereferences udc-\u003edriver. The missing lock and\nunlock calls are added.",
"id": "GHSA-6cpq-cwgw-5g63",
"modified": "2025-11-14T21:30:27Z",
"published": "2025-06-18T12:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49943"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1016fc0c096c92dd0e6e0541daac7a7868169903"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1a065e4673cbdd9f222a05f85e17d78ea50c8d9c"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6F24-WM2Q-5FJ6
Vulnerability from github – Published: 2025-05-02 18:31 – Updated: 2025-11-07 18:30In the Linux kernel, the following vulnerability has been resolved:
igb: revert rtnl_lock() that causes deadlock
The commit 6faee3d4ee8b ("igb: Add lock to avoid data race") adds rtnl_lock to eliminate a false data race shown below
(FREE from device detaching) | (USE from netdev core) igb_remove | igb_ndo_get_vf_config igb_disable_sriov | vf >= adapter->vfs_allocated_count? kfree(adapter->vf_data) | adapter->vfs_allocated_count = 0 | | memcpy(... adapter->vf_data[vf]
The above race will never happen and the extra rtnl_lock causes deadlock below
[ 141.420169] [ 141.420672] __schedule+0x2dd/0x840 [ 141.421427] schedule+0x50/0xc0 [ 141.422041] schedule_preempt_disabled+0x11/0x20 [ 141.422678] __mutex_lock.isra.13+0x431/0x6b0 [ 141.423324] unregister_netdev+0xe/0x20 [ 141.423578] igbvf_remove+0x45/0xe0 [igbvf] [ 141.423791] pci_device_remove+0x36/0xb0 [ 141.423990] device_release_driver_internal+0xc1/0x160 [ 141.424270] pci_stop_bus_device+0x6d/0x90 [ 141.424507] pci_stop_and_remove_bus_device+0xe/0x20 [ 141.424789] pci_iov_remove_virtfn+0xba/0x120 [ 141.425452] sriov_disable+0x2f/0xf0 [ 141.425679] igb_disable_sriov+0x4e/0x100 [igb] [ 141.426353] igb_remove+0xa0/0x130 [igb] [ 141.426599] pci_device_remove+0x36/0xb0 [ 141.426796] device_release_driver_internal+0xc1/0x160 [ 141.427060] driver_detach+0x44/0x90 [ 141.427253] bus_remove_driver+0x55/0xe0 [ 141.427477] pci_unregister_driver+0x2a/0xa0 [ 141.428296] __x64_sys_delete_module+0x141/0x2b0 [ 141.429126] ? mntput_no_expire+0x4a/0x240 [ 141.429363] ? syscall_trace_enter.isra.19+0x126/0x1a0 [ 141.429653] do_syscall_64+0x5b/0x80 [ 141.429847] ? exit_to_user_mode_prepare+0x14d/0x1c0 [ 141.430109] ? syscall_exit_to_user_mode+0x12/0x30 [ 141.430849] ? do_syscall_64+0x67/0x80 [ 141.431083] ? syscall_exit_to_user_mode_prepare+0x183/0x1b0 [ 141.431770] ? syscall_exit_to_user_mode+0x12/0x30 [ 141.432482] ? do_syscall_64+0x67/0x80 [ 141.432714] ? exc_page_fault+0x64/0x140 [ 141.432911] entry_SYSCALL_64_after_hwframe+0x72/0xdc
Since the igb_disable_sriov() will call pci_disable_sriov() before releasing any resources, the netdev core will synchronize the cleanup to avoid any races. This patch removes the useless rtnl_(un)lock to guarantee correctness.
{
"affected": [],
"aliases": [
"CVE-2023-53060"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-02T16:15:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nigb: revert rtnl_lock() that causes deadlock\n\nThe commit 6faee3d4ee8b (\"igb: Add lock to avoid data race\") adds\nrtnl_lock to eliminate a false data race shown below\n\n (FREE from device detaching) | (USE from netdev core)\nigb_remove | igb_ndo_get_vf_config\n igb_disable_sriov | vf \u003e= adapter-\u003evfs_allocated_count?\n kfree(adapter-\u003evf_data) |\n adapter-\u003evfs_allocated_count = 0 |\n | memcpy(... adapter-\u003evf_data[vf]\n\nThe above race will never happen and the extra rtnl_lock causes deadlock\nbelow\n\n[ 141.420169] \u003cTASK\u003e\n[ 141.420672] __schedule+0x2dd/0x840\n[ 141.421427] schedule+0x50/0xc0\n[ 141.422041] schedule_preempt_disabled+0x11/0x20\n[ 141.422678] __mutex_lock.isra.13+0x431/0x6b0\n[ 141.423324] unregister_netdev+0xe/0x20\n[ 141.423578] igbvf_remove+0x45/0xe0 [igbvf]\n[ 141.423791] pci_device_remove+0x36/0xb0\n[ 141.423990] device_release_driver_internal+0xc1/0x160\n[ 141.424270] pci_stop_bus_device+0x6d/0x90\n[ 141.424507] pci_stop_and_remove_bus_device+0xe/0x20\n[ 141.424789] pci_iov_remove_virtfn+0xba/0x120\n[ 141.425452] sriov_disable+0x2f/0xf0\n[ 141.425679] igb_disable_sriov+0x4e/0x100 [igb]\n[ 141.426353] igb_remove+0xa0/0x130 [igb]\n[ 141.426599] pci_device_remove+0x36/0xb0\n[ 141.426796] device_release_driver_internal+0xc1/0x160\n[ 141.427060] driver_detach+0x44/0x90\n[ 141.427253] bus_remove_driver+0x55/0xe0\n[ 141.427477] pci_unregister_driver+0x2a/0xa0\n[ 141.428296] __x64_sys_delete_module+0x141/0x2b0\n[ 141.429126] ? mntput_no_expire+0x4a/0x240\n[ 141.429363] ? syscall_trace_enter.isra.19+0x126/0x1a0\n[ 141.429653] do_syscall_64+0x5b/0x80\n[ 141.429847] ? exit_to_user_mode_prepare+0x14d/0x1c0\n[ 141.430109] ? syscall_exit_to_user_mode+0x12/0x30\n[ 141.430849] ? do_syscall_64+0x67/0x80\n[ 141.431083] ? syscall_exit_to_user_mode_prepare+0x183/0x1b0\n[ 141.431770] ? syscall_exit_to_user_mode+0x12/0x30\n[ 141.432482] ? do_syscall_64+0x67/0x80\n[ 141.432714] ? exc_page_fault+0x64/0x140\n[ 141.432911] entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\nSince the igb_disable_sriov() will call pci_disable_sriov() before\nreleasing any resources, the netdev core will synchronize the cleanup to\navoid any races. This patch removes the useless rtnl_(un)lock to guarantee\ncorrectness.",
"id": "GHSA-6f24-wm2q-5fj6",
"modified": "2025-11-07T18:30:26Z",
"published": "2025-05-02T18:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53060"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0dabb72b923e17cb3b4ac99ea1adc9ef35116930"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4d2626e10709ff8474ffd1a9db3cf4647569e89c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/62a64645749926f9d75af82a96440941f22b046f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/65f69851e44d71248b952a687e44759a7abb5016"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/66e5577cabc3d463eea540332727929d0ace41c6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7d845e9a485f287181ff81567c3900a8e7ad1e28"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cd1e320ac0958298c2774605ad050483f33a21f2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de91528d8ba274c614a2265077d695c61e31fd43"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6F2W-35QH-6J7J
Vulnerability from github – Published: 2022-05-24 17:29 – Updated: 2026-08-19 15:31A lock was missing when accessing a data structure and importing certificate information into the trust database. This vulnerability affects Firefox < 80 and Firefox for Android < 80.
{
"affected": [],
"aliases": [
"CVE-2020-15668"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-10-01T19:15:00Z",
"severity": "MODERATE"
},
"details": "A lock was missing when accessing a data structure and importing certificate information into the trust database. This vulnerability affects Firefox \u003c 80 and Firefox for Android \u003c 80.",
"id": "GHSA-6f2w-35qh-6j7j",
"modified": "2026-08-19T15:31:50Z",
"published": "2022-05-24T17:29:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15668"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1651520"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2020-36"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2020-39"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-6GRR-36F8-J7PV
Vulnerability from github – Published: 2026-05-05 18:33 – Updated: 2026-05-29 18:31In the Linux kernel, the following vulnerability has been resolved:
serial: 8250: Fix TX deadlock when using DMA
dmaengine_terminate_async does not guarantee that the
__dma_tx_complete callback will run. The callback is currently the
only place where dma->tx_running gets cleared. If the transaction is
canceled and the callback never runs, then dma->tx_running will never
get cleared and we will never schedule new TX DMA transactions again.
This change makes it so we clear dma->tx_running after we terminate
the DMA transaction. This is "safe" because serial8250_tx_dma_flush
is holding the UART port lock. The first thing the callback does is also
grab the UART port lock, so access to dma->tx_running is serialized.
{
"affected": [],
"aliases": [
"CVE-2026-43061"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-05T16:16:15Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nserial: 8250: Fix TX deadlock when using DMA\n\n`dmaengine_terminate_async` does not guarantee that the\n`__dma_tx_complete` callback will run. The callback is currently the\nonly place where `dma-\u003etx_running` gets cleared. If the transaction is\ncanceled and the callback never runs, then `dma-\u003etx_running` will never\nget cleared and we will never schedule new TX DMA transactions again.\n\nThis change makes it so we clear `dma-\u003etx_running` after we terminate\nthe DMA transaction. This is \"safe\" because `serial8250_tx_dma_flush`\nis holding the UART port lock. The first thing the callback does is also\ngrab the UART port lock, so access to `dma-\u003etx_running` is serialized.",
"id": "GHSA-6grr-36f8-j7pv",
"modified": "2026-05-29T18:31:14Z",
"published": "2026-05-05T18:33:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43061"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2a72403b985aea6b4aac3171830492f9a387f9e1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5f6b17562f03fc65c7d3474ef8f1959b19d1ca41"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/79a19bd936bb35f56ef0ccab1b3b59ebce8c762d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8190f9ab6ad90cb97652adbebd238b874a4ef70d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a424a34b8faddf97b5af41689087e7a230f79ba7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b5ad887339503103d0fbe9827b16ad287597c275"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d2719a0a9c3439abf67843a5504b7afccd9ded93"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f76d91271bcacbd759a2e4ee3ea61faa6a727ccf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6H6F-84WV-5RQQ
Vulnerability from github – Published: 2024-11-08 06:30 – Updated: 2024-11-19 18:30In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Fix reader locking when changing the sub buffer order
The function ring_buffer_subbuf_order_set() updates each ring_buffer_per_cpu and installs new sub buffers that match the requested page order. This operation may be invoked concurrently with readers that rely on some of the modified data, such as the head bit (RB_PAGE_HEAD), or the ring_buffer_per_cpu.pages and reader_page pointers. However, no exclusive access is acquired by ring_buffer_subbuf_order_set(). Modifying the mentioned data while a reader also operates on them can then result in incorrect memory access and various crashes.
Fix the problem by taking the reader_lock when updating a specific ring_buffer_per_cpu in ring_buffer_subbuf_order_set().
{
"affected": [],
"aliases": [
"CVE-2024-50207"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-08T06:15:17Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nring-buffer: Fix reader locking when changing the sub buffer order\n\nThe function ring_buffer_subbuf_order_set() updates each\nring_buffer_per_cpu and installs new sub buffers that match the requested\npage order. This operation may be invoked concurrently with readers that\nrely on some of the modified data, such as the head bit (RB_PAGE_HEAD), or\nthe ring_buffer_per_cpu.pages and reader_page pointers. However, no\nexclusive access is acquired by ring_buffer_subbuf_order_set(). Modifying\nthe mentioned data while a reader also operates on them can then result in\nincorrect memory access and various crashes.\n\nFix the problem by taking the reader_lock when updating a specific\nring_buffer_per_cpu in ring_buffer_subbuf_order_set().",
"id": "GHSA-6h6f-84wv-5rqq",
"modified": "2024-11-19T18:30:54Z",
"published": "2024-11-08T06:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50207"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/09661f75e75cb6c1d2d8326a70c311d46729235f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a569290525a05162d5dd26d9845591eaf46e5802"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6HCQ-HMM3-JJ3C
Vulnerability from github – Published: 2026-03-20 00:31 – Updated: 2026-03-20 20:41Spring MVC and WebFlux applications are vulnerable to stream corruption when using Server-Sent Events (SSE). This issue affects Spring Foundation: from 7.0.0 through 7.0.5, from 6.2.0 through 6.2.16, from 6.1.0 through 6.1.25, from 5.3.0 through 5.3.46.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-webmvc"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0-M1"
},
{
"fixed": "7.0.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-webmvc"
},
"ranges": [
{
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.2.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-webmvc"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"last_affected": "6.1.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-webmvc"
},
"ranges": [
{
"events": [
{
"introduced": "5.3.0"
},
{
"last_affected": "5.3.39"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-webflux"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0-M1"
},
{
"fixed": "7.0.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-webflux"
},
"ranges": [
{
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.2.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-webflux"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"last_affected": "6.1.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-webflux"
},
"ranges": [
{
"events": [
{
"introduced": "5.3.0"
},
{
"last_affected": "5.3.39"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-22735"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-20T20:41:16Z",
"nvd_published_at": "2026-03-20T00:16:15Z",
"severity": "LOW"
},
"details": "Spring MVC and WebFlux applications are vulnerable to stream corruption when using Server-Sent Events (SSE).\u00a0This issue affects Spring Foundation: from 7.0.0 through 7.0.5, from 6.2.0 through 6.2.16, from 6.1.0 through 6.1.25, from 5.3.0 through 5.3.46.",
"id": "GHSA-6hcq-hmm3-jj3c",
"modified": "2026-03-20T20:41:16Z",
"published": "2026-03-20T00:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22735"
},
{
"type": "PACKAGE",
"url": "https://github.com/spring-projects/spring-framework"
},
{
"type": "WEB",
"url": "https://spring.io/security/cve-2026-22735"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Spring MVC and WebFlux has Server Sent Event stream corruption"
}
GHSA-6HQ8-G74X-24Q3
Vulnerability from github – Published: 2025-10-24 18:30 – Updated: 2025-10-24 18:30In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix hang during unmount when block group reclaim task is running
When we start an unmount, at close_ctree(), if we have the reclaim task running and in the middle of a data block group relocation, we can trigger a deadlock when stopping an async reclaim task, producing a trace like the following:
[629724.498185] task:kworker/u16:7 state:D stack: 0 pid:681170 ppid: 2 flags:0x00004000 [629724.499760] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs] [629724.501267] Call Trace: [629724.501759] [629724.502174] __schedule+0x3cb/0xed0 [629724.502842] schedule+0x4e/0xb0 [629724.503447] btrfs_wait_on_delayed_iputs+0x7c/0xc0 [btrfs] [629724.504534] ? prepare_to_wait_exclusive+0xc0/0xc0 [629724.505442] flush_space+0x423/0x630 [btrfs] [629724.506296] ? rcu_read_unlock_trace_special+0x20/0x50 [629724.507259] ? lock_release+0x220/0x4a0 [629724.507932] ? btrfs_get_alloc_profile+0xb3/0x290 [btrfs] [629724.508940] ? do_raw_spin_unlock+0x4b/0xa0 [629724.509688] btrfs_async_reclaim_metadata_space+0x139/0x320 [btrfs] [629724.510922] process_one_work+0x252/0x5a0 [629724.511694] ? process_one_work+0x5a0/0x5a0 [629724.512508] worker_thread+0x52/0x3b0 [629724.513220] ? process_one_work+0x5a0/0x5a0 [629724.514021] kthread+0xf2/0x120 [629724.514627] ? kthread_complete_and_exit+0x20/0x20 [629724.515526] ret_from_fork+0x22/0x30 [629724.516236] [629724.516694] task:umount state:D stack: 0 pid:719055 ppid:695412 flags:0x00004000 [629724.518269] Call Trace: [629724.518746] [629724.519160] __schedule+0x3cb/0xed0 [629724.519835] schedule+0x4e/0xb0 [629724.520467] schedule_timeout+0xed/0x130 [629724.521221] ? lock_release+0x220/0x4a0 [629724.521946] ? lock_acquired+0x19c/0x420 [629724.522662] ? trace_hardirqs_on+0x1b/0xe0 [629724.523411] __wait_for_common+0xaf/0x1f0 [629724.524189] ? usleep_range_state+0xb0/0xb0 [629724.524997] __flush_work+0x26d/0x530 [629724.525698] ? flush_workqueue_prep_pwqs+0x140/0x140 [629724.526580] ? lock_acquire+0x1a0/0x310 [629724.527324] __cancel_work_timer+0x137/0x1c0 [629724.528190] close_ctree+0xfd/0x531 [btrfs] [629724.529000] ? evict_inodes+0x166/0x1c0 [629724.529510] generic_shutdown_super+0x74/0x120 [629724.530103] kill_anon_super+0x14/0x30 [629724.530611] btrfs_kill_super+0x12/0x20 [btrfs] [629724.531246] deactivate_locked_super+0x31/0xa0 [629724.531817] cleanup_mnt+0x147/0x1c0 [629724.532319] task_work_run+0x5c/0xa0 [629724.532984] exit_to_user_mode_prepare+0x1a6/0x1b0 [629724.533598] syscall_exit_to_user_mode+0x16/0x40 [629724.534200] do_syscall_64+0x48/0x90 [629724.534667] entry_SYSCALL_64_after_hwframe+0x44/0xae [629724.535318] RIP: 0033:0x7fa2b90437a7 [629724.535804] RSP: 002b:00007ffe0b7e4458 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 [629724.536912] RAX: 0000000000000000 RBX: 00007fa2b9182264 RCX: 00007fa2b90437a7 [629724.538156] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000555d6cf20dd0 [629724.539053] RBP: 0000555d6cf20ba0 R08: 0000000000000000 R09: 00007ffe0b7e3200 [629724.539956] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [629724.540883] R13: 0000555d6cf20dd0 R14: 0000555d6cf20cb0 R15: 0000000000000000 [629724.541796]
This happens because:
1) Before entering close_ctree() we have the async block group reclaim task running and relocating a data block group;
2) There's an async metadata (or data) space reclaim task running;
3) We enter close_ctree() and park the cleaner kthread;
4) The async space reclaim task is at flush_space() and runs all the existing delayed iputs;
5) Before the async space reclaim task calls btrfs_wait_on_delayed_iputs(), the block group reclaim task which is doing the data block group relocation, creates a delayed iput at replace_file_extents() (called when COWing leaves that have file extent items pointing to relocated data exten ---truncated---
{
"affected": [],
"aliases": [
"CVE-2022-49702"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:45Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix hang during unmount when block group reclaim task is running\n\nWhen we start an unmount, at close_ctree(), if we have the reclaim task\nrunning and in the middle of a data block group relocation, we can trigger\na deadlock when stopping an async reclaim task, producing a trace like the\nfollowing:\n\n[629724.498185] task:kworker/u16:7 state:D stack: 0 pid:681170 ppid: 2 flags:0x00004000\n[629724.499760] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs]\n[629724.501267] Call Trace:\n[629724.501759] \u003cTASK\u003e\n[629724.502174] __schedule+0x3cb/0xed0\n[629724.502842] schedule+0x4e/0xb0\n[629724.503447] btrfs_wait_on_delayed_iputs+0x7c/0xc0 [btrfs]\n[629724.504534] ? prepare_to_wait_exclusive+0xc0/0xc0\n[629724.505442] flush_space+0x423/0x630 [btrfs]\n[629724.506296] ? rcu_read_unlock_trace_special+0x20/0x50\n[629724.507259] ? lock_release+0x220/0x4a0\n[629724.507932] ? btrfs_get_alloc_profile+0xb3/0x290 [btrfs]\n[629724.508940] ? do_raw_spin_unlock+0x4b/0xa0\n[629724.509688] btrfs_async_reclaim_metadata_space+0x139/0x320 [btrfs]\n[629724.510922] process_one_work+0x252/0x5a0\n[629724.511694] ? process_one_work+0x5a0/0x5a0\n[629724.512508] worker_thread+0x52/0x3b0\n[629724.513220] ? process_one_work+0x5a0/0x5a0\n[629724.514021] kthread+0xf2/0x120\n[629724.514627] ? kthread_complete_and_exit+0x20/0x20\n[629724.515526] ret_from_fork+0x22/0x30\n[629724.516236] \u003c/TASK\u003e\n[629724.516694] task:umount state:D stack: 0 pid:719055 ppid:695412 flags:0x00004000\n[629724.518269] Call Trace:\n[629724.518746] \u003cTASK\u003e\n[629724.519160] __schedule+0x3cb/0xed0\n[629724.519835] schedule+0x4e/0xb0\n[629724.520467] schedule_timeout+0xed/0x130\n[629724.521221] ? lock_release+0x220/0x4a0\n[629724.521946] ? lock_acquired+0x19c/0x420\n[629724.522662] ? trace_hardirqs_on+0x1b/0xe0\n[629724.523411] __wait_for_common+0xaf/0x1f0\n[629724.524189] ? usleep_range_state+0xb0/0xb0\n[629724.524997] __flush_work+0x26d/0x530\n[629724.525698] ? flush_workqueue_prep_pwqs+0x140/0x140\n[629724.526580] ? lock_acquire+0x1a0/0x310\n[629724.527324] __cancel_work_timer+0x137/0x1c0\n[629724.528190] close_ctree+0xfd/0x531 [btrfs]\n[629724.529000] ? evict_inodes+0x166/0x1c0\n[629724.529510] generic_shutdown_super+0x74/0x120\n[629724.530103] kill_anon_super+0x14/0x30\n[629724.530611] btrfs_kill_super+0x12/0x20 [btrfs]\n[629724.531246] deactivate_locked_super+0x31/0xa0\n[629724.531817] cleanup_mnt+0x147/0x1c0\n[629724.532319] task_work_run+0x5c/0xa0\n[629724.532984] exit_to_user_mode_prepare+0x1a6/0x1b0\n[629724.533598] syscall_exit_to_user_mode+0x16/0x40\n[629724.534200] do_syscall_64+0x48/0x90\n[629724.534667] entry_SYSCALL_64_after_hwframe+0x44/0xae\n[629724.535318] RIP: 0033:0x7fa2b90437a7\n[629724.535804] RSP: 002b:00007ffe0b7e4458 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6\n[629724.536912] RAX: 0000000000000000 RBX: 00007fa2b9182264 RCX: 00007fa2b90437a7\n[629724.538156] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000555d6cf20dd0\n[629724.539053] RBP: 0000555d6cf20ba0 R08: 0000000000000000 R09: 00007ffe0b7e3200\n[629724.539956] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\n[629724.540883] R13: 0000555d6cf20dd0 R14: 0000555d6cf20cb0 R15: 0000000000000000\n[629724.541796] \u003c/TASK\u003e\n\nThis happens because:\n\n1) Before entering close_ctree() we have the async block group reclaim\n task running and relocating a data block group;\n\n2) There\u0027s an async metadata (or data) space reclaim task running;\n\n3) We enter close_ctree() and park the cleaner kthread;\n\n4) The async space reclaim task is at flush_space() and runs all the\n existing delayed iputs;\n\n5) Before the async space reclaim task calls\n btrfs_wait_on_delayed_iputs(), the block group reclaim task which is\n doing the data block group relocation, creates a delayed iput at\n replace_file_extents() (called when COWing leaves that have file extent\n items pointing to relocated data exten\n---truncated---",
"id": "GHSA-6hq8-g74x-24q3",
"modified": "2025-10-24T18:30:57Z",
"published": "2025-10-24T18:30:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49702"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/31e70e527806c546a72262f2fc3d982ee23c42d3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/341d33128a940c6634175dcb6ca92dc454cfa7d2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9fadb11f1295289e0da4d3342ecb6b92c1c99540"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6HQC-57W7-HX9Q
Vulnerability from github – Published: 2025-03-27 15:31 – Updated: 2025-11-03 21:33In the Linux kernel, the following vulnerability has been resolved:
i2c: npcm: disable interrupt enable bit before devm_request_irq
The customer reports that there is a soft lockup issue related to the i2c driver. After checking, the i2c module was doing a tx transfer and the bmc machine reboots in the middle of the i2c transaction, the i2c module keeps the status without being reset.
Due to such an i2c module status, the i2c irq handler keeps getting triggered since the i2c irq handler is registered in the kernel booting process after the bmc machine is doing a warm rebooting. The continuous triggering is stopped by the soft lockup watchdog timer.
Disable the interrupt enable bit in the i2c module before calling devm_request_irq to fix this issue since the i2c relative status bit is read-only.
Here is the soft lockup log. [ 28.176395] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:1] [ 28.183351] Modules linked in: [ 28.186407] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.120-yocto-s-dirty-bbebc78 #1 [ 28.201174] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 28.208128] pc : __do_softirq+0xb0/0x368 [ 28.212055] lr : __do_softirq+0x70/0x368 [ 28.215972] sp : ffffff8035ebca00 [ 28.219278] x29: ffffff8035ebca00 x28: 0000000000000002 x27: ffffff80071a3780 [ 28.226412] x26: ffffffc008bdc000 x25: ffffffc008bcc640 x24: ffffffc008be50c0 [ 28.233546] x23: ffffffc00800200c x22: 0000000000000000 x21: 000000000000001b [ 28.240679] x20: 0000000000000000 x19: ffffff80001c3200 x18: ffffffffffffffff [ 28.247812] x17: ffffffc02d2e0000 x16: ffffff8035eb8b40 x15: 00001e8480000000 [ 28.254945] x14: 02c3647e37dbfcb6 x13: 02c364f2ab14200c x12: 0000000002c364f2 [ 28.262078] x11: 00000000fa83b2da x10: 000000000000b67e x9 : ffffffc008010250 [ 28.269211] x8 : 000000009d983d00 x7 : 7fffffffffffffff x6 : 0000036d74732434 [ 28.276344] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : 0000000000000198 [ 28.283476] x2 : ffffffc02d2e0000 x1 : 00000000000000e0 x0 : ffffffc008bdcb40 [ 28.290611] Call trace: [ 28.293052] __do_softirq+0xb0/0x368 [ 28.296625] __irq_exit_rcu+0xe0/0x100 [ 28.300374] irq_exit+0x14/0x20 [ 28.303513] handle_domain_irq+0x68/0x90 [ 28.307440] gic_handle_irq+0x78/0xb0 [ 28.311098] call_on_irq_stack+0x20/0x38 [ 28.315019] do_interrupt_handler+0x54/0x5c [ 28.319199] el1_interrupt+0x2c/0x4c [ 28.322777] el1h_64_irq_handler+0x14/0x20 [ 28.326872] el1h_64_irq+0x74/0x78 [ 28.330269] __setup_irq+0x454/0x780 [ 28.333841] request_threaded_irq+0xd0/0x1b4 [ 28.338107] devm_request_threaded_irq+0x84/0x100 [ 28.342809] npcm_i2c_probe_bus+0x188/0x3d0 [ 28.346990] platform_probe+0x6c/0xc4 [ 28.350653] really_probe+0xcc/0x45c [ 28.354227] __driver_probe_device+0x8c/0x160 [ 28.358578] driver_probe_device+0x44/0xe0 [ 28.362670] __driver_attach+0x124/0x1d0 [ 28.366589] bus_for_each_dev+0x7c/0xe0 [ 28.370426] driver_attach+0x28/0x30 [ 28.373997] bus_add_driver+0x124/0x240 [ 28.377830] driver_register+0x7c/0x124 [ 28.381662] __platform_driver_register+0x2c/0x34 [ 28.386362] npcm_i2c_init+0x3c/0x5c [ 28.389937] do_one_initcall+0x74/0x230 [ 28.393768] kernel_init_freeable+0x24c/0x2b4 [ 28.398126] kernel_init+0x28/0x130 [ 28.401614] ret_from_fork+0x10/0x20 [ 28.405189] Kernel panic - not syncing: softlockup: hung tasks [ 28.411011] SMP: stopping secondary CPUs [ 28.414933] Kernel Offset: disabled [ 28.418412] CPU features: 0x00000000,00000802 [ 28.427644] Rebooting in 20 seconds..
{
"affected": [],
"aliases": [
"CVE-2025-21878"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-27T15:15:55Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: npcm: disable interrupt enable bit before devm_request_irq\n\nThe customer reports that there is a soft lockup issue related to\nthe i2c driver. After checking, the i2c module was doing a tx transfer\nand the bmc machine reboots in the middle of the i2c transaction, the i2c\nmodule keeps the status without being reset.\n\nDue to such an i2c module status, the i2c irq handler keeps getting\ntriggered since the i2c irq handler is registered in the kernel booting\nprocess after the bmc machine is doing a warm rebooting.\nThe continuous triggering is stopped by the soft lockup watchdog timer.\n\nDisable the interrupt enable bit in the i2c module before calling\ndevm_request_irq to fix this issue since the i2c relative status bit\nis read-only.\n\nHere is the soft lockup log.\n[ 28.176395] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:1]\n[ 28.183351] Modules linked in:\n[ 28.186407] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.120-yocto-s-dirty-bbebc78 #1\n[ 28.201174] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 28.208128] pc : __do_softirq+0xb0/0x368\n[ 28.212055] lr : __do_softirq+0x70/0x368\n[ 28.215972] sp : ffffff8035ebca00\n[ 28.219278] x29: ffffff8035ebca00 x28: 0000000000000002 x27: ffffff80071a3780\n[ 28.226412] x26: ffffffc008bdc000 x25: ffffffc008bcc640 x24: ffffffc008be50c0\n[ 28.233546] x23: ffffffc00800200c x22: 0000000000000000 x21: 000000000000001b\n[ 28.240679] x20: 0000000000000000 x19: ffffff80001c3200 x18: ffffffffffffffff\n[ 28.247812] x17: ffffffc02d2e0000 x16: ffffff8035eb8b40 x15: 00001e8480000000\n[ 28.254945] x14: 02c3647e37dbfcb6 x13: 02c364f2ab14200c x12: 0000000002c364f2\n[ 28.262078] x11: 00000000fa83b2da x10: 000000000000b67e x9 : ffffffc008010250\n[ 28.269211] x8 : 000000009d983d00 x7 : 7fffffffffffffff x6 : 0000036d74732434\n[ 28.276344] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : 0000000000000198\n[ 28.283476] x2 : ffffffc02d2e0000 x1 : 00000000000000e0 x0 : ffffffc008bdcb40\n[ 28.290611] Call trace:\n[ 28.293052] __do_softirq+0xb0/0x368\n[ 28.296625] __irq_exit_rcu+0xe0/0x100\n[ 28.300374] irq_exit+0x14/0x20\n[ 28.303513] handle_domain_irq+0x68/0x90\n[ 28.307440] gic_handle_irq+0x78/0xb0\n[ 28.311098] call_on_irq_stack+0x20/0x38\n[ 28.315019] do_interrupt_handler+0x54/0x5c\n[ 28.319199] el1_interrupt+0x2c/0x4c\n[ 28.322777] el1h_64_irq_handler+0x14/0x20\n[ 28.326872] el1h_64_irq+0x74/0x78\n[ 28.330269] __setup_irq+0x454/0x780\n[ 28.333841] request_threaded_irq+0xd0/0x1b4\n[ 28.338107] devm_request_threaded_irq+0x84/0x100\n[ 28.342809] npcm_i2c_probe_bus+0x188/0x3d0\n[ 28.346990] platform_probe+0x6c/0xc4\n[ 28.350653] really_probe+0xcc/0x45c\n[ 28.354227] __driver_probe_device+0x8c/0x160\n[ 28.358578] driver_probe_device+0x44/0xe0\n[ 28.362670] __driver_attach+0x124/0x1d0\n[ 28.366589] bus_for_each_dev+0x7c/0xe0\n[ 28.370426] driver_attach+0x28/0x30\n[ 28.373997] bus_add_driver+0x124/0x240\n[ 28.377830] driver_register+0x7c/0x124\n[ 28.381662] __platform_driver_register+0x2c/0x34\n[ 28.386362] npcm_i2c_init+0x3c/0x5c\n[ 28.389937] do_one_initcall+0x74/0x230\n[ 28.393768] kernel_init_freeable+0x24c/0x2b4\n[ 28.398126] kernel_init+0x28/0x130\n[ 28.401614] ret_from_fork+0x10/0x20\n[ 28.405189] Kernel panic - not syncing: softlockup: hung tasks\n[ 28.411011] SMP: stopping secondary CPUs\n[ 28.414933] Kernel Offset: disabled\n[ 28.418412] CPU features: 0x00000000,00000802\n[ 28.427644] Rebooting in 20 seconds..",
"id": "GHSA-6hqc-57w7-hx9q",
"modified": "2025-11-03T21:33:13Z",
"published": "2025-03-27T15:31:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21878"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/12d0e39916705b68d2d8ba20a8e35d1d27afc260"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1b267e1b87d52b16e7dfcc7ab2ab760f6f8f9ca9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/545b563eb00d0576775da4011b3f7ffefc9e8c60"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/846e371631c57365eeb89e5db1ab0f344169af93"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dd1998e243f5fa25d348a384ba0b6c84d980f2b2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e3aea1dba97d31eceed7b622000af0406988b9c8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f32d7b4dc6e791523c70e83049645dcba2a2aa33"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6HVC-J4M8-JP74
Vulnerability from github – Published: 2022-11-29 00:30 – Updated: 2025-04-14 18:31A flaw was found in the Linux kernel's Layer 2 Tunneling Protocol (L2TP). A missing lock when clearing sk_user_data can lead to a race condition and NULL pointer dereference. A local user could use this flaw to potentially crash the system causing a denial of service.
{
"affected": [],
"aliases": [
"CVE-2022-4129"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-11-28T22:15:00Z",
"severity": "MODERATE"
},
"details": "A flaw was found in the Linux kernel\u0027s Layer 2 Tunneling Protocol (L2TP). A missing lock when clearing sk_user_data can lead to a race condition and NULL pointer dereference. A local user could use this flaw to potentially crash the system causing a denial of service.",
"id": "GHSA-6hvc-j4m8-jp74",
"modified": "2025-04-14T18:31:41Z",
"published": "2022-11-29T00:30:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4129"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/7X5SPXMXXFANDASPCKER2JIQO2F3UHCP"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/AM5KFIE6JNZXHBA5A2KYDZAT3MEX2B67"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JOKXNIM2R4FQCDRQV67UMAY6EBC72QFG"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/7X5SPXMXXFANDASPCKER2JIQO2F3UHCP"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/AM5KFIE6JNZXHBA5A2KYDZAT3MEX2B67"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JOKXNIM2R4FQCDRQV67UMAY6EBC72QFG"
},
{
"type": "WEB",
"url": "https://lore.kernel.org/all/20221114191619.124659-1-jakub%40cloudflare.com/t"
},
{
"type": "WEB",
"url": "https://lore.kernel.org/all/20221114191619.124659-1-jakub@cloudflare.com/t"
},
{
"type": "WEB",
"url": "https://lore.kernel.org/netdev/20221121085426.21315-1-jakub%40cloudflare.com/t"
},
{
"type": "WEB",
"url": "https://lore.kernel.org/netdev/20221121085426.21315-1-jakub@cloudflare.com/t"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
Strategy: Libraries or Frameworks
Use industry standard APIs to implement locking mechanism.
CAPEC-25: Forced Deadlock
The adversary triggers and exploits a deadlock condition in the target software to cause a denial of service. A deadlock can occur when two or more competing actions are waiting for each other to finish, and thus neither ever does. Deadlock conditions can be difficult to detect.
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-27: Leveraging Race Conditions via Symbolic Links
This attack leverages the use of symbolic links (Symlinks) in order to write to sensitive files. An attacker can create a Symlink link to a target file not otherwise accessible to them. When the privileged program tries to create a temporary file with the same name as the Symlink link, it will actually write to the target file pointed to by the attackers' Symlink link. If the attacker can insert malicious content in the temporary file they will be writing to the sensitive file by using the Symlink. The race occurs because the system checks if the temporary file exists, then creates the file. The attacker would typically create the Symlink during the interval between the check and the creation of the temporary file.