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-5822-38R8-R5P2
Vulnerability from github – Published: 2024-09-04 21:30 – Updated: 2024-11-08 18:30In the Linux kernel, the following vulnerability has been resolved:
driver core: Fix uevent_show() vs driver detach race
uevent_show() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct device_driver).dev_groups. Instead, the anti-pattern of taking the device_lock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock.
This deadlock is typically invisible to lockdep given the device_lock() is marked lockdep_set_novalidate_class(), but some subsystems allocate a local lockdep key for @dev->mutex to reveal reports of the form:
====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ #275 Tainted: G OE N
modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220
but task is already holding lock: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e
The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronize_rcu() in module_remove_driver() to close any potential races. It is potentially overkill to suffer synchronize_rcu() just to handle the rare module removal racing uevent_show() event.
Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1].
{
"affected": [],
"aliases": [
"CVE-2024-44952"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-04T19:15:30Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: Fix uevent_show() vs driver detach race\n\nuevent_show() wants to de-reference dev-\u003edriver-\u003ename. There is no clean\nway for a device attribute to de-reference dev-\u003edriver unless that\nattribute is defined via (struct device_driver).dev_groups. Instead, the\nanti-pattern of taking the device_lock() in the attribute handler risks\ndeadlocks with code paths that remove device attributes while holding\nthe lock.\n\nThis deadlock is typically invisible to lockdep given the device_lock()\nis marked lockdep_set_novalidate_class(), but some subsystems allocate a\nlocal lockdep key for @dev-\u003emutex to reveal reports of the form:\n\n ======================================================\n WARNING: possible circular locking dependency detected\n 6.10.0-rc7+ #275 Tainted: G OE N\n ------------------------------------------------------\n modprobe/2374 is trying to acquire lock:\n ffff8c2270070de0 (kn-\u003eactive#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220\n\n but task is already holding lock:\n ffff8c22016e88f8 (\u0026cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210\n\n which lock already depends on the new lock.\n\n the existing dependency chain (in reverse order) is:\n\n -\u003e #1 (\u0026cxl_root_key){+.+.}-{3:3}:\n __mutex_lock+0x99/0xc30\n uevent_show+0xac/0x130\n dev_attr_show+0x18/0x40\n sysfs_kf_seq_show+0xac/0xf0\n seq_read_iter+0x110/0x450\n vfs_read+0x25b/0x340\n ksys_read+0x67/0xf0\n do_syscall_64+0x75/0x190\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n -\u003e #0 (kn-\u003eactive#6){++++}-{0:0}:\n __lock_acquire+0x121a/0x1fa0\n lock_acquire+0xd6/0x2e0\n kernfs_drain+0x1e9/0x200\n __kernfs_remove+0xde/0x220\n kernfs_remove_by_name_ns+0x5e/0xa0\n device_del+0x168/0x410\n device_unregister+0x13/0x60\n devres_release_all+0xb8/0x110\n device_unbind_cleanup+0xe/0x70\n device_release_driver_internal+0x1c7/0x210\n driver_detach+0x47/0x90\n bus_remove_driver+0x6c/0xf0\n cxl_acpi_exit+0xc/0x11 [cxl_acpi]\n __do_sys_delete_module.isra.0+0x181/0x260\n do_syscall_64+0x75/0x190\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe observation though is that driver objects are typically much longer\nlived than device objects. It is reasonable to perform lockless\nde-reference of a @driver pointer even if it is racing detach from a\ndevice. Given the infrequency of driver unregistration, use\nsynchronize_rcu() in module_remove_driver() to close any potential\nraces. It is potentially overkill to suffer synchronize_rcu() just to\nhandle the rare module removal racing uevent_show() event.\n\nThanks to Tetsuo Handa for the debug analysis of the syzbot report [1].",
"id": "GHSA-5822-38r8-r5p2",
"modified": "2024-11-08T18:30:43Z",
"published": "2024-09-04T21:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44952"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/15fffc6a5624b13b428bb1c6e9088e32a55eb82c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1cfc329304617838dc06f021bbbde3bc79cd655e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4749d336170dbb629e515a857e58a82e61c37a9c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/49ea4e0d862632d51667da5e7a9c88a560e9c5a1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4a7c2a8387524942171037e70b80e969c3b5c05b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4d035c743c3e391728a6f81cbf0f7f9ca700cf62"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/92d847a35e1e41bceba13b8ac1f0e1b9dbe30d25"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9c23fc327d6ec67629b4ad323bd64d3834c0417d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cd490a247ddf325325fd0de8898659400c9237ef"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cfc72b86fa20cbf44d2b6cc27b35eb15080232ab"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d4dba9a076838f3d0333a6a66efec2cdda90b2ee"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dd98c9630b7ee273da87e9a244f94ddf947161e2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f098e8fc7227166206256c18d56ab622039108b1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fd28d9589460945985ef5333e9b942c4261f0826"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fe10c8367687c27172a10ba5cc849bd82077bd7d"
}
],
"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-58VG-W4WX-WP6P
Vulnerability from github – Published: 2025-07-25 15:30 – Updated: 2025-11-19 21:31In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_ffa: Replace mutex with rwlock to avoid sleep in atomic context
The current use of a mutex to protect the notifier hashtable accesses can lead to issues in the atomic context. It results in the below kernel warnings:
| BUG: sleeping function called from invalid context at kernel/locking/mutex.c:258 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 9, name: kworker/0:0 | preempt_count: 1, expected: 0 | RCU nest depth: 0, expected: 0 | CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.14.0 #4 | Workqueue: ffa_pcpu_irq_notification notif_pcpu_irq_work_fn | Call trace: | show_stack+0x18/0x24 (C) | dump_stack_lvl+0x78/0x90 | dump_stack+0x18/0x24 | __might_resched+0x114/0x170 | __might_sleep+0x48/0x98 | mutex_lock+0x24/0x80 | handle_notif_callbacks+0x54/0xe0 | notif_get_and_handle+0x40/0x88 | generic_exec_single+0x80/0xc0 | smp_call_function_single+0xfc/0x1a0 | notif_pcpu_irq_work_fn+0x2c/0x38 | process_one_work+0x14c/0x2b4 | worker_thread+0x2e4/0x3e0 | kthread+0x13c/0x210 | ret_from_fork+0x10/0x20
To address this, replace the mutex with an rwlock to protect the notifier hashtable accesses. This ensures that read-side locking does not sleep and multiple readers can acquire the lock concurrently, avoiding unnecessary contention and potential deadlocks. Writer access remains exclusive, preserving correctness.
This change resolves warnings from lockdep about potential sleep in atomic context.
{
"affected": [],
"aliases": [
"CVE-2025-38388"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-25T13:15:28Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: arm_ffa: Replace mutex with rwlock to avoid sleep in atomic context\n\nThe current use of a mutex to protect the notifier hashtable accesses\ncan lead to issues in the atomic context. It results in the below\nkernel warnings:\n\n | BUG: sleeping function called from invalid context at kernel/locking/mutex.c:258\n | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 9, name: kworker/0:0\n | preempt_count: 1, expected: 0\n | RCU nest depth: 0, expected: 0\n | CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.14.0 #4\n | Workqueue: ffa_pcpu_irq_notification notif_pcpu_irq_work_fn\n | Call trace:\n | show_stack+0x18/0x24 (C)\n | dump_stack_lvl+0x78/0x90\n | dump_stack+0x18/0x24\n | __might_resched+0x114/0x170\n | __might_sleep+0x48/0x98\n | mutex_lock+0x24/0x80\n | handle_notif_callbacks+0x54/0xe0\n | notif_get_and_handle+0x40/0x88\n | generic_exec_single+0x80/0xc0\n | smp_call_function_single+0xfc/0x1a0\n | notif_pcpu_irq_work_fn+0x2c/0x38\n | process_one_work+0x14c/0x2b4\n | worker_thread+0x2e4/0x3e0\n | kthread+0x13c/0x210\n | ret_from_fork+0x10/0x20\n\nTo address this, replace the mutex with an rwlock to protect the notifier\nhashtable accesses. This ensures that read-side locking does not sleep and\nmultiple readers can acquire the lock concurrently, avoiding unnecessary\ncontention and potential deadlocks. Writer access remains exclusive,\npreserving correctness.\n\nThis change resolves warnings from lockdep about potential sleep in\natomic context.",
"id": "GHSA-58vg-w4wx-wp6p",
"modified": "2025-11-19T21:31:16Z",
"published": "2025-07-25T15:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38388"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/31405510a48dcf054abfa5b7b8d70ce1b27d1f13"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8986f8f61b482c0e6efd28f0b2423d9640c20eb1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9ca7a421229bbdfbe2e1e628cff5cfa782720a10"
}
],
"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-59G4-MVCC-7P3X
Vulnerability from github – Published: 2025-04-16 15:34 – Updated: 2025-10-31 21:30In the Linux kernel, the following vulnerability has been resolved:
net: ibmveth: make veth_pool_store stop hanging
v2: - Created a single error handling unlock and exit in veth_pool_store - Greatly expanded commit message with previous explanatory-only text
Summary: Use rtnl_mutex to synchronize veth_pool_store with itself, ibmveth_close and ibmveth_open, preventing multiple calls in a row to napi_disable.
Background: Two (or more) threads could call veth_pool_store through writing to /sys/devices/vio/30000002/pool/. You can do this easily with a little shell script. This causes a hang.
I configured LOCKDEP, compiled ibmveth.c with DEBUG, and built a new kernel. I ran this test again and saw:
Setting pool0/active to 0
Setting pool1/active to 1
[ 73.911067][ T4365] ibmveth 30000002 eth0: close starting
Setting pool1/active to 1
Setting pool1/active to 0
[ 73.911367][ T4366] ibmveth 30000002 eth0: close starting
[ 73.916056][ T4365] ibmveth 30000002 eth0: close complete
[ 73.916064][ T4365] ibmveth 30000002 eth0: open starting
[ 110.808564][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification.
[ 230.808495][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification.
[ 243.683786][ T123] INFO: task stress.sh:4365 blocked for more than 122 seconds.
[ 243.683827][ T123] Not tainted 6.14.0-01103-g2df0c02dab82-dirty #8
[ 243.683833][ T123] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 243.683838][ T123] task:stress.sh state:D stack:28096 pid:4365 tgid:4365 ppid:4364 task_flags:0x400040 flags:0x00042000
[ 243.683852][ T123] Call Trace:
[ 243.683857][ T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable)
[ 243.683868][ T123] [c00000000c38f840] [c00000000001f908] __switch_to+0x318/0x4e0
[ 243.683878][ T123] [c00000000c38f8a0] [c000000001549a70] __schedule+0x500/0x12a0
[ 243.683888][ T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210
[ 243.683896][ T123] [c00000000c38f9d0] [c00000000154ac80] schedule_preempt_disabled+0x30/0x50
[ 243.683904][ T123] [c00000000c38fa00] [c00000000154dbb0] __mutex_lock+0x730/0x10f0
[ 243.683913][ T123] [c00000000c38fb10] [c000000001154d40] napi_enable+0x30/0x60
[ 243.683921][ T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc
[ 243.683928][ T123] [c00000000c38fbe0] [c000000000f4aa20] veth_pool_store+0x220/0x270
[ 243.683936][ T123] [c00000000c38fc70] [c000000000826278] sysfs_kf_write+0x68/0xb0
[ 243.683944][ T123] [c00000000c38fcb0] [c0000000008240b8] kernfs_fop_write_iter+0x198/0x2d0
[ 243.683951][ T123] [c00000000c38fd00] [c00000000071b9ac] vfs_write+0x34c/0x650
[ 243.683958][ T123] [c00000000c38fdc0] [c00000000071bea8] ksys_write+0x88/0x150
[ 243.683966][ T123] [c00000000c38fe10] [c0000000000317f4] system_call_exception+0x124/0x340
[ 243.683973][ T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec
...
[ 243.684087][ T123] Showing all locks held in the system:
[ 243.684095][ T123] 1 lock held by khungtaskd/123:
[ 243.684099][ T123] #0: c00000000278e370 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x50/0x248
[ 243.684114][ T123] 4 locks held by stress.sh/4365:
[ 243.684119][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150
[ 243.684132][ T123] #1: c000000041aea888 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0
[ 243.684143][ T123] #2: c0000000366fb9a8 (kn->active#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0
[ 243.684155][ T123] #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, at: napi_enable+0x30/0x60
[ 243.684166][ T123] 5 locks held by stress.sh/4366:
[ 243.684170][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150
[ 243.
---truncated---
{
"affected": [],
"aliases": [
"CVE-2025-22053"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-16T15:15:58Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ibmveth: make veth_pool_store stop hanging\n\nv2:\n- Created a single error handling unlock and exit in veth_pool_store\n- Greatly expanded commit message with previous explanatory-only text\n\nSummary: Use rtnl_mutex to synchronize veth_pool_store with itself,\nibmveth_close and ibmveth_open, preventing multiple calls in a row to\nnapi_disable.\n\nBackground: Two (or more) threads could call veth_pool_store through\nwriting to /sys/devices/vio/30000002/pool*/*. You can do this easily\nwith a little shell script. This causes a hang.\n\nI configured LOCKDEP, compiled ibmveth.c with DEBUG, and built a new\nkernel. I ran this test again and saw:\n\n Setting pool0/active to 0\n Setting pool1/active to 1\n [ 73.911067][ T4365] ibmveth 30000002 eth0: close starting\n Setting pool1/active to 1\n Setting pool1/active to 0\n [ 73.911367][ T4366] ibmveth 30000002 eth0: close starting\n [ 73.916056][ T4365] ibmveth 30000002 eth0: close complete\n [ 73.916064][ T4365] ibmveth 30000002 eth0: open starting\n [ 110.808564][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification.\n [ 230.808495][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification.\n [ 243.683786][ T123] INFO: task stress.sh:4365 blocked for more than 122 seconds.\n [ 243.683827][ T123] Not tainted 6.14.0-01103-g2df0c02dab82-dirty #8\n [ 243.683833][ T123] \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n [ 243.683838][ T123] task:stress.sh state:D stack:28096 pid:4365 tgid:4365 ppid:4364 task_flags:0x400040 flags:0x00042000\n [ 243.683852][ T123] Call Trace:\n [ 243.683857][ T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable)\n [ 243.683868][ T123] [c00000000c38f840] [c00000000001f908] __switch_to+0x318/0x4e0\n [ 243.683878][ T123] [c00000000c38f8a0] [c000000001549a70] __schedule+0x500/0x12a0\n [ 243.683888][ T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210\n [ 243.683896][ T123] [c00000000c38f9d0] [c00000000154ac80] schedule_preempt_disabled+0x30/0x50\n [ 243.683904][ T123] [c00000000c38fa00] [c00000000154dbb0] __mutex_lock+0x730/0x10f0\n [ 243.683913][ T123] [c00000000c38fb10] [c000000001154d40] napi_enable+0x30/0x60\n [ 243.683921][ T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc\n [ 243.683928][ T123] [c00000000c38fbe0] [c000000000f4aa20] veth_pool_store+0x220/0x270\n [ 243.683936][ T123] [c00000000c38fc70] [c000000000826278] sysfs_kf_write+0x68/0xb0\n [ 243.683944][ T123] [c00000000c38fcb0] [c0000000008240b8] kernfs_fop_write_iter+0x198/0x2d0\n [ 243.683951][ T123] [c00000000c38fd00] [c00000000071b9ac] vfs_write+0x34c/0x650\n [ 243.683958][ T123] [c00000000c38fdc0] [c00000000071bea8] ksys_write+0x88/0x150\n [ 243.683966][ T123] [c00000000c38fe10] [c0000000000317f4] system_call_exception+0x124/0x340\n [ 243.683973][ T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec\n ...\n [ 243.684087][ T123] Showing all locks held in the system:\n [ 243.684095][ T123] 1 lock held by khungtaskd/123:\n [ 243.684099][ T123] #0: c00000000278e370 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x50/0x248\n [ 243.684114][ T123] 4 locks held by stress.sh/4365:\n [ 243.684119][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150\n [ 243.684132][ T123] #1: c000000041aea888 (\u0026of-\u003emutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0\n [ 243.684143][ T123] #2: c0000000366fb9a8 (kn-\u003eactive#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0\n [ 243.684155][ T123] #3: c000000035ff4cb8 (\u0026dev-\u003elock){+.+.}-{3:3}, at: napi_enable+0x30/0x60\n [ 243.684166][ T123] 5 locks held by stress.sh/4366:\n [ 243.684170][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150\n [ 243.\n---truncated---",
"id": "GHSA-59g4-mvcc-7p3x",
"modified": "2025-10-31T21:30:54Z",
"published": "2025-04-16T15:34:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22053"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/053f3ff67d7feefc75797863f3d84b47ad47086f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0a2470e3ecde64fc7e3781dc474923193621ae67"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e458c292f4c687dcf5aad32dd4836d03cd2191f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/86cc70f5c85dc09bf7f3e1eee380eefe73c90765"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8a88bb092f4208355880b9fdcc69d491aa297595"
}
],
"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-59HF-6V72-VM3M
Vulnerability from github – Published: 2024-05-20 12:30 – Updated: 2025-09-24 18:30In the Linux kernel, the following vulnerability has been resolved:
net: ks8851: Handle softirqs at the end of IRQ thread to fix hang
The ks8851_irq() thread may call ks8851_rx_pkts() in case there are any packets in the MAC FIFO, which calls netif_rx(). This netif_rx() implementation is guarded by local_bh_disable() and local_bh_enable(). The local_bh_enable() may call do_softirq() to run softirqs in case any are pending. One of the softirqs is net_rx_action, which ultimately reaches the driver .start_xmit callback. If that happens, the system hangs. The entire call chain is below:
ks8851_start_xmit_par from netdev_start_xmit netdev_start_xmit from dev_hard_start_xmit dev_hard_start_xmit from sch_direct_xmit sch_direct_xmit from __dev_queue_xmit __dev_queue_xmit from __neigh_update __neigh_update from neigh_update neigh_update from arp_process.constprop.0 arp_process.constprop.0 from __netif_receive_skb_one_core __netif_receive_skb_one_core from process_backlog process_backlog from __napi_poll.constprop.0 __napi_poll.constprop.0 from net_rx_action net_rx_action from __do_softirq __do_softirq from call_with_stack call_with_stack from do_softirq do_softirq from __local_bh_enable_ip __local_bh_enable_ip from netif_rx netif_rx from ks8851_irq ks8851_irq from irq_thread_fn irq_thread_fn from irq_thread irq_thread from kthread kthread from ret_from_fork
The hang happens because ks8851_irq() first locks a spinlock in ks8851_par.c ks8851_lock_par() spin_lock_irqsave(&ksp->lock, ...) and with that spinlock locked, calls netif_rx(). Once the execution reaches ks8851_start_xmit_par(), it calls ks8851_lock_par() again which attempts to claim the already locked spinlock again, and the hang happens.
Move the do_softirq() call outside of the spinlock protected section of ks8851_irq() by disabling BHs around the entire spinlock protected section of ks8851_irq() handler. Place local_bh_enable() outside of the spinlock protected section, so that it can trigger do_softirq() without the ks8851_par.c ks8851_lock_par() spinlock being held, and safely call ks8851_start_xmit_par() without attempting to lock the already locked spinlock.
Since ks8851_irq() is protected by local_bh_disable()/local_bh_enable() now, replace netif_rx() with __netif_rx() which is not duplicating the local_bh_disable()/local_bh_enable() calls.
{
"affected": [],
"aliases": [
"CVE-2024-35971"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-20T10:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ks8851: Handle softirqs at the end of IRQ thread to fix hang\n\nThe ks8851_irq() thread may call ks8851_rx_pkts() in case there are\nany packets in the MAC FIFO, which calls netif_rx(). This netif_rx()\nimplementation is guarded by local_bh_disable() and local_bh_enable().\nThe local_bh_enable() may call do_softirq() to run softirqs in case\nany are pending. One of the softirqs is net_rx_action, which ultimately\nreaches the driver .start_xmit callback. If that happens, the system\nhangs. The entire call chain is below:\n\nks8851_start_xmit_par from netdev_start_xmit\nnetdev_start_xmit from dev_hard_start_xmit\ndev_hard_start_xmit from sch_direct_xmit\nsch_direct_xmit from __dev_queue_xmit\n__dev_queue_xmit from __neigh_update\n__neigh_update from neigh_update\nneigh_update from arp_process.constprop.0\narp_process.constprop.0 from __netif_receive_skb_one_core\n__netif_receive_skb_one_core from process_backlog\nprocess_backlog from __napi_poll.constprop.0\n__napi_poll.constprop.0 from net_rx_action\nnet_rx_action from __do_softirq\n__do_softirq from call_with_stack\ncall_with_stack from do_softirq\ndo_softirq from __local_bh_enable_ip\n__local_bh_enable_ip from netif_rx\nnetif_rx from ks8851_irq\nks8851_irq from irq_thread_fn\nirq_thread_fn from irq_thread\nirq_thread from kthread\nkthread from ret_from_fork\n\nThe hang happens because ks8851_irq() first locks a spinlock in\nks8851_par.c ks8851_lock_par() spin_lock_irqsave(\u0026ksp-\u003elock, ...)\nand with that spinlock locked, calls netif_rx(). Once the execution\nreaches ks8851_start_xmit_par(), it calls ks8851_lock_par() again\nwhich attempts to claim the already locked spinlock again, and the\nhang happens.\n\nMove the do_softirq() call outside of the spinlock protected section\nof ks8851_irq() by disabling BHs around the entire spinlock protected\nsection of ks8851_irq() handler. Place local_bh_enable() outside of\nthe spinlock protected section, so that it can trigger do_softirq()\nwithout the ks8851_par.c ks8851_lock_par() spinlock being held, and\nsafely call ks8851_start_xmit_par() without attempting to lock the\nalready locked spinlock.\n\nSince ks8851_irq() is protected by local_bh_disable()/local_bh_enable()\nnow, replace netif_rx() with __netif_rx() which is not duplicating the\nlocal_bh_disable()/local_bh_enable() calls.",
"id": "GHSA-59hf-6v72-vm3m",
"modified": "2025-09-24T18:30:22Z",
"published": "2024-05-20T12:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35971"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/492337a4fbd1421b42df684ee9b34be2a2722540"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/49d5d70538b6b8f2a3f8f1ac30c1f921d4a0929b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be0384bf599cf1eb8d337517feeb732d71f75a6f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cba376eb036c2c20077b41d47b317d8218fe754f"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/05/30/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/05/30/2"
}
],
"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-5C36-JX4M-M84F
Vulnerability from github – Published: 2026-05-06 12:30 – Updated: 2026-05-13 21:31In the Linux kernel, the following vulnerability has been resolved:
Revert "PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV"
This reverts commit 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV"), which causes a deadlock by recursively taking pci_rescan_remove_lock when sriov_del_vfs() is called as part of pci_stop_and_remove_bus_device(). For example with the following sequence of commands:
$ echo > /sys/bus/pci/devices//sriov_numvfs $ echo 1 > /sys/bus/pci/devices//remove
A trimmed trace of the deadlock on a mlx5 device is as below:
zsh/5715 is trying to acquire lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: sriov_disable+0x34/0x140
but task is already holding lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_stop_and_remove_bus_device_locked+0x24/0x80 ... Call Trace: [<00000259778c4f90>] dump_stack_lvl+0xc0/0x110 [<00000259779c844e>] print_deadlock_bug+0x31e/0x330 [<00000259779c1908>] __lock_acquire+0x16c8/0x32f0 [<00000259779bffac>] lock_acquire+0x14c/0x350 [<00000259789643a6>] __mutex_lock_common+0xe6/0x1520 [<000002597896413c>] mutex_lock_nested+0x3c/0x50 [<00000259784a07e4>] sriov_disable+0x34/0x140 [<00000258f7d6dd80>] mlx5_sriov_disable+0x50/0x80 [mlx5_core] [<00000258f7d5745e>] remove_one+0x5e/0xf0 [mlx5_core] [<00000259784857fc>] pci_device_remove+0x3c/0xa0 [<000002597851012e>] device_release_driver_internal+0x18e/0x280 [<000002597847ae22>] pci_stop_bus_device+0x82/0xa0 [<000002597847afce>] pci_stop_and_remove_bus_device_locked+0x5e/0x80 [<00000259784972c2>] remove_store+0x72/0x90 [<0000025977e6661a>] kernfs_fop_write_iter+0x15a/0x200 [<0000025977d7241c>] vfs_write+0x24c/0x300 [<0000025977d72696>] ksys_write+0x86/0x110 [<000002597895b61c>] __do_syscall+0x14c/0x400 [<000002597896e0ee>] system_call+0x6e/0x90
This alone is not a complete fix as it restores the issue the cited commit tried to solve. A new fix will be provided as a follow on.
{
"affected": [],
"aliases": [
"CVE-2026-43147"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-06T12:16:32Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV\"\n\nThis reverts commit 05703271c3cd (\"PCI/IOV: Add PCI rescan-remove locking\nwhen enabling/disabling SR-IOV\"), which causes a deadlock by recursively\ntaking pci_rescan_remove_lock when sriov_del_vfs() is called as part of\npci_stop_and_remove_bus_device(). For example with the following sequence\nof commands:\n\n $ echo \u003cNUM\u003e \u003e /sys/bus/pci/devices/\u003cpf\u003e/sriov_numvfs\n $ echo 1 \u003e /sys/bus/pci/devices/\u003cpf\u003e/remove\n\nA trimmed trace of the deadlock on a mlx5 device is as below:\n\n zsh/5715 is trying to acquire lock:\n 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: sriov_disable+0x34/0x140\n\n but task is already holding lock:\n 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_stop_and_remove_bus_device_locked+0x24/0x80\n ...\n Call Trace:\n [\u003c00000259778c4f90\u003e] dump_stack_lvl+0xc0/0x110\n [\u003c00000259779c844e\u003e] print_deadlock_bug+0x31e/0x330\n [\u003c00000259779c1908\u003e] __lock_acquire+0x16c8/0x32f0\n [\u003c00000259779bffac\u003e] lock_acquire+0x14c/0x350\n [\u003c00000259789643a6\u003e] __mutex_lock_common+0xe6/0x1520\n [\u003c000002597896413c\u003e] mutex_lock_nested+0x3c/0x50\n [\u003c00000259784a07e4\u003e] sriov_disable+0x34/0x140\n [\u003c00000258f7d6dd80\u003e] mlx5_sriov_disable+0x50/0x80 [mlx5_core]\n [\u003c00000258f7d5745e\u003e] remove_one+0x5e/0xf0 [mlx5_core]\n [\u003c00000259784857fc\u003e] pci_device_remove+0x3c/0xa0\n [\u003c000002597851012e\u003e] device_release_driver_internal+0x18e/0x280\n [\u003c000002597847ae22\u003e] pci_stop_bus_device+0x82/0xa0\n [\u003c000002597847afce\u003e] pci_stop_and_remove_bus_device_locked+0x5e/0x80\n [\u003c00000259784972c2\u003e] remove_store+0x72/0x90\n [\u003c0000025977e6661a\u003e] kernfs_fop_write_iter+0x15a/0x200\n [\u003c0000025977d7241c\u003e] vfs_write+0x24c/0x300\n [\u003c0000025977d72696\u003e] ksys_write+0x86/0x110\n [\u003c000002597895b61c\u003e] __do_syscall+0x14c/0x400\n [\u003c000002597896e0ee\u003e] system_call+0x6e/0x90\n\nThis alone is not a complete fix as it restores the issue the cited commit\ntried to solve. A new fix will be provided as a follow on.",
"id": "GHSA-5c36-jx4m-m84f",
"modified": "2026-05-13T21:31:58Z",
"published": "2026-05-06T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43147"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0de341b2365bad430aade0853fe09c2cbe468f59"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2fa119c0e5e528453ebae9e70740e8d2d8c0ed5a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/40f67686a5002c0c322fac918406bbc8d9c2ec2f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/58677783c89681871077f50a7042b0c6380c4fd8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/639265296fe6ee21b6f00e00ee2bab65f3b07252"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/83651d37474c762920e345a3a0828f975ca4d732"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d47f27e145f8bd13f3c230da5e3af29225b4a2f7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f61cdd7e9b67bb8961b0a81bf294b78343e5db05"
}
],
"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-5FJR-C5P8-HXVJ
Vulnerability from github – Published: 2022-05-24 19:10 – Updated: 2022-05-24 19:10btrfs in the Linux kernel before 5.13.4 allows attackers to cause a denial of service (deadlock) via processes that trigger allocation of new system chunks during times when there is a shortage of free space in the system space_info.
{
"affected": [],
"aliases": [
"CVE-2021-38203"
],
"database_specific": {
"cwe_ids": [
"CWE-667",
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-08T20:15:00Z",
"severity": "MODERATE"
},
"details": "btrfs in the Linux kernel before 5.13.4 allows attackers to cause a denial of service (deadlock) via processes that trigger allocation of new system chunks during times when there is a shortage of free space in the system space_info.",
"id": "GHSA-5fjr-c5p8-hxvj",
"modified": "2022-05-24T19:10:23Z",
"published": "2022-05-24T19:10:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38203"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/1cb3db1cf383a3c7dbda1aa0ce748b0958759947"
},
{
"type": "WEB",
"url": "https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.13.4"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210902-0010"
}
],
"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-5FXQ-3R3P-42M4
Vulnerability from github – Published: 2022-04-30 18:13 – Updated: 2024-02-08 21:30Concurrent Versions Software (CVS) uses predictable temporary file names for locking, which allows local users to cause a denial of service by creating the lock directory before it is created for use by a legitimate CVS user.
{
"affected": [],
"aliases": [
"CVE-2000-0338"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2000-04-23T04:00:00Z",
"severity": "MODERATE"
},
"details": "Concurrent Versions Software (CVS) uses predictable temporary file names for locking, which allows local users to cause a denial of service by creating the lock directory before it is created for use by a legitimate CVS user.",
"id": "GHSA-5fxq-3r3p-42m4",
"modified": "2024-02-08T21:30:28Z",
"published": "2022-04-30T18:13:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2000-0338"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/1136"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/frames/?content=/templates/archive.pike%3Flist%3D1%26msg%3D20000423174038.A520%40clico.pl"
}
],
"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-5GR3-HCQ9-FP58
Vulnerability from github – Published: 2022-05-24 19:05 – Updated: 2022-05-24 19:05In memory management driver, there is a possible memory corruption due to improper locking. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android SoCAndroid ID: A-185195268
{
"affected": [],
"aliases": [
"CVE-2021-0529"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-21T17:15:00Z",
"severity": "HIGH"
},
"details": "In memory management driver, there is a possible memory corruption due to improper locking. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android SoCAndroid ID: A-185195268",
"id": "GHSA-5gr3-hcq9-fp58",
"modified": "2022-05-24T19:05:42Z",
"published": "2022-05-24T19:05:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0529"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2021-06-01"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-5H69-GPMH-V98W
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-16 03:30In the Linux kernel, the following vulnerability has been resolved:
x86/shstk: Prevent deadlock during shstk sigreturn
During sigreturn the shadow stack signal frame is popped. The kernel does this by reading the shadow stack using normal read accesses. When it can't assume the memory is shadow stack, it takes extra steps to makes sure it is reading actual shadow stack memory and not other normal readable memory. It does this by holding the mmap read lock while doing the access and checking the flags of the VMA.
Unfortunately that is not safe. If the read of the shadow stack sigframe hits a page fault, the fault handler will try to recursively grab another mmap read lock. This normally works ok, but if a writer on another CPU is also waiting, the second read lock could fail and cause a deadlock.
Fix this by not holding mmap lock during the read access to userspace.
Instead use mmap_lock_speculate_...() to watch for changes between dropping mmap lock and the userspace access. Retry if anything grabbed an mmap write lock in between and could have changed the VMA.
These mmap_lock_speculate_...() helpers use mm::mm_lock_seq, which is only available when PER_VMA_LOCK is configured. So make X86_USER_SHADOW_STACK depend on it. On x86, PER_VMA_LOCK is a default configuration for SMP kernels. So drop support for the other configs under the assumption that the !SMP shadow stack user base does not exist.
Currently there is a check that skips the lookup work when the SSP can be assumed to be on a shadow stack. While reorganizing the function, remove the optimization to make the tricky code flows more common, such that issues like this cannot escape detection for so long.
{
"affected": [],
"aliases": [
"CVE-2026-46063"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:26Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/shstk: Prevent deadlock during shstk sigreturn\n\nDuring sigreturn the shadow stack signal frame is popped. The kernel does\nthis by reading the shadow stack using normal read accesses. When it can\u0027t\nassume the memory is shadow stack, it takes extra steps to makes sure it is\nreading actual shadow stack memory and not other normal readable memory. It\ndoes this by holding the mmap read lock while doing the access and checking\nthe flags of the VMA.\n\nUnfortunately that is not safe. If the read of the shadow stack sigframe\nhits a page fault, the fault handler will try to recursively grab another\nmmap read lock. This normally works ok, but if a writer on another CPU is\nalso waiting, the second read lock could fail and cause a deadlock.\n\nFix this by not holding mmap lock during the read access to userspace.\n\nInstead use mmap_lock_speculate_...() to watch for changes between dropping\nmmap lock and the userspace access. Retry if anything grabbed an mmap write\nlock in between and could have changed the VMA.\n\nThese mmap_lock_speculate_...() helpers use mm::mm_lock_seq, which is only\navailable when PER_VMA_LOCK is configured. So make X86_USER_SHADOW_STACK\ndepend on it. On x86, PER_VMA_LOCK is a default configuration for SMP\nkernels. So drop support for the other configs under the assumption that\nthe !SMP shadow stack user base does not exist.\n\nCurrently there is a check that skips the lookup work when the SSP can be\nassumed to be on a shadow stack. While reorganizing the function, remove\nthe optimization to make the tricky code flows more common, such that\nissues like this cannot escape detection for so long.",
"id": "GHSA-5h69-gpmh-v98w",
"modified": "2026-06-16T03:30:34Z",
"published": "2026-05-27T15:33:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46063"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3d29db827502067626062f5c74dd502d14ab15bc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4f3374c990fb2adec06d20fd6d780927811c9aa0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9874b2917b9fbc30956fee209d3c4aa47201c64e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d042d69b417515959e49021fef008c9b04a99bd5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e2c2b044458cbf22da05264fa707308e8d4f86f9"
}
],
"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-5HMX-W727-FQQ7
Vulnerability from github – Published: 2024-05-21 15:31 – Updated: 2024-11-05 00:31In the Linux kernel, the following vulnerability has been resolved:
powerpc/mm: Fix lockup on kernel exec fault
The powerpc kernel is not prepared to handle exec faults from kernel. Especially, the function is_exec_fault() will return 'false' when an exec fault is taken by kernel, because the check is based on reading current->thread.regs->trap which contains the trap from user.
For instance, when provoking a LKDTM EXEC_USERSPACE test, current->thread.regs->trap is set to SYSCALL trap (0xc00), and the fault taken by the kernel is not seen as an exec fault by set_access_flags_filter().
Commit d7df2443cd5f ("powerpc/mm: Fix spurious segfaults on radix with autonuma") made it clear and handled it properly. But later on commit d3ca587404b3 ("powerpc/mm: Fix reporting of kernel execute faults") removed that handling, introducing test based on error_code. And here is the problem, because on the 603 all upper bits of SRR1 get cleared when the TLB instruction miss handler bails out to ISI.
Until commit cbd7e6ca0210 ("powerpc/fault: Avoid heavy search_exception_tables() verification"), an exec fault from kernel at a userspace address was indirectly caught by the lack of entry for that address in the exception tables. But after that commit the kernel mainly relies on KUAP or on core mm handling to catch wrong user accesses. Here the access is not wrong, so mm handles it. It is a minor fault because PAGE_EXEC is not set, set_access_flags_filter() should set PAGE_EXEC and voila. But as is_exec_fault() returns false as explained in the beginning, set_access_flags_filter() bails out without setting PAGE_EXEC flag, which leads to a forever minor exec fault.
As the kernel is not prepared to handle such exec faults, the thing to do is to fire in bad_kernel_fault() for any exec fault taken by the kernel, as it was prior to commit d3ca587404b3.
{
"affected": [],
"aliases": [
"CVE-2021-47350"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T15:15:21Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/mm: Fix lockup on kernel exec fault\n\nThe powerpc kernel is not prepared to handle exec faults from kernel.\nEspecially, the function is_exec_fault() will return \u0027false\u0027 when an\nexec fault is taken by kernel, because the check is based on reading\ncurrent-\u003ethread.regs-\u003etrap which contains the trap from user.\n\nFor instance, when provoking a LKDTM EXEC_USERSPACE test,\ncurrent-\u003ethread.regs-\u003etrap is set to SYSCALL trap (0xc00), and\nthe fault taken by the kernel is not seen as an exec fault by\nset_access_flags_filter().\n\nCommit d7df2443cd5f (\"powerpc/mm: Fix spurious segfaults on radix\nwith autonuma\") made it clear and handled it properly. But later on\ncommit d3ca587404b3 (\"powerpc/mm: Fix reporting of kernel execute\nfaults\") removed that handling, introducing test based on error_code.\nAnd here is the problem, because on the 603 all upper bits of SRR1\nget cleared when the TLB instruction miss handler bails out to ISI.\n\nUntil commit cbd7e6ca0210 (\"powerpc/fault: Avoid heavy\nsearch_exception_tables() verification\"), an exec fault from kernel\nat a userspace address was indirectly caught by the lack of entry for\nthat address in the exception tables. But after that commit the\nkernel mainly relies on KUAP or on core mm handling to catch wrong\nuser accesses. Here the access is not wrong, so mm handles it.\nIt is a minor fault because PAGE_EXEC is not set,\nset_access_flags_filter() should set PAGE_EXEC and voila.\nBut as is_exec_fault() returns false as explained in the beginning,\nset_access_flags_filter() bails out without setting PAGE_EXEC flag,\nwhich leads to a forever minor exec fault.\n\nAs the kernel is not prepared to handle such exec faults, the thing to\ndo is to fire in bad_kernel_fault() for any exec fault taken by the\nkernel, as it was prior to commit d3ca587404b3.",
"id": "GHSA-5hmx-w727-fqq7",
"modified": "2024-11-05T00:31:27Z",
"published": "2024-05-21T15:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47350"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/500f81cec9f1bfa5210aa9dd5ba9a06e22f62a35"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8a96ec5ebf96ad8e2ba7b1b34103a0be5140fc70"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a82471a14aad90f79d1608d2bcbb019f0ffb53f0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cd5d5e602f502895e47e18cd46804d6d7014e65c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d2e52d4664097a6c1f591d869ec594bd7a0d4925"
}
],
"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.