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-96WF-6GFH-Q6GV
Vulnerability from github – Published: 2025-09-11 18:35 – Updated: 2025-11-25 18:32In the Linux kernel, the following vulnerability has been resolved:
dm: dm-crypt: Do not partially accept write BIOs with zoned targets
Read and write operations issued to a dm-crypt target may be split according to the dm-crypt internal limits defined by the max_read_size and max_write_size module parameters (default is 128 KB). The intent is to improve processing time of large BIOs by splitting them into smaller operations that can be parallelized on different CPUs.
For zoned dm-crypt targets, this BIO splitting is still done but without the parallel execution to ensure that the issuing order of write operations to the underlying devices remains sequential. However, the splitting itself causes other problems:
1) Since dm-crypt relies on the block layer zone write plugging to handle zone append emulation using regular write operations, the reminder of a split write BIO will always be plugged into the target zone write plugged. Once the on-going write BIO finishes, this reminder BIO is unplugged and issued from the zone write plug work. If this reminder BIO itself needs to be split, the reminder will be re-issued and plugged again, but that causes a call to a blk_queue_enter(), which may block if a queue freeze operation was initiated. This results in a deadlock as DM submission still holds BIOs that the queue freeze side is waiting for.
2) dm-crypt relies on the emulation done by the block layer using regular write operations for processing zone append operations. This still requires to properly return the written sector as the BIO sector of the original BIO. However, this can be done correctly only and only if there is a single clone BIO used for processing the original zone append operation issued by the user. If the size of a zone append operation is larger than dm-crypt max_write_size, then the orginal BIO will be split and processed as a chain of regular write operations. Such chaining result in an incorrect written sector being returned to the zone append issuer using the original BIO sector. This in turn results in file system data corruptions using xfs or btrfs.
Fix this by modifying get_max_request_size() to always return the size of the BIO to avoid it being split with dm_accpet_partial_bio() in crypt_map(). get_max_request_size() is renamed to get_max_request_sectors() to clarify the unit of the value returned and its interface is changed to take a struct dm_target pointer and a pointer to the struct bio being processed. In addition to this change, to ensure that crypt_alloc_buffer() works correctly, set the dm-crypt device max_hw_sectors limit to be at most BIO_MAX_VECS << PAGE_SECTORS_SHIFT (1 MB with a 4KB page architecture). This forces DM core to split write BIOs before passing them to crypt_map(), and thus guaranteeing that dm-crypt can always accept an entire write BIO without needing to split it.
This change does not have any effect on the read path of dm-crypt. Read operations can still be split and the BIO fragments processed in parallel. There is also no impact on the performance of the write path given that all zone write BIOs were already processed inline instead of in parallel.
This change also does not affect in any way regular dm-crypt block devices.
{
"affected": [],
"aliases": [
"CVE-2025-39791"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-11T17:15:45Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm: dm-crypt: Do not partially accept write BIOs with zoned targets\n\nRead and write operations issued to a dm-crypt target may be split\naccording to the dm-crypt internal limits defined by the max_read_size\nand max_write_size module parameters (default is 128 KB). The intent is\nto improve processing time of large BIOs by splitting them into smaller\noperations that can be parallelized on different CPUs.\n\nFor zoned dm-crypt targets, this BIO splitting is still done but without\nthe parallel execution to ensure that the issuing order of write\noperations to the underlying devices remains sequential. However, the\nsplitting itself causes other problems:\n\n1) Since dm-crypt relies on the block layer zone write plugging to\n handle zone append emulation using regular write operations, the\n reminder of a split write BIO will always be plugged into the target\n zone write plugged. Once the on-going write BIO finishes, this\n reminder BIO is unplugged and issued from the zone write plug work.\n If this reminder BIO itself needs to be split, the reminder will be\n re-issued and plugged again, but that causes a call to a\n blk_queue_enter(), which may block if a queue freeze operation was\n initiated. This results in a deadlock as DM submission still holds\n BIOs that the queue freeze side is waiting for.\n\n2) dm-crypt relies on the emulation done by the block layer using\n regular write operations for processing zone append operations. This\n still requires to properly return the written sector as the BIO\n sector of the original BIO. However, this can be done correctly only\n and only if there is a single clone BIO used for processing the\n original zone append operation issued by the user. If the size of a\n zone append operation is larger than dm-crypt max_write_size, then\n the orginal BIO will be split and processed as a chain of regular\n write operations. Such chaining result in an incorrect written sector\n being returned to the zone append issuer using the original BIO\n sector. This in turn results in file system data corruptions using\n xfs or btrfs.\n\nFix this by modifying get_max_request_size() to always return the size\nof the BIO to avoid it being split with dm_accpet_partial_bio() in\ncrypt_map(). get_max_request_size() is renamed to\nget_max_request_sectors() to clarify the unit of the value returned\nand its interface is changed to take a struct dm_target pointer and a\npointer to the struct bio being processed. In addition to this change,\nto ensure that crypt_alloc_buffer() works correctly, set the dm-crypt\ndevice max_hw_sectors limit to be at most\nBIO_MAX_VECS \u003c\u003c PAGE_SECTORS_SHIFT (1 MB with a 4KB page architecture).\nThis forces DM core to split write BIOs before passing them to\ncrypt_map(), and thus guaranteeing that dm-crypt can always accept an\nentire write BIO without needing to split it.\n\nThis change does not have any effect on the read path of dm-crypt. Read\noperations can still be split and the BIO fragments processed in\nparallel. There is also no impact on the performance of the write path\ngiven that all zone write BIOs were already processed inline instead of\nin parallel.\n\nThis change also does not affect in any way regular dm-crypt block\ndevices.",
"id": "GHSA-96wf-6gfh-q6gv",
"modified": "2025-11-25T18:32:20Z",
"published": "2025-09-11T18:35:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39791"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/52a2c4c60470352acf9cde7a2dfa661c1e67e796"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8864616719b6bbf92356bc89ff544b0cd484c656"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e549663849e5bb3b985dc2d293069f0d9747ae72"
}
],
"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-975C-W82Q-MXHV
Vulnerability from github – Published: 2024-11-08 06:30 – Updated: 2026-05-12 15:30In the Linux kernel, the following vulnerability has been resolved:
posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()
If get_clock_desc() succeeds, it calls fget() for the clockid's fd, and get the clk->rwsem read lock, so the error path should release the lock to make the lock balance and fput the clockid's fd to make the refcount balance and release the fd related resource.
However the below commit left the error path locked behind resulting in unbalanced locking. Check timespec64_valid_strict() before get_clock_desc() to fix it, because the "ts" is not changed after that.
[pabeni@redhat.com: fixed commit message typo]
{
"affected": [],
"aliases": [
"CVE-2024-50210"
],
"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\nposix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()\n\nIf get_clock_desc() succeeds, it calls fget() for the clockid\u0027s fd,\nand get the clk-\u003erwsem read lock, so the error path should release\nthe lock to make the lock balance and fput the clockid\u0027s fd to make\nthe refcount balance and release the fd related resource.\n\nHowever the below commit left the error path locked behind resulting in\nunbalanced locking. Check timespec64_valid_strict() before\nget_clock_desc() to fix it, because the \"ts\" is not changed\nafter that.\n\n[pabeni@redhat.com: fixed commit message typo]",
"id": "GHSA-975c-w82q-mxhv",
"modified": "2026-05-12T15:30:40Z",
"published": "2024-11-08T06:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50210"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1ba33b327c3f88a7baee598979d73ab5b44d41cc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5f063bbf1ee6b01611c016b54e050a41506eb794"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6e62807c7fbb3c758d233018caf94dfea9c65dbd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a8219446b95a859488feaade674d13f9efacfa32"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b27330128eca25179637c1816d5a72d6cc408c66"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c7fcfdba35abc9f39b83080c2bce398dad13a943"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d005400262ddaf1ca1666bbcd1acf42fe81d57ce"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e56e0ec1b79f5a6272c6e78b36e9d593aa0449af"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9889-58R3-P8H2
Vulnerability from github – Published: 2025-05-20 18:30 – Updated: 2025-12-16 21:30In the Linux kernel, the following vulnerability has been resolved:
iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifo
Prevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty.
{
"affected": [],
"aliases": [
"CVE-2025-37969"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-20T17:15:47Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\niio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifo\n\nPrevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop in\ncase pattern_len is equal to zero and the device FIFO is not empty.",
"id": "GHSA-9889-58r3-p8h2",
"modified": "2025-12-16T21:30:49Z",
"published": "2025-05-20T18:30:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37969"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/16857370b3a30663515956b3bd27f3def6a2cf06"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/35b8c0a284983b71d92d082c54b7eb655ed4194f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4db7d923a8c298788181b796f71adf6ca499f966"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/76727a1d81afde77d21ea8feaeb12d34605be6f4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8114ef86e2058e2554111b793596f17bee23fa15"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9ce662851380fe2018e36e15c0bdcb1ad177ed95"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9ddb4cf2192c213e4dba1733bbcdc94cf6d85bf7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dadf9116108315f2eb14c7415c7805f392c476b4"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.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-9933-F4M5-7V96
Vulnerability from github – Published: 2025-03-27 18:31 – Updated: 2025-04-15 21:31In the Linux kernel, the following vulnerability has been resolved:
net: enetc: avoid deadlock in enetc_tx_onestep_tstamp()
This lockdep splat says it better than I could:
================================ WARNING: inconsistent lock state 6.2.0-rc2-07010-ga9b9500ffaac-dirty #967 Not tainted
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. kworker/1:3/179 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff3ec4036ce098 (_xmit_ETHER#2){+.?.}-{3:3}, at: netif_freeze_queues+0x5c/0xc0 {IN-SOFTIRQ-W} state was registered at: _raw_spin_lock+0x5c/0xc0 sch_direct_xmit+0x148/0x37c __dev_queue_xmit+0x528/0x111c ip6_finish_output2+0x5ec/0xb7c ip6_finish_output+0x240/0x3f0 ip6_output+0x78/0x360 ndisc_send_skb+0x33c/0x85c ndisc_send_rs+0x54/0x12c addrconf_rs_timer+0x154/0x260 call_timer_fn+0xb8/0x3a0 __run_timers.part.0+0x214/0x26c run_timer_softirq+0x3c/0x74 __do_softirq+0x14c/0x5d8 _dosoftirq+0x10/0x20 call_on_irq_stack+0x2c/0x5c do_softirq_own_stack+0x1c/0x30 irq_exit_rcu+0x168/0x1a0 irq_exit_rcu+0x10/0x40 el1_interrupt+0x38/0x64 irq event stamp: 7825 hardirqs last enabled at (7825): [] exit_to_kernel_mode+0x34/0x130 hardirqs last disabled at (7823): [] __do_softirq+0x550/0x5d8 softirqs last enabled at (7824): [] __do_softirq+0x46c/0x5d8 softirqs last disabled at (7811): [] ____do_softirq+0x10/0x20
other info that might help us debug this: Possible unsafe locking scenario:
CPU0
----
lock(_xmit_ETHER#2); lock(_xmit_ETHER#2);
*** DEADLOCK ***
3 locks held by kworker/1:3/179: #0: ffff3ec400004748 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0 #1: ffff80000a0bbdc8 ((work_completion)(&priv->tx_onestep_tstamp)){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0 #2: ffff3ec4036cd438 (&dev->tx_global_lock){+.+.}-{3:3}, at: netif_tx_lock+0x1c/0x34
Workqueue: events enetc_tx_onestep_tstamp Call trace: print_usage_bug.part.0+0x208/0x22c mark_lock+0x7f0/0x8b0 __lock_acquire+0x7c4/0x1ce0 lock_acquire.part.0+0xe0/0x220 lock_acquire+0x68/0x84 _raw_spin_lock+0x5c/0xc0 netif_freeze_queues+0x5c/0xc0 netif_tx_lock+0x24/0x34 enetc_tx_onestep_tstamp+0x20/0x100 process_one_work+0x28c/0x6c0 worker_thread+0x74/0x450 kthread+0x118/0x11c
but I'll say it anyway: the enetc_tx_onestep_tstamp() work item runs in process context, therefore with softirqs enabled (i.o.w., it can be interrupted by a softirq). If we hold the netif_tx_lock() when there is an interrupt, and the NET_TX softirq then gets scheduled, this will take the netif_tx_lock() a second time and deadlock the kernel.
To solve this, use netif_tx_lock_bh(), which blocks softirqs from running.
{
"affected": [],
"aliases": [
"CVE-2023-53022"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-27T17:15:51Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: enetc: avoid deadlock in enetc_tx_onestep_tstamp()\n\nThis lockdep splat says it better than I could:\n\n================================\nWARNING: inconsistent lock state\n6.2.0-rc2-07010-ga9b9500ffaac-dirty #967 Not tainted\n--------------------------------\ninconsistent {IN-SOFTIRQ-W} -\u003e {SOFTIRQ-ON-W} usage.\nkworker/1:3/179 [HC0[0]:SC0[0]:HE1:SE1] takes:\nffff3ec4036ce098 (_xmit_ETHER#2){+.?.}-{3:3}, at: netif_freeze_queues+0x5c/0xc0\n{IN-SOFTIRQ-W} state was registered at:\n _raw_spin_lock+0x5c/0xc0\n sch_direct_xmit+0x148/0x37c\n __dev_queue_xmit+0x528/0x111c\n ip6_finish_output2+0x5ec/0xb7c\n ip6_finish_output+0x240/0x3f0\n ip6_output+0x78/0x360\n ndisc_send_skb+0x33c/0x85c\n ndisc_send_rs+0x54/0x12c\n addrconf_rs_timer+0x154/0x260\n call_timer_fn+0xb8/0x3a0\n __run_timers.part.0+0x214/0x26c\n run_timer_softirq+0x3c/0x74\n __do_softirq+0x14c/0x5d8\n ____do_softirq+0x10/0x20\n call_on_irq_stack+0x2c/0x5c\n do_softirq_own_stack+0x1c/0x30\n __irq_exit_rcu+0x168/0x1a0\n irq_exit_rcu+0x10/0x40\n el1_interrupt+0x38/0x64\nirq event stamp: 7825\nhardirqs last enabled at (7825): [\u003cffffdf1f7200cae4\u003e] exit_to_kernel_mode+0x34/0x130\nhardirqs last disabled at (7823): [\u003cffffdf1f708105f0\u003e] __do_softirq+0x550/0x5d8\nsoftirqs last enabled at (7824): [\u003cffffdf1f7081050c\u003e] __do_softirq+0x46c/0x5d8\nsoftirqs last disabled at (7811): [\u003cffffdf1f708166e0\u003e] ____do_softirq+0x10/0x20\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(_xmit_ETHER#2);\n \u003cInterrupt\u003e\n lock(_xmit_ETHER#2);\n\n *** DEADLOCK ***\n\n3 locks held by kworker/1:3/179:\n #0: ffff3ec400004748 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0\n #1: ffff80000a0bbdc8 ((work_completion)(\u0026priv-\u003etx_onestep_tstamp)){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0\n #2: ffff3ec4036cd438 (\u0026dev-\u003etx_global_lock){+.+.}-{3:3}, at: netif_tx_lock+0x1c/0x34\n\nWorkqueue: events enetc_tx_onestep_tstamp\nCall trace:\n print_usage_bug.part.0+0x208/0x22c\n mark_lock+0x7f0/0x8b0\n __lock_acquire+0x7c4/0x1ce0\n lock_acquire.part.0+0xe0/0x220\n lock_acquire+0x68/0x84\n _raw_spin_lock+0x5c/0xc0\n netif_freeze_queues+0x5c/0xc0\n netif_tx_lock+0x24/0x34\n enetc_tx_onestep_tstamp+0x20/0x100\n process_one_work+0x28c/0x6c0\n worker_thread+0x74/0x450\n kthread+0x118/0x11c\n\nbut I\u0027ll say it anyway: the enetc_tx_onestep_tstamp() work item runs in\nprocess context, therefore with softirqs enabled (i.o.w., it can be\ninterrupted by a softirq). If we hold the netif_tx_lock() when there is\nan interrupt, and the NET_TX softirq then gets scheduled, this will take\nthe netif_tx_lock() a second time and deadlock the kernel.\n\nTo solve this, use netif_tx_lock_bh(), which blocks softirqs from\nrunning.",
"id": "GHSA-9933-f4m5-7v96",
"modified": "2025-04-15T21:31:30Z",
"published": "2025-03-27T18:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53022"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3c463721a73bdb57a913e0d3124677a3758886fc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8232e5a84d25a84a5cbda0f241a00793fb6eb608"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e893dced1a18e77b1262f5c10169413f0ece0da7"
}
],
"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-99GR-CW2X-89QP
Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-15 15:30In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix mismatched unlock for DMUB HW lock in HWSS fast path
[Why] The evaluation for whether we need to use the DMUB HW lock isn't the same as whether we need to unlock which results in a hang when the fast path is used for ASIC without FAMS support.
[How] Store a flag that indicates whether we should use the lock and use that same flag to specify whether unlocking is needed.
{
"affected": [],
"aliases": [
"CVE-2026-43305"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-08T14:16:37Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix mismatched unlock for DMUB HW lock in HWSS fast path\n\n[Why]\nThe evaluation for whether we need to use the DMUB HW lock isn\u0027t the\nsame as whether we need to unlock which results in a hang when the\nfast path is used for ASIC without FAMS support.\n\n[How]\nStore a flag that indicates whether we should use the lock and use\nthat same flag to specify whether unlocking is needed.",
"id": "GHSA-99gr-cw2x-89qp",
"modified": "2026-05-15T15:30:33Z",
"published": "2026-05-08T15:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43305"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4e387ad67efb100b645630ffbce7716786f52283"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/af3303970da5ce5bfe6dffdd07f38f42aad603e0"
}
],
"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-99MJ-3X29-5MM3
Vulnerability from github – Published: 2024-05-17 15:31 – Updated: 2025-01-10 18:31In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix deadlock while reading mqd from debugfs
An errant disk backup on my desktop got into debugfs and triggered the following deadlock scenario in the amdgpu debugfs files. The machine also hard-resets immediately after those lines are printed (although I wasn't able to reproduce that part when reading by hand):
[ 1318.016074][ T1082] ====================================================== [ 1318.016607][ T1082] WARNING: possible circular locking dependency detected [ 1318.017107][ T1082] 6.8.0-rc7-00015-ge0c8221b72c0 #17 Not tainted [ 1318.017598][ T1082] ------------------------------------------------------ [ 1318.018096][ T1082] tar/1082 is trying to acquire lock: [ 1318.018585][ T1082] ffff98c44175d6a0 (&mm->mmap_lock){++++}-{3:3}, at: __might_fault+0x40/0x80 [ 1318.019084][ T1082] [ 1318.019084][ T1082] but task is already holding lock: [ 1318.020052][ T1082] ffff98c4c13f55f8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu] [ 1318.020607][ T1082] [ 1318.020607][ T1082] which lock already depends on the new lock. [ 1318.020607][ T1082] [ 1318.022081][ T1082] [ 1318.022081][ T1082] the existing dependency chain (in reverse order) is: [ 1318.023083][ T1082] [ 1318.023083][ T1082] -> #2 (reservation_ww_class_mutex){+.+.}-{3:3}: [ 1318.024114][ T1082] __ww_mutex_lock.constprop.0+0xe0/0x12f0 [ 1318.024639][ T1082] ww_mutex_lock+0x32/0x90 [ 1318.025161][ T1082] dma_resv_lockdep+0x18a/0x330 [ 1318.025683][ T1082] do_one_initcall+0x6a/0x350 [ 1318.026210][ T1082] kernel_init_freeable+0x1a3/0x310 [ 1318.026728][ T1082] kernel_init+0x15/0x1a0 [ 1318.027242][ T1082] ret_from_fork+0x2c/0x40 [ 1318.027759][ T1082] ret_from_fork_asm+0x11/0x20 [ 1318.028281][ T1082] [ 1318.028281][ T1082] -> #1 (reservation_ww_class_acquire){+.+.}-{0:0}: [ 1318.029297][ T1082] dma_resv_lockdep+0x16c/0x330 [ 1318.029790][ T1082] do_one_initcall+0x6a/0x350 [ 1318.030263][ T1082] kernel_init_freeable+0x1a3/0x310 [ 1318.030722][ T1082] kernel_init+0x15/0x1a0 [ 1318.031168][ T1082] ret_from_fork+0x2c/0x40 [ 1318.031598][ T1082] ret_from_fork_asm+0x11/0x20 [ 1318.032011][ T1082] [ 1318.032011][ T1082] -> #0 (&mm->mmap_lock){++++}-{3:3}: [ 1318.032778][ T1082] __lock_acquire+0x14bf/0x2680 [ 1318.033141][ T1082] lock_acquire+0xcd/0x2c0 [ 1318.033487][ T1082] __might_fault+0x58/0x80 [ 1318.033814][ T1082] amdgpu_debugfs_mqd_read+0x103/0x250 [amdgpu] [ 1318.034181][ T1082] full_proxy_read+0x55/0x80 [ 1318.034487][ T1082] vfs_read+0xa7/0x360 [ 1318.034788][ T1082] ksys_read+0x70/0xf0 [ 1318.035085][ T1082] do_syscall_64+0x94/0x180 [ 1318.035375][ T1082] entry_SYSCALL_64_after_hwframe+0x46/0x4e [ 1318.035664][ T1082] [ 1318.035664][ T1082] other info that might help us debug this: [ 1318.035664][ T1082] [ 1318.036487][ T1082] Chain exists of: [ 1318.036487][ T1082] &mm->mmap_lock --> reservation_ww_class_acquire --> reservation_ww_class_mutex [ 1318.036487][ T1082] [ 1318.037310][ T1082] Possible unsafe locking scenario: [ 1318.037310][ T1082] [ 1318.037838][ T1082] CPU0 CPU1 [ 1318.038101][ T1082] ---- ---- [ 1318.038350][ T1082] lock(reservation_ww_class_mutex); [ 1318.038590][ T1082] lock(reservation_ww_class_acquire); [ 1318.038839][ T1082] lock(reservation_ww_class_mutex); [ 1318.039083][ T1082] rlock(&mm->mmap_lock); [ 1318.039328][ T1082] [ 1318.039328][ T1082] *** DEADLOCK *** [ 1318.039328][ T1082] [ 1318.040029][ T1082] 1 lock held by tar/1082: [ 1318.040259][ T1082] #0: ffff98c4c13f55f8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu] [ 1318.040560][ T1082] [ 1318.040560][ T1082] stack backtrace: [ ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-35795"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-17T14:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: fix deadlock while reading mqd from debugfs\n\nAn errant disk backup on my desktop got into debugfs and triggered the\nfollowing deadlock scenario in the amdgpu debugfs files. The machine\nalso hard-resets immediately after those lines are printed (although I\nwasn\u0027t able to reproduce that part when reading by hand):\n\n[ 1318.016074][ T1082] ======================================================\n[ 1318.016607][ T1082] WARNING: possible circular locking dependency detected\n[ 1318.017107][ T1082] 6.8.0-rc7-00015-ge0c8221b72c0 #17 Not tainted\n[ 1318.017598][ T1082] ------------------------------------------------------\n[ 1318.018096][ T1082] tar/1082 is trying to acquire lock:\n[ 1318.018585][ T1082] ffff98c44175d6a0 (\u0026mm-\u003emmap_lock){++++}-{3:3}, at: __might_fault+0x40/0x80\n[ 1318.019084][ T1082]\n[ 1318.019084][ T1082] but task is already holding lock:\n[ 1318.020052][ T1082] ffff98c4c13f55f8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu]\n[ 1318.020607][ T1082]\n[ 1318.020607][ T1082] which lock already depends on the new lock.\n[ 1318.020607][ T1082]\n[ 1318.022081][ T1082]\n[ 1318.022081][ T1082] the existing dependency chain (in reverse order) is:\n[ 1318.023083][ T1082]\n[ 1318.023083][ T1082] -\u003e #2 (reservation_ww_class_mutex){+.+.}-{3:3}:\n[ 1318.024114][ T1082] __ww_mutex_lock.constprop.0+0xe0/0x12f0\n[ 1318.024639][ T1082] ww_mutex_lock+0x32/0x90\n[ 1318.025161][ T1082] dma_resv_lockdep+0x18a/0x330\n[ 1318.025683][ T1082] do_one_initcall+0x6a/0x350\n[ 1318.026210][ T1082] kernel_init_freeable+0x1a3/0x310\n[ 1318.026728][ T1082] kernel_init+0x15/0x1a0\n[ 1318.027242][ T1082] ret_from_fork+0x2c/0x40\n[ 1318.027759][ T1082] ret_from_fork_asm+0x11/0x20\n[ 1318.028281][ T1082]\n[ 1318.028281][ T1082] -\u003e #1 (reservation_ww_class_acquire){+.+.}-{0:0}:\n[ 1318.029297][ T1082] dma_resv_lockdep+0x16c/0x330\n[ 1318.029790][ T1082] do_one_initcall+0x6a/0x350\n[ 1318.030263][ T1082] kernel_init_freeable+0x1a3/0x310\n[ 1318.030722][ T1082] kernel_init+0x15/0x1a0\n[ 1318.031168][ T1082] ret_from_fork+0x2c/0x40\n[ 1318.031598][ T1082] ret_from_fork_asm+0x11/0x20\n[ 1318.032011][ T1082]\n[ 1318.032011][ T1082] -\u003e #0 (\u0026mm-\u003emmap_lock){++++}-{3:3}:\n[ 1318.032778][ T1082] __lock_acquire+0x14bf/0x2680\n[ 1318.033141][ T1082] lock_acquire+0xcd/0x2c0\n[ 1318.033487][ T1082] __might_fault+0x58/0x80\n[ 1318.033814][ T1082] amdgpu_debugfs_mqd_read+0x103/0x250 [amdgpu]\n[ 1318.034181][ T1082] full_proxy_read+0x55/0x80\n[ 1318.034487][ T1082] vfs_read+0xa7/0x360\n[ 1318.034788][ T1082] ksys_read+0x70/0xf0\n[ 1318.035085][ T1082] do_syscall_64+0x94/0x180\n[ 1318.035375][ T1082] entry_SYSCALL_64_after_hwframe+0x46/0x4e\n[ 1318.035664][ T1082]\n[ 1318.035664][ T1082] other info that might help us debug this:\n[ 1318.035664][ T1082]\n[ 1318.036487][ T1082] Chain exists of:\n[ 1318.036487][ T1082] \u0026mm-\u003emmap_lock --\u003e reservation_ww_class_acquire --\u003e reservation_ww_class_mutex\n[ 1318.036487][ T1082]\n[ 1318.037310][ T1082] Possible unsafe locking scenario:\n[ 1318.037310][ T1082]\n[ 1318.037838][ T1082] CPU0 CPU1\n[ 1318.038101][ T1082] ---- ----\n[ 1318.038350][ T1082] lock(reservation_ww_class_mutex);\n[ 1318.038590][ T1082] lock(reservation_ww_class_acquire);\n[ 1318.038839][ T1082] lock(reservation_ww_class_mutex);\n[ 1318.039083][ T1082] rlock(\u0026mm-\u003emmap_lock);\n[ 1318.039328][ T1082]\n[ 1318.039328][ T1082] *** DEADLOCK ***\n[ 1318.039328][ T1082]\n[ 1318.040029][ T1082] 1 lock held by tar/1082:\n[ 1318.040259][ T1082] #0: ffff98c4c13f55f8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu]\n[ 1318.040560][ T1082]\n[ 1318.040560][ T1082] stack backtrace:\n[\n---truncated---",
"id": "GHSA-99mj-3x29-5mm3",
"modified": "2025-01-10T18:31:37Z",
"published": "2024-05-17T15:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35795"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/197f6d6987c55860f6eea1c93e4f800c59078874"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4687e3c6ee877ee25e57b984eca00be53b9a8db5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8678b1060ae2b75feb60b87e5b75e17374e3c1c5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8b03556da6e576c62664b6cd01809e4a09d53b5b"
}
],
"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-99VR-7HVG-69WF
Vulnerability from github – Published: 2022-12-06 09:30 – Updated: 2022-12-07 18:30In camera driver, there is a possible memory corruption due to improper locking. This could lead to local denial of service in kernel.
{
"affected": [],
"aliases": [
"CVE-2022-39131"
],
"database_specific": {
"cwe_ids": [
"CWE-119",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-06T07:15:00Z",
"severity": "MODERATE"
},
"details": "In camera driver, there is a possible memory corruption due to improper locking. This could lead to local denial of service in kernel.",
"id": "GHSA-99vr-7hvg-69wf",
"modified": "2022-12-07T18:30:28Z",
"published": "2022-12-06T09:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39131"
},
{
"type": "WEB",
"url": "https://www.unisoc.com/en_us/secy/announcementDetail/1599588060988411006"
}
],
"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-9C6C-JQH5-VQV4
Vulnerability from github – Published: 2022-05-24 16:46 – Updated: 2024-04-04 00:49HP has identified a security vulnerability with some versions of Workstation BIOS (UEFI Firmware) where the runtime BIOS code could be tampered with if the TPM is disabled. This vulnerability relates to Workstations whose TPM is disabled by default.
{
"affected": [],
"aliases": [
"CVE-2019-6321"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-05-29T20:29:00Z",
"severity": "HIGH"
},
"details": "HP has identified a security vulnerability with some versions of Workstation BIOS (UEFI Firmware) where the runtime BIOS code could be tampered with if the TPM is disabled. This vulnerability relates to Workstations whose TPM is disabled by default.",
"id": "GHSA-9c6c-jqh5-vqv4",
"modified": "2024-04-04T00:49:32Z",
"published": "2022-05-24T16:46:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-6321"
},
{
"type": "WEB",
"url": "https://support.hp.com/us-en/document/c06318199"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9CC8-5CMC-HCJ3
Vulnerability from github – Published: 2025-04-14 21:32 – Updated: 2025-04-14 21:32In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix sleeping function called from invalid context on RT kernel
When setting bootparams="trace_event=initcall:initcall_start tp_printk=1" in the cmdline, the output_printk() was called, and the spin_lock_irqsave() was called in the atomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel, these locks are replaced with sleepable rt-spinlock, so the stack calltrace will be triggered. Fix it by raw_spin_lock_irqsave when PREEMPT_RT and "trace_event=initcall:initcall_start tp_printk=1" enabled.
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0 preempt_count: 2, expected: 0 RCU nest depth: 0, expected: 0 Preemption disabled at: [] try_to_wake_up+0x7e/0xba0 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.1-rt17+ #19 34c5812404187a875f32bee7977f7367f9679ea7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: dump_stack_lvl+0x60/0x8c dump_stack+0x10/0x12 __might_resched.cold+0x11d/0x155 rt_spin_lock+0x40/0x70 trace_event_buffer_commit+0x2fa/0x4c0 ? map_vsyscall+0x93/0x93 trace_event_raw_event_initcall_start+0xbe/0x110 ? perf_trace_initcall_finish+0x210/0x210 ? probe_sched_wakeup+0x34/0x40 ? ttwu_do_wakeup+0xda/0x310 ? trace_hardirqs_on+0x35/0x170 ? map_vsyscall+0x93/0x93 do_one_initcall+0x217/0x3c0 ? trace_event_raw_event_initcall_level+0x170/0x170 ? push_cpu_stop+0x400/0x400 ? cblist_init_generic+0x241/0x290 kernel_init_freeable+0x1ac/0x347 ? _raw_spin_unlock_irq+0x65/0x80 ? rest_init+0xf0/0xf0 kernel_init+0x1e/0x150 ret_from_fork+0x22/0x30
{
"affected": [],
"aliases": [
"CVE-2022-49322"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix sleeping function called from invalid context on RT kernel\n\nWhen setting bootparams=\"trace_event=initcall:initcall_start tp_printk=1\" in the\ncmdline, the output_printk() was called, and the spin_lock_irqsave() was called in the\natomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel,\nthese locks are replaced with sleepable rt-spinlock, so the stack calltrace will\nbe triggered.\nFix it by raw_spin_lock_irqsave when PREEMPT_RT and \"trace_event=initcall:initcall_start\ntp_printk=1\" enabled.\n\n BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46\n in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0\n preempt_count: 2, expected: 0\n RCU nest depth: 0, expected: 0\n Preemption disabled at:\n [\u003cffffffff8992303e\u003e] try_to_wake_up+0x7e/0xba0\n CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.1-rt17+ #19 34c5812404187a875f32bee7977f7367f9679ea7\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014\n Call Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x60/0x8c\n dump_stack+0x10/0x12\n __might_resched.cold+0x11d/0x155\n rt_spin_lock+0x40/0x70\n trace_event_buffer_commit+0x2fa/0x4c0\n ? map_vsyscall+0x93/0x93\n trace_event_raw_event_initcall_start+0xbe/0x110\n ? perf_trace_initcall_finish+0x210/0x210\n ? probe_sched_wakeup+0x34/0x40\n ? ttwu_do_wakeup+0xda/0x310\n ? trace_hardirqs_on+0x35/0x170\n ? map_vsyscall+0x93/0x93\n do_one_initcall+0x217/0x3c0\n ? trace_event_raw_event_initcall_level+0x170/0x170\n ? push_cpu_stop+0x400/0x400\n ? cblist_init_generic+0x241/0x290\n kernel_init_freeable+0x1ac/0x347\n ? _raw_spin_unlock_irq+0x65/0x80\n ? rest_init+0xf0/0xf0\n kernel_init+0x1e/0x150\n ret_from_fork+0x22/0x30\n \u003c/TASK\u003e",
"id": "GHSA-9cc8-5cmc-hcj3",
"modified": "2025-04-14T21:32:22Z",
"published": "2025-04-14T21:32:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49322"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/12025abdc8539ed9d5014e2d647a3fd1bd3de5cd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1788e6dbb61286215442b1af99e51405a6206762"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/40f9fde06b25884baa0c4bd138b909a9b67218b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/43bfc4dccc416c964b53cbdc430e814f8b6f770b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/48c6ee7d6c614f09b2c8553a95eefef6ecf196e0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9abf3db8bdb63ab545034148ef2118f4d088ca59"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b534640a2c6a8d88168febc82ec6d161184f2ec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be1f323fb9d9b14a505ca22d742d321769454de1"
}
],
"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-9H35-HQFF-9V3W
Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-09-08 09:35In the Linux kernel, the following vulnerability has been resolved:
fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling
A SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in send_sigio() and send_sigurg() when a process group receives a signal.
When FASYNC is configured for a process group (PIDTYPE_PGID), both functions use read_lock(&tasklist_lock) to traverse the task list. However, they are frequently called from softirq context: - send_sigio() via input_inject_event -> kill_fasync - send_sigurg() via tcp_check_urg -> sk_send_sigurg (NET_RX_SOFTIRQ)
The deadlock is caused by the rwlock writer fairness mechanism: 1. CPU 0 (process context) holds read_lock(&tasklist_lock) in do_wait(). 2. CPU 1 (process context) attempts write_lock(&tasklist_lock) in fork() or exit() and spins, which blocks all new readers. 3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception). 4. The softirq calls send_sigurg() and attempts to acquire read_lock(&tasklist_lock), deadlocking because CPU 1 is waiting.
Since PID hashing and do_each_pid_task() traversals are already RCU-protected, the read_lock on tasklist_lock is no longer strictly required for safe traversal. Fix this by replacing tasklist_lock with rcu_read_lock(), aligning the process group signaling path with the single-PID path. This also mitigates a potential remote denial of service vector via TCP URG packets.
Lockdep splat:
WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected [...] Chain exists of: &dev->event_lock --> &f_owner->lock --> tasklist_lock
Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(tasklist_lock); local_irq_disable(); lock(&dev->event_lock); lock(&f_owner->lock); lock(&dev->event_lock);
*** DEADLOCK ***
{
"affected": [],
"aliases": [
"CVE-2026-52946"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T17:17:04Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling\n\nA SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in\nsend_sigio() and send_sigurg() when a process group receives a signal.\n\nWhen FASYNC is configured for a process group (PIDTYPE_PGID), both\nfunctions use read_lock(\u0026tasklist_lock) to traverse the task list.\nHowever, they are frequently called from softirq context:\n- send_sigio() via input_inject_event -\u003e kill_fasync\n- send_sigurg() via tcp_check_urg -\u003e sk_send_sigurg (NET_RX_SOFTIRQ)\n\nThe deadlock is caused by the rwlock writer fairness mechanism:\n1. CPU 0 (process context) holds read_lock(\u0026tasklist_lock) in do_wait().\n2. CPU 1 (process context) attempts write_lock(\u0026tasklist_lock) in\n fork() or exit() and spins, which blocks all new readers.\n3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception).\n4. The softirq calls send_sigurg() and attempts to acquire\n read_lock(\u0026tasklist_lock), deadlocking because CPU 1 is waiting.\n\nSince PID hashing and do_each_pid_task() traversals are already\nRCU-protected, the read_lock on tasklist_lock is no longer strictly\nrequired for safe traversal. Fix this by replacing tasklist_lock with\nrcu_read_lock(), aligning the process group signaling path with the\nsingle-PID path. This also mitigates a potential remote denial of\nservice vector via TCP URG packets.\n\nLockdep splat:\n=====================================================\nWARNING: SOFTIRQ-safe -\u003e SOFTIRQ-unsafe lock order detected\n[...]\nChain exists of:\n \u0026dev-\u003eevent_lock --\u003e \u0026f_owner-\u003elock --\u003e tasklist_lock\n\nPossible interrupt unsafe locking scenario:\n CPU0 CPU1\n ---- ----\n lock(tasklist_lock);\n local_irq_disable();\n lock(\u0026dev-\u003eevent_lock);\n lock(\u0026f_owner-\u003elock);\n \u003cInterrupt\u003e\n lock(\u0026dev-\u003eevent_lock);\n\n*** DEADLOCK ***",
"id": "GHSA-9h35-hqff-9v3w",
"modified": "2026-09-08T09:35:32Z",
"published": "2026-06-24T18:32:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52946"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/00633c4683828acd5256fa8d5163f440d74bbe71"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1bee417678f1135e35b25a37734db46aa94258d2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/20a93e397abe850c49b6fa0e8cc827b5f634a8f5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/32dbd5ce4be3a3ed7e00f8af18795cc84fc50a33"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/36c1b57b2ecf3c61ac93f5f07bd29b6f21e226ed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/54626335ea4174ab2d9a183b511d825f6765e47b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/897d6a7247739fb1528f98c575df4f2e5de7f994"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b5fa9e32fb6718f70c986ee14dd5d01b4846f331"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bfcc8e8d8a495bb34cae9e620adfb75fb13a3954"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
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.