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.
713 vulnerabilities reference this CWE, most recent first.
GHSA-684M-V6V9-3H53
Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2024-06-03 18:55In the Linux kernel, the following vulnerability has been resolved:
r8169: fix LED-related deadlock on module removal
Binding devm_led_classdev_register() to the netdev is problematic because on module removal we get a RTNL-related deadlock. Fix this by avoiding the device-managed LED functions.
Note: We can safely call led_classdev_unregister() for a LED even if registering it failed, because led_classdev_unregister() detects this and is a no-op in this case.
{
"affected": [],
"aliases": [
"CVE-2024-27021"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T06:15:20Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nr8169: fix LED-related deadlock on module removal\n\nBinding devm_led_classdev_register() to the netdev is problematic\nbecause on module removal we get a RTNL-related deadlock. Fix this\nby avoiding the device-managed LED functions.\n\nNote: We can safely call led_classdev_unregister() for a LED even\nif registering it failed, because led_classdev_unregister() detects\nthis and is a no-op in this case.",
"id": "GHSA-684m-v6v9-3h53",
"modified": "2024-06-03T18:55:52Z",
"published": "2024-05-01T06:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27021"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/19fa4f2a85d777a8052e869c1b892a2f7556569d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/53d986f39acd8ea11c9e460732bfa5add66360d9"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW"
}
],
"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-68J8-P6JF-3M4X
Vulnerability from github – Published: 2025-03-18 21:31 – Updated: 2025-03-18 21:31In the Linux kernel, the following vulnerability has been resolved:
powerpc/set_memory: Avoid spinlock recursion in change_page_attr()
Commit 1f9ad21c3b38 ("powerpc/mm: Implement set_memory() routines") included a spin_lock() to change_page_attr() in order to safely perform the three step operations. But then commit 9f7853d7609d ("powerpc/mm: Fix set_memory_*() against concurrent accesses") modify it to use pte_update() and do the operation safely against concurrent access.
In the meantime, Maxime reported some spinlock recursion.
[ 15.351649] BUG: spinlock recursion on CPU#0, kworker/0:2/217 [ 15.357540] lock: init_mm+0x3c/0x420, .magic: dead4ead, .owner: kworker/0:2/217, .owner_cpu: 0 [ 15.366563] CPU: 0 PID: 217 Comm: kworker/0:2 Not tainted 5.15.0+ #523 [ 15.373350] Workqueue: events do_free_init [ 15.377615] Call Trace: [ 15.380232] [e4105ac0] [800946a4] do_raw_spin_lock+0xf8/0x120 (unreliable) [ 15.387340] [e4105ae0] [8001f4ec] change_page_attr+0x40/0x1d4 [ 15.393413] [e4105b10] [801424e0] __apply_to_page_range+0x164/0x310 [ 15.400009] [e4105b60] [80169620] free_pcp_prepare+0x1e4/0x4a0 [ 15.406045] [e4105ba0] [8016c5a0] free_unref_page+0x40/0x2b8 [ 15.411979] [e4105be0] [8018724c] kasan_depopulate_vmalloc_pte+0x6c/0x94 [ 15.418989] [e4105c00] [801424e0] __apply_to_page_range+0x164/0x310 [ 15.425451] [e4105c50] [80187834] kasan_release_vmalloc+0xbc/0x134 [ 15.431898] [e4105c70] [8015f7a8] __purge_vmap_area_lazy+0x4e4/0xdd8 [ 15.438560] [e4105d30] [80160d10] _vm_unmap_aliases.part.0+0x17c/0x24c [ 15.445283] [e4105d60] [801642d0] __vunmap+0x2f0/0x5c8 [ 15.450684] [e4105db0] [800e32d0] do_free_init+0x68/0x94 [ 15.456181] [e4105dd0] [8005d094] process_one_work+0x4bc/0x7b8 [ 15.462283] [e4105e90] [8005d614] worker_thread+0x284/0x6e8 [ 15.468227] [e4105f00] [8006aaec] kthread+0x1f0/0x210 [ 15.473489] [e4105f40] [80017148] ret_from_kernel_thread+0x14/0x1c
Remove the read / modify / write sequence to make the operation atomic and remove the spin_lock() in change_page_attr().
To do the operation atomically, we can't use pte modification helpers anymore. Because all platforms have different combination of bits, it is not easy to use those bits directly. But all have the PAGE_KERNEL{RO/ROX/RW/RWX} set of flags. All we need it to compare two sets to know which bits are set or cleared.
For instance, by comparing _PAGE_KERNEL_ROX and _PAGE_KERNEL_RO you know which bit gets cleared and which bit get set when changing exec permission.
{
"affected": [],
"aliases": [
"CVE-2021-47632"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T06:37:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/set_memory: Avoid spinlock recursion in change_page_attr()\n\nCommit 1f9ad21c3b38 (\"powerpc/mm: Implement set_memory() routines\")\nincluded a spin_lock() to change_page_attr() in order to\nsafely perform the three step operations. But then\ncommit 9f7853d7609d (\"powerpc/mm: Fix set_memory_*() against\nconcurrent accesses\") modify it to use pte_update() and do\nthe operation safely against concurrent access.\n\nIn the meantime, Maxime reported some spinlock recursion.\n\n[ 15.351649] BUG: spinlock recursion on CPU#0, kworker/0:2/217\n[ 15.357540] lock: init_mm+0x3c/0x420, .magic: dead4ead, .owner: kworker/0:2/217, .owner_cpu: 0\n[ 15.366563] CPU: 0 PID: 217 Comm: kworker/0:2 Not tainted 5.15.0+ #523\n[ 15.373350] Workqueue: events do_free_init\n[ 15.377615] Call Trace:\n[ 15.380232] [e4105ac0] [800946a4] do_raw_spin_lock+0xf8/0x120 (unreliable)\n[ 15.387340] [e4105ae0] [8001f4ec] change_page_attr+0x40/0x1d4\n[ 15.393413] [e4105b10] [801424e0] __apply_to_page_range+0x164/0x310\n[ 15.400009] [e4105b60] [80169620] free_pcp_prepare+0x1e4/0x4a0\n[ 15.406045] [e4105ba0] [8016c5a0] free_unref_page+0x40/0x2b8\n[ 15.411979] [e4105be0] [8018724c] kasan_depopulate_vmalloc_pte+0x6c/0x94\n[ 15.418989] [e4105c00] [801424e0] __apply_to_page_range+0x164/0x310\n[ 15.425451] [e4105c50] [80187834] kasan_release_vmalloc+0xbc/0x134\n[ 15.431898] [e4105c70] [8015f7a8] __purge_vmap_area_lazy+0x4e4/0xdd8\n[ 15.438560] [e4105d30] [80160d10] _vm_unmap_aliases.part.0+0x17c/0x24c\n[ 15.445283] [e4105d60] [801642d0] __vunmap+0x2f0/0x5c8\n[ 15.450684] [e4105db0] [800e32d0] do_free_init+0x68/0x94\n[ 15.456181] [e4105dd0] [8005d094] process_one_work+0x4bc/0x7b8\n[ 15.462283] [e4105e90] [8005d614] worker_thread+0x284/0x6e8\n[ 15.468227] [e4105f00] [8006aaec] kthread+0x1f0/0x210\n[ 15.473489] [e4105f40] [80017148] ret_from_kernel_thread+0x14/0x1c\n\nRemove the read / modify / write sequence to make the operation atomic\nand remove the spin_lock() in change_page_attr().\n\nTo do the operation atomically, we can\u0027t use pte modification helpers\nanymore. Because all platforms have different combination of bits, it\nis not easy to use those bits directly. But all have the\n_PAGE_KERNEL_{RO/ROX/RW/RWX} set of flags. All we need it to compare\ntwo sets to know which bits are set or cleared.\n\nFor instance, by comparing _PAGE_KERNEL_ROX and _PAGE_KERNEL_RO you\nknow which bit gets cleared and which bit get set when changing exec\npermission.",
"id": "GHSA-68j8-p6jf-3m4x",
"modified": "2025-03-18T21:31:58Z",
"published": "2025-03-18T21:31:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47632"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6def4eaf0391f24be541633a954c0e4876858b1e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6ebe5ca2cbe438a688f2ae238ef5a0b0b5f3468a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/96917107e67846f1d959ed03be281048efad14c5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a4c182ecf33584b9b2d1aa9dad073014a504c01f"
}
],
"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-69HW-3R8X-9JF6
Vulnerability from github – Published: 2025-05-20 18:30 – Updated: 2025-12-19 18:31In the Linux kernel, the following vulnerability has been resolved:
ftrace: Add cond_resched() to ftrace_graph_set_hash()
When the kernel contains a large number of functions that can be traced, the loop in ftrace_graph_set_hash() may take a lot of time to execute. This may trigger the softlockup watchdog.
Add cond_resched() within the loop to allow the kernel to remain responsive even when processing a large number of functions.
This matches the cond_resched() that is used in other locations of the code that iterates over all functions that can be traced.
{
"affected": [],
"aliases": [
"CVE-2025-37940"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-20T16:15:31Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Add cond_resched() to ftrace_graph_set_hash()\n\nWhen the kernel contains a large number of functions that can be traced,\nthe loop in ftrace_graph_set_hash() may take a lot of time to execute.\nThis may trigger the softlockup watchdog.\n\nAdd cond_resched() within the loop to allow the kernel to remain\nresponsive even when processing a large number of functions.\n\nThis matches the cond_resched() that is used in other locations of the\ncode that iterates over all functions that can be traced.",
"id": "GHSA-69hw-3r8x-9jf6",
"modified": "2025-12-19T18:31:05Z",
"published": "2025-05-20T18:30:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37940"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1fce9574b9d515bcb8a75379a8053e18602424e3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/42ea22e754ba4f2b86f8760ca27f6f71da2d982c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4429535acab750d963fdc3dfcc9e0eee42f4d599"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5d336ac215e5c76e43ef4bca9ba699835e53e2fd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/618655d54c5f8af5d57b77491d08c0f0ff77d114"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/72be43ff061a889c6ee648a330a42486cafa15a6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8dd7d7280357596ba63dfdb4c1725d9dd24bd42a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dd38803c9088b848c6b56f4f6d7efc4497bfde61"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e5b4ae6f01d4a510d5725eca7254519a1093920d"
},
{
"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-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"
}
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.