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.
693 vulnerabilities reference this CWE, most recent first.
GHSA-CM68-WV9Q-PQFQ
Vulnerability from github – Published: 2023-02-06 21:30 – Updated: 2023-02-14 18:30In vcu, there is a possible memory corruption due to improper locking. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07519184; Issue ID: ALPS07519184.
{
"affected": [],
"aliases": [
"CVE-2023-20618"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-06T20:15:00Z",
"severity": "MODERATE"
},
"details": "In vcu, there is a possible memory corruption due to improper locking. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07519184; Issue ID: ALPS07519184.",
"id": "GHSA-cm68-wv9q-pqfq",
"modified": "2023-02-14T18:30:20Z",
"published": "2023-02-06T21:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20618"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/February-2023"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CMGX-QW5M-5J29
Vulnerability from github – Published: 2026-06-25 09:31 – Updated: 2026-07-02 21:32In the Linux kernel, the following vulnerability has been resolved:
net: phy: don't try to setup PHY-driven SFP cages when using genphy
We don't have support for PHY-driver SFP cages with the genphy code.
On top of that, it was found by sashiko that running sfp_bus_add_upstream() for genphy deadlocks, as for genphy the PHY probing runs under RTNL, which isn't the case for non-genphy drivers.
This problem was reproduced, and does lead to a deadlock on RTNL.
Before the blamed commit, the phy_sfp_probe() call was made by individual PHY drivers, so there was no way to get to the SFP probing path when using genphy.
Let's therefore only run phy_sfp_probe when not using genphy.
{
"affected": [],
"aliases": [
"CVE-2026-53231"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-25T09:16:41Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: don\u0027t try to setup PHY-driven SFP cages when using genphy\n\nWe don\u0027t have support for PHY-driver SFP cages with the genphy code.\n\nOn top of that, it was found by sashiko that running\nsfp_bus_add_upstream() for genphy deadlocks, as for genphy the PHY\nprobing runs under RTNL, which isn\u0027t the case for non-genphy drivers.\n\nThis problem was reproduced, and does lead to a deadlock on RTNL.\n\nBefore the blamed commit, the phy_sfp_probe() call was made by\nindividual PHY drivers, so there was no way to get to the SFP probing\npath when using genphy.\n\nLet\u0027s therefore only run phy_sfp_probe when not using genphy.",
"id": "GHSA-cmgx-qw5m-5j29",
"modified": "2026-07-02T21:32:06Z",
"published": "2026-06-25T09:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53231"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5a0082ec20a05ef2378410323a5089a8f1786f4a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ef8d739eee6f85303cbecebc01eb72f063de74e0"
}
],
"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-CP43-X3RR-GWCC
Vulnerability from github – Published: 2025-02-27 21:32 – Updated: 2025-10-28 03:30In the Linux kernel, the following vulnerability has been resolved:
block: fix queue freeze vs limits lock order in sysfs store methods
queue_attr_store() always freezes a device queue before calling the attribute store operation. For attributes that control queue limits, the store operation will also lock the queue limits with a call to queue_limits_start_update(). However, some drivers (e.g. SCSI sd) may need to issue commands to a device to obtain limit values from the hardware with the queue limits locked. This creates a potential ABBA deadlock situation if a user attempts to modify a limit (thus freezing the device queue) while the device driver starts a revalidation of the device queue limits.
Avoid such deadlock by not freezing the queue before calling the ->store_limit() method in struct queue_sysfs_entry and instead use the queue_limits_commit_update_frozen helper to freeze the queue after taking the limits lock.
This also removes taking the sysfs lock for the store_limit method as it doesn't protect anything here, but creates even more nesting. Hopefully it will go away from the actual sysfs methods entirely soon.
(commit log adapted from a similar patch from Damien Le Moal)
{
"affected": [],
"aliases": [
"CVE-2025-21807"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-27T20:16:03Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: fix queue freeze vs limits lock order in sysfs store methods\n\nqueue_attr_store() always freezes a device queue before calling the\nattribute store operation. For attributes that control queue limits, the\nstore operation will also lock the queue limits with a call to\nqueue_limits_start_update(). However, some drivers (e.g. SCSI sd) may\nneed to issue commands to a device to obtain limit values from the\nhardware with the queue limits locked. This creates a potential ABBA\ndeadlock situation if a user attempts to modify a limit (thus freezing\nthe device queue) while the device driver starts a revalidation of the\ndevice queue limits.\n\nAvoid such deadlock by not freezing the queue before calling the\n-\u003estore_limit() method in struct queue_sysfs_entry and instead use the\nqueue_limits_commit_update_frozen helper to freeze the queue after taking\nthe limits lock.\n\nThis also removes taking the sysfs lock for the store_limit method as\nit doesn\u0027t protect anything here, but creates even more nesting.\nHopefully it will go away from the actual sysfs methods entirely soon.\n\n(commit log adapted from a similar patch from Damien Le Moal)",
"id": "GHSA-cp43-x3rr-gwcc",
"modified": "2025-10-28T03:30:13Z",
"published": "2025-02-27T21:32:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21807"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8985da5481562e96b95e94ed8e5cc9b6565eb82b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c99f66e4084a62a2cc401c4704a84328aeddc9ec"
}
],
"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-CPR5-FXJG-JCR6
Vulnerability from github – Published: 2024-02-28 09:30 – Updated: 2024-12-06 21:30In the Linux kernel, the following vulnerability has been resolved:
nvmet-tcp: fix incorrect locking in state_change sk callback
We are not changing anything in the TCP connection state so we should not take a write_lock but rather a read lock.
This caused a deadlock when running nvmet-tcp and nvme-tcp on the same system, where state_change callbacks on the host and on the controller side have causal relationship and made lockdep report on this with blktests:
================================ WARNING: inconsistent lock state 5.12.0-rc3 #1 Tainted: G I
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-R} usage. nvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff888363151000 (clock-AF_INET){++-?}-{2:2}, at: nvme_tcp_state_change+0x21/0x150 [nvme_tcp] {IN-SOFTIRQ-W} state was registered at: __lock_acquire+0x79b/0x18d0 lock_acquire+0x1ca/0x480 _raw_write_lock_bh+0x39/0x80 nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp] tcp_fin+0x2a8/0x780 tcp_data_queue+0xf94/0x1f20 tcp_rcv_established+0x6ba/0x1f00 tcp_v4_do_rcv+0x502/0x760 tcp_v4_rcv+0x257e/0x3430 ip_protocol_deliver_rcu+0x69/0x6a0 ip_local_deliver_finish+0x1e2/0x2f0 ip_local_deliver+0x1a2/0x420 ip_rcv+0x4fb/0x6b0 __netif_receive_skb_one_core+0x162/0x1b0 process_backlog+0x1ff/0x770 __napi_poll.constprop.0+0xa9/0x5c0 net_rx_action+0x7b3/0xb30 __do_softirq+0x1f0/0x940 do_softirq+0xa1/0xd0 __local_bh_enable_ip+0xd8/0x100 ip_finish_output2+0x6b7/0x18a0 __ip_queue_xmit+0x706/0x1aa0 __tcp_transmit_skb+0x2068/0x2e20 tcp_write_xmit+0xc9e/0x2bb0 __tcp_push_pending_frames+0x92/0x310 inet_shutdown+0x158/0x300 __nvme_tcp_stop_queue+0x36/0x270 [nvme_tcp] nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp] nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp] nvme_do_delete_ctrl+0x100/0x10c [nvme_core] nvme_sysfs_delete.cold+0x8/0xd [nvme_core] kernfs_fop_write_iter+0x2c7/0x460 new_sync_write+0x36c/0x610 vfs_write+0x5c0/0x870 ksys_write+0xf9/0x1d0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae irq event stamp: 10687 hardirqs last enabled at (10687): [] _raw_spin_unlock_irqrestore+0x2d/0x40 hardirqs last disabled at (10686): [] _raw_spin_lock_irqsave+0x68/0x90 softirqs last enabled at (10684): [] __do_softirq+0x608/0x940 softirqs last disabled at (10649): [] do_softirq+0xa1/0xd0
other info that might help us debug this: Possible unsafe locking scenario:
CPU0
----
lock(clock-AF_INET); lock(clock-AF_INET);
*** DEADLOCK ***
5 locks held by nvme/1324: #0: ffff8884a01fe470 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xf9/0x1d0 #1: ffff8886e435c090 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x216/0x460 #2: ffff888104d90c38 (kn->active#255){++++}-{0:0}, at: kernfs_remove_self+0x22d/0x330 #3: ffff8884634538d0 (&queue->queue_lock){+.+.}-{3:3}, at: nvme_tcp_stop_queue+0x52/0xb0 [nvme_tcp] #4: ffff888363150d30 (sk_lock-AF_INET){+.+.}-{0:0}, at: inet_shutdown+0x59/0x300
stack backtrace: CPU: 26 PID: 1324 Comm: nvme Tainted: G I 5.12.0-rc3 #1 Hardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.10.0 11/12/2020 Call Trace: dump_stack+0x93/0xc2 mark_lock_irq.cold+0x2c/0xb3 ? verify_lock_unused+0x390/0x390 ? stack_trace_consume_entry+0x160/0x160 ? lock_downgrade+0x100/0x100 ? save_trace+0x88/0x5e0 ? _raw_spin_unlock_irqrestore+0x2d/0x40 mark_lock+0x530/0x1470 ? mark_lock_irq+0x1d10/0x1d10 ? enqueue_timer+0x660/0x660 mark_usage+0x215/0x2a0 __lock_acquire+0x79b/0x18d0 ? tcp_schedule_loss_probe.part.0+0x38c/0x520 lock_acquire+0x1ca/0x480 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? rcu_read_unlock+0x40/0x40 ? tcp_mtu_probe+0x1ae0/0x1ae0 ? kmalloc_reserve+0xa0/0xa0 ? sysfs_file_ops+0x170/0x170 _raw_read_lock+0x3d/0xa0 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? sysfs_file_ops ---truncated---
{
"affected": [],
"aliases": [
"CVE-2021-47041"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-28T09:15:40Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: fix incorrect locking in state_change sk callback\n\nWe are not changing anything in the TCP connection state so\nwe should not take a write_lock but rather a read lock.\n\nThis caused a deadlock when running nvmet-tcp and nvme-tcp\non the same system, where state_change callbacks on the\nhost and on the controller side have causal relationship\nand made lockdep report on this with blktests:\n\n================================\nWARNING: inconsistent lock state\n5.12.0-rc3 #1 Tainted: G I\n--------------------------------\ninconsistent {IN-SOFTIRQ-W} -\u003e {SOFTIRQ-ON-R} usage.\nnvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes:\nffff888363151000 (clock-AF_INET){++-?}-{2:2}, at: nvme_tcp_state_change+0x21/0x150 [nvme_tcp]\n{IN-SOFTIRQ-W} state was registered at:\n __lock_acquire+0x79b/0x18d0\n lock_acquire+0x1ca/0x480\n _raw_write_lock_bh+0x39/0x80\n nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp]\n tcp_fin+0x2a8/0x780\n tcp_data_queue+0xf94/0x1f20\n tcp_rcv_established+0x6ba/0x1f00\n tcp_v4_do_rcv+0x502/0x760\n tcp_v4_rcv+0x257e/0x3430\n ip_protocol_deliver_rcu+0x69/0x6a0\n ip_local_deliver_finish+0x1e2/0x2f0\n ip_local_deliver+0x1a2/0x420\n ip_rcv+0x4fb/0x6b0\n __netif_receive_skb_one_core+0x162/0x1b0\n process_backlog+0x1ff/0x770\n __napi_poll.constprop.0+0xa9/0x5c0\n net_rx_action+0x7b3/0xb30\n __do_softirq+0x1f0/0x940\n do_softirq+0xa1/0xd0\n __local_bh_enable_ip+0xd8/0x100\n ip_finish_output2+0x6b7/0x18a0\n __ip_queue_xmit+0x706/0x1aa0\n __tcp_transmit_skb+0x2068/0x2e20\n tcp_write_xmit+0xc9e/0x2bb0\n __tcp_push_pending_frames+0x92/0x310\n inet_shutdown+0x158/0x300\n __nvme_tcp_stop_queue+0x36/0x270 [nvme_tcp]\n nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp]\n nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp]\n nvme_do_delete_ctrl+0x100/0x10c [nvme_core]\n nvme_sysfs_delete.cold+0x8/0xd [nvme_core]\n kernfs_fop_write_iter+0x2c7/0x460\n new_sync_write+0x36c/0x610\n vfs_write+0x5c0/0x870\n ksys_write+0xf9/0x1d0\n do_syscall_64+0x33/0x40\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nirq event stamp: 10687\nhardirqs last enabled at (10687): [\u003cffffffff9ec376bd\u003e] _raw_spin_unlock_irqrestore+0x2d/0x40\nhardirqs last disabled at (10686): [\u003cffffffff9ec374d8\u003e] _raw_spin_lock_irqsave+0x68/0x90\nsoftirqs last enabled at (10684): [\u003cffffffff9f000608\u003e] __do_softirq+0x608/0x940\nsoftirqs last disabled at (10649): [\u003cffffffff9cdedd31\u003e] do_softirq+0xa1/0xd0\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(clock-AF_INET);\n \u003cInterrupt\u003e\n lock(clock-AF_INET);\n\n *** DEADLOCK ***\n\n5 locks held by nvme/1324:\n #0: ffff8884a01fe470 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xf9/0x1d0\n #1: ffff8886e435c090 (\u0026of-\u003emutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x216/0x460\n #2: ffff888104d90c38 (kn-\u003eactive#255){++++}-{0:0}, at: kernfs_remove_self+0x22d/0x330\n #3: ffff8884634538d0 (\u0026queue-\u003equeue_lock){+.+.}-{3:3}, at: nvme_tcp_stop_queue+0x52/0xb0 [nvme_tcp]\n #4: ffff888363150d30 (sk_lock-AF_INET){+.+.}-{0:0}, at: inet_shutdown+0x59/0x300\n\nstack backtrace:\nCPU: 26 PID: 1324 Comm: nvme Tainted: G I 5.12.0-rc3 #1\nHardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.10.0 11/12/2020\nCall Trace:\n dump_stack+0x93/0xc2\n mark_lock_irq.cold+0x2c/0xb3\n ? verify_lock_unused+0x390/0x390\n ? stack_trace_consume_entry+0x160/0x160\n ? lock_downgrade+0x100/0x100\n ? save_trace+0x88/0x5e0\n ? _raw_spin_unlock_irqrestore+0x2d/0x40\n mark_lock+0x530/0x1470\n ? mark_lock_irq+0x1d10/0x1d10\n ? enqueue_timer+0x660/0x660\n mark_usage+0x215/0x2a0\n __lock_acquire+0x79b/0x18d0\n ? tcp_schedule_loss_probe.part.0+0x38c/0x520\n lock_acquire+0x1ca/0x480\n ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp]\n ? rcu_read_unlock+0x40/0x40\n ? tcp_mtu_probe+0x1ae0/0x1ae0\n ? kmalloc_reserve+0xa0/0xa0\n ? sysfs_file_ops+0x170/0x170\n _raw_read_lock+0x3d/0xa0\n ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp]\n nvme_tcp_state_change+0x21/0x150 [nvme_tcp]\n ? sysfs_file_ops\n---truncated---",
"id": "GHSA-cpr5-fxjg-jcr6",
"modified": "2024-12-06T21:30:35Z",
"published": "2024-02-28T09:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47041"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/06beaa1a9f6e501213195e47c30416032fd2bbd5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/60ade0d56b06537a28884745059b3801c78e03bc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/906c538340dde6d891df89fe7dac8eaa724e40da"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/999d606a820c36ae9b9e9611360c8b3d8d4bb777"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b5332a9f3f3d884a1b646ce155e664cc558c1722"
}
],
"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-CQCJ-P3PX-RPRF
Vulnerability from github – Published: 2026-01-14 15:33 – Updated: 2026-03-25 21:30In the Linux kernel, the following vulnerability has been resolved:
mptcp: avoid deadlock on fallback while reinjecting
Jakub reported an MPTCP deadlock at fallback time:
WARNING: possible recursive locking detected 6.18.0-rc7-virtme #1 Not tainted
mptcp_connect/20858 is trying to acquire lock: ff1100001da18b60 (&msk->fallback_lock){+.-.}-{3:3}, at: __mptcp_try_fallback+0xd8/0x280
but task is already holding lock: ff1100001da18b60 (&msk->fallback_lock){+.-.}-{3:3}, at: __mptcp_retrans+0x352/0xaa0
other info that might help us debug this: Possible unsafe locking scenario:
CPU0
----
lock(&msk->fallback_lock); lock(&msk->fallback_lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by mptcp_connect/20858: #0: ff1100001da18290 (sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_sendmsg+0x114/0x1bc0 #1: ff1100001db40fd0 (k-sk_lock-AF_INET#2){+.+.}-{0:0}, at: __mptcp_retrans+0x2cb/0xaa0 #2: ff1100001da18b60 (&msk->fallback_lock){+.-.}-{3:3}, at: __mptcp_retrans+0x352/0xaa0
stack backtrace: CPU: 0 UID: 0 PID: 20858 Comm: mptcp_connect Not tainted 6.18.0-rc7-virtme #1 PREEMPT(full) Hardware name: Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0x6f/0xa0 print_deadlock_bug.cold+0xc0/0xcd validate_chain+0x2ff/0x5f0 __lock_acquire+0x34c/0x740 lock_acquire.part.0+0xbc/0x260 _raw_spin_lock_bh+0x38/0x50 __mptcp_try_fallback+0xd8/0x280 mptcp_sendmsg_frag+0x16c2/0x3050 __mptcp_retrans+0x421/0xaa0 mptcp_release_cb+0x5aa/0xa70 release_sock+0xab/0x1d0 mptcp_sendmsg+0xd5b/0x1bc0 sock_write_iter+0x281/0x4d0 new_sync_write+0x3c5/0x6f0 vfs_write+0x65e/0xbb0 ksys_write+0x17e/0x200 do_syscall_64+0xbb/0xfd0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7fa5627cbc5e Code: 4d 89 d8 e8 14 bd 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa RSP: 002b:00007fff1fe14700 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fa5627cbc5e RDX: 0000000000001f9c RSI: 00007fff1fe16984 RDI: 0000000000000005 RBP: 00007fff1fe14710 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff1fe16920 R13: 0000000000002000 R14: 0000000000001f9c R15: 0000000000001f9c
The packet scheduler could attempt a reinjection after receiving an MP_FAIL and before the infinite map has been transmitted, causing a deadlock since MPTCP needs to do the reinjection atomically from WRT fallback.
Address the issue explicitly avoiding the reinjection in the critical scenario. Note that this is the only fallback critical section that could potentially send packets and hit the double-lock.
{
"affected": [],
"aliases": [
"CVE-2025-71126"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-14T15:16:02Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: avoid deadlock on fallback while reinjecting\n\nJakub reported an MPTCP deadlock at fallback time:\n\n WARNING: possible recursive locking detected\n 6.18.0-rc7-virtme #1 Not tainted\n --------------------------------------------\n mptcp_connect/20858 is trying to acquire lock:\n ff1100001da18b60 (\u0026msk-\u003efallback_lock){+.-.}-{3:3}, at: __mptcp_try_fallback+0xd8/0x280\n\n but task is already holding lock:\n ff1100001da18b60 (\u0026msk-\u003efallback_lock){+.-.}-{3:3}, at: __mptcp_retrans+0x352/0xaa0\n\n other info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(\u0026msk-\u003efallback_lock);\n lock(\u0026msk-\u003efallback_lock);\n\n *** DEADLOCK ***\n\n May be due to missing lock nesting notation\n\n 3 locks held by mptcp_connect/20858:\n #0: ff1100001da18290 (sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_sendmsg+0x114/0x1bc0\n #1: ff1100001db40fd0 (k-sk_lock-AF_INET#2){+.+.}-{0:0}, at: __mptcp_retrans+0x2cb/0xaa0\n #2: ff1100001da18b60 (\u0026msk-\u003efallback_lock){+.-.}-{3:3}, at: __mptcp_retrans+0x352/0xaa0\n\n stack backtrace:\n CPU: 0 UID: 0 PID: 20858 Comm: mptcp_connect Not tainted 6.18.0-rc7-virtme #1 PREEMPT(full)\n Hardware name: Bochs, BIOS Bochs 01/01/2011\n Call Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x6f/0xa0\n print_deadlock_bug.cold+0xc0/0xcd\n validate_chain+0x2ff/0x5f0\n __lock_acquire+0x34c/0x740\n lock_acquire.part.0+0xbc/0x260\n _raw_spin_lock_bh+0x38/0x50\n __mptcp_try_fallback+0xd8/0x280\n mptcp_sendmsg_frag+0x16c2/0x3050\n __mptcp_retrans+0x421/0xaa0\n mptcp_release_cb+0x5aa/0xa70\n release_sock+0xab/0x1d0\n mptcp_sendmsg+0xd5b/0x1bc0\n sock_write_iter+0x281/0x4d0\n new_sync_write+0x3c5/0x6f0\n vfs_write+0x65e/0xbb0\n ksys_write+0x17e/0x200\n do_syscall_64+0xbb/0xfd0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x7fa5627cbc5e\n Code: 4d 89 d8 e8 14 bd 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 \u003cc9\u003e c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa\n RSP: 002b:00007fff1fe14700 EFLAGS: 00000202 ORIG_RAX: 0000000000000001\n RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fa5627cbc5e\n RDX: 0000000000001f9c RSI: 00007fff1fe16984 RDI: 0000000000000005\n RBP: 00007fff1fe14710 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff1fe16920\n R13: 0000000000002000 R14: 0000000000001f9c R15: 0000000000001f9c\n\nThe packet scheduler could attempt a reinjection after receiving an\nMP_FAIL and before the infinite map has been transmitted, causing a\ndeadlock since MPTCP needs to do the reinjection atomically from WRT\nfallback.\n\nAddress the issue explicitly avoiding the reinjection in the critical\nscenario. Note that this is the only fallback critical section that\ncould potentially send packets and hit the double-lock.",
"id": "GHSA-cqcj-p3px-rprf",
"modified": "2026-03-25T21:30:22Z",
"published": "2026-01-14T15:33:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71126"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0107442e82c0f8d6010e07e6030741c59c520d6e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0ca9fb4335e726dab4f23b3bfe87271d8f005f41"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/252892d5a6a2f163ce18f32716e46fa4da7d4e79"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/50f47c02be419bf0a3ae94c118addf67beef359f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ffb8c27b0539dd90262d1021488e7817fae57c42"
}
],
"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-CQH4-JV7G-JR53
Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-21 18:33In the Linux kernel, the following vulnerability has been resolved:
accel/amdxdna: Fix runtime suspend deadlock when there is pending job
The runtime suspend callback drains the running job workqueue before suspending the device. If a job is still executing and calls pm_runtime_resume_and_get(), it can deadlock with the runtime suspend path.
Fix this by moving pm_runtime_resume_and_get() from the job execution routine to the job submission routine, ensuring the device is resumed before the job is queued and avoiding the deadlock during runtime suspend.
{
"affected": [],
"aliases": [
"CVE-2026-43446"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-08T15:16:57Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\naccel/amdxdna: Fix runtime suspend deadlock when there is pending job\n\nThe runtime suspend callback drains the running job workqueue before\nsuspending the device. If a job is still executing and calls\npm_runtime_resume_and_get(), it can deadlock with the runtime suspend\npath.\n\nFix this by moving pm_runtime_resume_and_get() from the job execution\nroutine to the job submission routine, ensuring the device is resumed\nbefore the job is queued and avoiding the deadlock during runtime\nsuspend.",
"id": "GHSA-cqh4-jv7g-jr53",
"modified": "2026-05-21T18:33:06Z",
"published": "2026-05-08T15:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43446"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6b13cb8f48a42ddf6dd98865b673a82e37ff238b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ac72e7385a2c7533dd766de4197134d96230be85"
}
],
"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-CQJR-X55G-2J6V
Vulnerability from github – Published: 2025-04-01 18:30 – Updated: 2025-11-03 21:33In the Linux kernel, the following vulnerability has been resolved:
gpio: rcar: Use raw_spinlock to protect register access
Use raw_spinlock in order to fix spurious messages about invalid context when spinlock debugging is enabled. The lock is only used to serialize register access.
[ 4.239592] =============================
[ 4.239595] [ BUG: Invalid wait context ]
[ 4.239599] 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 Not tainted
[ 4.239603] -----------------------------
[ 4.239606] kworker/u8:5/76 is trying to lock:
[ 4.239609] ffff0000091898a0 (&p->lock){....}-{3:3}, at: gpio_rcar_config_interrupt_input_mode+0x34/0x164
[ 4.239641] other info that might help us debug this:
[ 4.239643] context-{5:5}
[ 4.239646] 5 locks held by kworker/u8:5/76:
[ 4.239651] #0: ffff0000080fb148 ((wq_completion)async){+.+.}-{0:0}, at: process_one_work+0x190/0x62c
[ 4.250180] OF: /soc/sound@ec500000/ports/port@0/endpoint: Read of boolean property 'frame-master' with a value.
[ 4.254094] #1: ffff80008299bd80 ((work_completion)(&entry->work)){+.+.}-{0:0}, at: process_one_work+0x1b8/0x62c
[ 4.254109] #2: ffff00000920c8f8
[ 4.258345] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property 'bitclock-master' with a value.
[ 4.264803] (&dev->mutex){....}-{4:4}, at: __device_attach_async_helper+0x3c/0xdc
[ 4.264820] #3: ffff00000a50ca40 (request_class#2){+.+.}-{4:4}, at: __setup_irq+0xa0/0x690
[ 4.264840] #4:
[ 4.268872] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property 'frame-master' with a value.
[ 4.273275] ffff00000a50c8c8 (lock_class){....}-{2:2}, at: __setup_irq+0xc4/0x690
[ 4.296130] renesas_sdhi_internal_dmac ee100000.mmc: mmc1 base at 0x00000000ee100000, max clock rate 200 MHz
[ 4.304082] stack backtrace:
[ 4.304086] CPU: 1 UID: 0 PID: 76 Comm: kworker/u8:5 Not tainted 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35
[ 4.304092] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)
[ 4.304097] Workqueue: async async_run_entry_fn
[ 4.304106] Call trace:
[ 4.304110] show_stack+0x14/0x20 (C)
[ 4.304122] dump_stack_lvl+0x6c/0x90
[ 4.304131] dump_stack+0x14/0x1c
[ 4.304138] __lock_acquire+0xdfc/0x1584
[ 4.426274] lock_acquire+0x1c4/0x33c
[ 4.429942] _raw_spin_lock_irqsave+0x5c/0x80
[ 4.434307] gpio_rcar_config_interrupt_input_mode+0x34/0x164
[ 4.440061] gpio_rcar_irq_set_type+0xd4/0xd8
[ 4.444422] __irq_set_trigger+0x5c/0x178
[ 4.448435] __setup_irq+0x2e4/0x690
[ 4.452012] request_threaded_irq+0xc4/0x190
[ 4.456285] devm_request_threaded_irq+0x7c/0xf4
[ 4.459398] ata1: link resume succeeded after 1 retries
[ 4.460902] mmc_gpiod_request_cd_irq+0x68/0xe0
[ 4.470660] mmc_start_host+0x50/0xac
[ 4.474327] mmc_add_host+0x80/0xe4
[ 4.477817] tmio_mmc_host_probe+0x2b0/0x440
[ 4.482094] renesas_sdhi_probe+0x488/0x6f4
[ 4.486281] renesas_sdhi_internal_dmac_probe+0x60/0x78
[ 4.491509] platform_probe+0x64/0xd8
[ 4.495178] really_probe+0xb8/0x2a8
[ 4.498756] __driver_probe_device+0x74/0x118
[ 4.503116] driver_probe_device+0x3c/0x154
[ 4.507303] __device_attach_driver+0xd4/0x160
[ 4.511750] bus_for_each_drv+0x84/0xe0
[ 4.515588] __device_attach_async_helper+0xb0/0xdc
[ 4.520470] async_run_entry_fn+0x30/0xd8
[ 4.524481] process_one_work+0x210/0x62c
[ 4.528494] worker_thread+0x1ac/0x340
[ 4.532245] kthread+0x10c/0x110
[ 4.535476] ret_from_fork+0x10/0x20
{
"affected": [],
"aliases": [
"CVE-2025-21912"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-01T16:15:21Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: rcar: Use raw_spinlock to protect register access\n\nUse raw_spinlock in order to fix spurious messages about invalid context\nwhen spinlock debugging is enabled. The lock is only used to serialize\nregister access.\n\n [ 4.239592] =============================\n [ 4.239595] [ BUG: Invalid wait context ]\n [ 4.239599] 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 Not tainted\n [ 4.239603] -----------------------------\n [ 4.239606] kworker/u8:5/76 is trying to lock:\n [ 4.239609] ffff0000091898a0 (\u0026p-\u003elock){....}-{3:3}, at: gpio_rcar_config_interrupt_input_mode+0x34/0x164\n [ 4.239641] other info that might help us debug this:\n [ 4.239643] context-{5:5}\n [ 4.239646] 5 locks held by kworker/u8:5/76:\n [ 4.239651] #0: ffff0000080fb148 ((wq_completion)async){+.+.}-{0:0}, at: process_one_work+0x190/0x62c\n [ 4.250180] OF: /soc/sound@ec500000/ports/port@0/endpoint: Read of boolean property \u0027frame-master\u0027 with a value.\n [ 4.254094] #1: ffff80008299bd80 ((work_completion)(\u0026entry-\u003ework)){+.+.}-{0:0}, at: process_one_work+0x1b8/0x62c\n [ 4.254109] #2: ffff00000920c8f8\n [ 4.258345] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property \u0027bitclock-master\u0027 with a value.\n [ 4.264803] (\u0026dev-\u003emutex){....}-{4:4}, at: __device_attach_async_helper+0x3c/0xdc\n [ 4.264820] #3: ffff00000a50ca40 (request_class#2){+.+.}-{4:4}, at: __setup_irq+0xa0/0x690\n [ 4.264840] #4:\n [ 4.268872] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property \u0027frame-master\u0027 with a value.\n [ 4.273275] ffff00000a50c8c8 (lock_class){....}-{2:2}, at: __setup_irq+0xc4/0x690\n [ 4.296130] renesas_sdhi_internal_dmac ee100000.mmc: mmc1 base at 0x00000000ee100000, max clock rate 200 MHz\n [ 4.304082] stack backtrace:\n [ 4.304086] CPU: 1 UID: 0 PID: 76 Comm: kworker/u8:5 Not tainted 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35\n [ 4.304092] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)\n [ 4.304097] Workqueue: async async_run_entry_fn\n [ 4.304106] Call trace:\n [ 4.304110] show_stack+0x14/0x20 (C)\n [ 4.304122] dump_stack_lvl+0x6c/0x90\n [ 4.304131] dump_stack+0x14/0x1c\n [ 4.304138] __lock_acquire+0xdfc/0x1584\n [ 4.426274] lock_acquire+0x1c4/0x33c\n [ 4.429942] _raw_spin_lock_irqsave+0x5c/0x80\n [ 4.434307] gpio_rcar_config_interrupt_input_mode+0x34/0x164\n [ 4.440061] gpio_rcar_irq_set_type+0xd4/0xd8\n [ 4.444422] __irq_set_trigger+0x5c/0x178\n [ 4.448435] __setup_irq+0x2e4/0x690\n [ 4.452012] request_threaded_irq+0xc4/0x190\n [ 4.456285] devm_request_threaded_irq+0x7c/0xf4\n [ 4.459398] ata1: link resume succeeded after 1 retries\n [ 4.460902] mmc_gpiod_request_cd_irq+0x68/0xe0\n [ 4.470660] mmc_start_host+0x50/0xac\n [ 4.474327] mmc_add_host+0x80/0xe4\n [ 4.477817] tmio_mmc_host_probe+0x2b0/0x440\n [ 4.482094] renesas_sdhi_probe+0x488/0x6f4\n [ 4.486281] renesas_sdhi_internal_dmac_probe+0x60/0x78\n [ 4.491509] platform_probe+0x64/0xd8\n [ 4.495178] really_probe+0xb8/0x2a8\n [ 4.498756] __driver_probe_device+0x74/0x118\n [ 4.503116] driver_probe_device+0x3c/0x154\n [ 4.507303] __device_attach_driver+0xd4/0x160\n [ 4.511750] bus_for_each_drv+0x84/0xe0\n [ 4.515588] __device_attach_async_helper+0xb0/0xdc\n [ 4.520470] async_run_entry_fn+0x30/0xd8\n [ 4.524481] process_one_work+0x210/0x62c\n [ 4.528494] worker_thread+0x1ac/0x340\n [ 4.532245] kthread+0x10c/0x110\n [ 4.535476] ret_from_fork+0x10/0x20",
"id": "GHSA-cqjr-x55g-2j6v",
"modified": "2025-11-03T21:33:21Z",
"published": "2025-04-01T18:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21912"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/389891ac9f678baf68e13623ef1308493af4b074"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e300913c42041e81c5b17a970c4e078086ff2d1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/51ef3073493e2a25dced05fdd59dfb059e7e284d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7c1f36f9c9aca507d317479a3d3388150ae40a87"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b42c84f9e4ec5bc2885e7fd80c79ec0352f5d2af"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c10365031f16514a29c812cd909085a6e4ea4b61"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f02c41f87cfe61440c18bf77d1ef0a884b9ee2b5"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.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-CQWH-R98H-2279
Vulnerability from github – Published: 2026-04-24 15:32 – Updated: 2026-06-01 18:31In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix possible deadlock between unlink and dio_end_io_write
ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem, while in ocfs2_dio_end_io_write, it acquires these locks in reverse order. This creates an ABBA lock ordering violation on lock classes ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and ocfs2_file_ip_alloc_sem_key.
Lock Chain #0 (orphan dir inode_lock -> ip_alloc_sem): ocfs2_unlink ocfs2_prepare_orphan_dir ocfs2_lookup_lock_orphan_dir inode_lock(orphan_dir_inode) <- lock A __ocfs2_prepare_orphan_dir ocfs2_prepare_dir_for_insert ocfs2_extend_dir ocfs2_expand_inline_dir down_write(&oi->ip_alloc_sem) <- Lock B
Lock Chain #1 (ip_alloc_sem -> orphan dir inode_lock): ocfs2_dio_end_io_write down_write(&oi->ip_alloc_sem) <- Lock B ocfs2_del_inode_from_orphan() inode_lock(orphan_dir_inode) <- Lock A
Deadlock Scenario: CPU0 (unlink) CPU1 (dio_end_io_write) ------ ------ inode_lock(orphan_dir_inode) down_write(ip_alloc_sem) down_write(ip_alloc_sem) inode_lock(orphan_dir_inode)
Since ip_alloc_sem is to protect allocation changes, which is unrelated with operations in ocfs2_del_inode_from_orphan. So move ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.
{
"affected": [],
"aliases": [
"CVE-2026-31598"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-24T15:16:37Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix possible deadlock between unlink and dio_end_io_write\n\nocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem,\nwhile in ocfs2_dio_end_io_write, it acquires these locks in reverse order.\nThis creates an ABBA lock ordering violation on lock classes\nocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and\nocfs2_file_ip_alloc_sem_key.\n\nLock Chain #0 (orphan dir inode_lock -\u003e ip_alloc_sem):\nocfs2_unlink\n ocfs2_prepare_orphan_dir\n ocfs2_lookup_lock_orphan_dir\n inode_lock(orphan_dir_inode) \u003c- lock A\n __ocfs2_prepare_orphan_dir\n ocfs2_prepare_dir_for_insert\n ocfs2_extend_dir\n\t ocfs2_expand_inline_dir\n\t down_write(\u0026oi-\u003eip_alloc_sem) \u003c- Lock B\n\nLock Chain #1 (ip_alloc_sem -\u003e orphan dir inode_lock):\nocfs2_dio_end_io_write\n down_write(\u0026oi-\u003eip_alloc_sem) \u003c- Lock B\n ocfs2_del_inode_from_orphan()\n inode_lock(orphan_dir_inode) \u003c- Lock A\n\nDeadlock Scenario:\n CPU0 (unlink) CPU1 (dio_end_io_write)\n ------ ------\n inode_lock(orphan_dir_inode)\n down_write(ip_alloc_sem)\n down_write(ip_alloc_sem)\n inode_lock(orphan_dir_inode)\n\nSince ip_alloc_sem is to protect allocation changes, which is unrelated\nwith operations in ocfs2_del_inode_from_orphan. So move\nocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.",
"id": "GHSA-cqwh-r98h-2279",
"modified": "2026-06-01T18:31:27Z",
"published": "2026-04-24T15:32:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31598"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/297d8d7bb6a2bf133d3a3636edbdf94101cbd719"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2b884d52273c60c298bd570163e8053657bbaff6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/32630dee18c6bb2175c8a865a474749492eaf19c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4b80b5a838a32437f2cae0662578bac216a2c51a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/93f35419eb84d58820040642cb6e7528fe4aba7a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b02da26a992db0c0e2559acbda0fc48d4a2fd337"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bc0fb5c7d54c78be43a536df0e20dee32adb27d3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e049f7a9bd80b7319590789ea5e1c523d6339d91"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f9fb1a7b635849322e1d7b7b6b26389778ec8e82"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CR25-MCG8-CFVP
Vulnerability from github – Published: 2025-01-11 15:30 – Updated: 2025-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
scsi: megaraid_sas: Fix for a potential deadlock
This fixes a 'possible circular locking dependency detected' warning CPU0 CPU1 ---- ---- lock(&instance->reset_mutex); lock(&shost->scan_mutex); lock(&instance->reset_mutex); lock(&shost->scan_mutex);
Fix this by temporarily releasing the reset_mutex.
{
"affected": [],
"aliases": [
"CVE-2024-57807"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-11T13:15:30Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: megaraid_sas: Fix for a potential deadlock\n\nThis fixes a \u0027possible circular locking dependency detected\u0027 warning\n CPU0 CPU1\n ---- ----\n lock(\u0026instance-\u003ereset_mutex);\n lock(\u0026shost-\u003escan_mutex);\n lock(\u0026instance-\u003ereset_mutex);\n lock(\u0026shost-\u003escan_mutex);\n\nFix this by temporarily releasing the reset_mutex.",
"id": "GHSA-cr25-mcg8-cfvp",
"modified": "2025-11-03T21:32:07Z",
"published": "2025-01-11T15:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57807"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3c654998a3e8167a58b6c6fede545fe400a4b554"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/466ca39dbf5d0ba71c16b15c27478a9c7d4022a8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/50740f4dc78b41dec7c8e39772619d5ba841ddd7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/78afb9bfad00c4aa58a424111d7edbcab9452f2b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/edadc693bfcc0f1ea08b8fa041c9361fd042410d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f36d024bd15ed356a80dda3ddc46d0a62aa55815"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f50783148ec98a1d38b87422e2ceaf2380b7b606"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CR4C-WW97-FPHQ
Vulnerability from github – Published: 2024-03-15 21:30 – Updated: 2025-03-13 21:31In the Linux kernel, the following vulnerability has been resolved:
bpf, lockdown, audit: Fix buggy SELinux lockdown permission checks
Commit 59438b46471a ("security,lockdown,selinux: implement SELinux lockdown") added an implementation of the locked_down LSM hook to SELinux, with the aim to restrict which domains are allowed to perform operations that would breach lockdown. This is indirectly also getting audit subsystem involved to report events. The latter is problematic, as reported by Ondrej and Serhei, since it can bring down the whole system via audit:
1) The audit events that are triggered due to calls to security_locked_down() can OOM kill a machine, see below details [0].
2) It also seems to be causing a deadlock via avc_has_perm()/slow_avc_audit() when trying to wake up kauditd, for example, when using trace_sched_switch() tracepoint, see details in [1]. Triggering this was not via some hypothetical corner case, but with existing tools like runqlat & runqslower from bcc, for example, which make use of this tracepoint. Rough call sequence goes like:
rq_lock(rq) -> -------------------------+
trace_sched_switch() -> |
bpf_prog_xyz() -> +-> deadlock
selinux_lockdown() -> |
audit_log_end() -> |
wake_up_interruptible() -> |
try_to_wake_up() -> |
rq_lock(rq) --------------+
What's worse is that the intention of 59438b46471a to further restrict lockdown settings for specific applications in respect to the global lockdown policy is completely broken for BPF. The SELinux policy rule for the current lockdown check looks something like this:
allow : lockdown { };
However, this doesn't match with the 'current' task where the security_locked_down() is executed, example: httpd does a syscall. There is a tracing program attached to the syscall which triggers a BPF program to run, which ends up doing a bpf_probe_read_kernel{,_str}() helper call. The selinux_lockdown() hook does the permission check against 'current', that is, httpd in this example. httpd has literally zero relation to this tracing program, and it would be nonsensical having to write an SELinux policy rule against httpd to let the tracing helper pass. The policy in this case needs to be against the entity that is installing the BPF program. For example, if bpftrace would generate a histogram of syscall counts by user space application:
bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'
bpftrace would then go and generate a BPF program from this internally. One way of doing it [for the sake of the example] could be to call bpf_get_current_task() helper and then access current->comm via one of bpf_probe_read_kernel{,str}() helpers. So the program itself has nothing to do with httpd or any other random app doing a syscall here. The BPF program _explicitly initiated the lockdown check. The allow/deny policy belongs in the context of bpftrace: meaning, you want to grant bpftrace access to use these helpers, but other tracers on the system like my_random_tracer not.
Therefore fix all three issues at the same time by taking a completely different approach for the security_locked_down() hook, that is, move the check into the program verification phase where we actually retrieve the BPF func proto. This also reliably gets the task (current) that is trying to install the BPF tracing program, e.g. bpftrace/bcc/perf/systemtap/etc, and it also fixes the OOM since we're moving this out of the BPF helper's fast-path which can be called several millions of times per second.
The check is then also in line with other security_locked_down() hooks in the system where the enforcement is performed at open/load time, for example, open_kcore() for /proc/kcore access or module_sig_check() for module signatures just to pick f ---truncated---
{
"affected": [],
"aliases": [
"CVE-2021-47128"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-15T21:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, lockdown, audit: Fix buggy SELinux lockdown permission checks\n\nCommit 59438b46471a (\"security,lockdown,selinux: implement SELinux lockdown\")\nadded an implementation of the locked_down LSM hook to SELinux, with the aim\nto restrict which domains are allowed to perform operations that would breach\nlockdown. This is indirectly also getting audit subsystem involved to report\nevents. The latter is problematic, as reported by Ondrej and Serhei, since it\ncan bring down the whole system via audit:\n\n 1) The audit events that are triggered due to calls to security_locked_down()\n can OOM kill a machine, see below details [0].\n\n 2) It also seems to be causing a deadlock via avc_has_perm()/slow_avc_audit()\n when trying to wake up kauditd, for example, when using trace_sched_switch()\n tracepoint, see details in [1]. Triggering this was not via some hypothetical\n corner case, but with existing tools like runqlat \u0026 runqslower from bcc, for\n example, which make use of this tracepoint. Rough call sequence goes like:\n\n rq_lock(rq) -\u003e -------------------------+\n trace_sched_switch() -\u003e |\n bpf_prog_xyz() -\u003e +-\u003e deadlock\n selinux_lockdown() -\u003e |\n audit_log_end() -\u003e |\n wake_up_interruptible() -\u003e |\n try_to_wake_up() -\u003e |\n rq_lock(rq) --------------+\n\nWhat\u0027s worse is that the intention of 59438b46471a to further restrict lockdown\nsettings for specific applications in respect to the global lockdown policy is\ncompletely broken for BPF. The SELinux policy rule for the current lockdown check\nlooks something like this:\n\n allow \u003cwho\u003e \u003cwho\u003e : lockdown { \u003creason\u003e };\n\nHowever, this doesn\u0027t match with the \u0027current\u0027 task where the security_locked_down()\nis executed, example: httpd does a syscall. There is a tracing program attached\nto the syscall which triggers a BPF program to run, which ends up doing a\nbpf_probe_read_kernel{,_str}() helper call. The selinux_lockdown() hook does\nthe permission check against \u0027current\u0027, that is, httpd in this example. httpd\nhas literally zero relation to this tracing program, and it would be nonsensical\nhaving to write an SELinux policy rule against httpd to let the tracing helper\npass. The policy in this case needs to be against the entity that is installing\nthe BPF program. For example, if bpftrace would generate a histogram of syscall\ncounts by user space application:\n\n bpftrace -e \u0027tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }\u0027\n\nbpftrace would then go and generate a BPF program from this internally. One way\nof doing it [for the sake of the example] could be to call bpf_get_current_task()\nhelper and then access current-\u003ecomm via one of bpf_probe_read_kernel{,_str}()\nhelpers. So the program itself has nothing to do with httpd or any other random\napp doing a syscall here. The BPF program _explicitly initiated_ the lockdown\ncheck. The allow/deny policy belongs in the context of bpftrace: meaning, you\nwant to grant bpftrace access to use these helpers, but other tracers on the\nsystem like my_random_tracer _not_.\n\nTherefore fix all three issues at the same time by taking a completely different\napproach for the security_locked_down() hook, that is, move the check into the\nprogram verification phase where we actually retrieve the BPF func proto. This\nalso reliably gets the task (current) that is trying to install the BPF tracing\nprogram, e.g. bpftrace/bcc/perf/systemtap/etc, and it also fixes the OOM since\nwe\u0027re moving this out of the BPF helper\u0027s fast-path which can be called several\nmillions of times per second.\n\nThe check is then also in line with other security_locked_down() hooks in the\nsystem where the enforcement is performed at open/load time, for example,\nopen_kcore() for /proc/kcore access or module_sig_check() for module signatures\njust to pick f\n---truncated---",
"id": "GHSA-cr4c-ww97-fphq",
"modified": "2025-03-13T21:31:00Z",
"published": "2024-03-15T21:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47128"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/acc43fc6cf0d50612193813c5906a1ab9d433e1e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ff40e51043af63715ab413995ff46996ecf9583f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ff5039ec75c83d2ed5b781dc7733420ee8c985fc"
}
],
"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.