CWE-667
Allowed-with-ReviewImproper Locking
Abstraction: Class · Status: Draft
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
713 vulnerabilities reference this CWE, most recent first.
GHSA-G6F8-F8F2-6WH5
Vulnerability from github – Published: 2025-01-11 15:30 – Updated: 2025-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
i3c: Use i3cdev->desc->info instead of calling i3c_device_get_info() to avoid deadlock
A deadlock may happen since the i3c_master_register() acquires &i3cbus->lock twice. See the log below. Use i3cdev->desc->info instead of calling i3c_device_info() to avoid acquiring the lock twice.
v2: - Modified the title and commit message
============================================ WARNING: possible recursive locking detected 6.11.0-mainline
init/1 is trying to acquire lock: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_bus_normaluse_lock
but task is already holding lock: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_master_register
other info that might help us debug this: Possible unsafe locking scenario:
CPU0
----
lock(&i3cbus->lock); lock(&i3cbus->lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by init/1: #0: fcffff809b6798f8 (&dev->mutex){....}-{3:3}, at: __driver_attach #1: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_master_register
stack backtrace: CPU: 6 UID: 0 PID: 1 Comm: init Call trace: dump_backtrace+0xfc/0x17c show_stack+0x18/0x28 dump_stack_lvl+0x40/0xc0 dump_stack+0x18/0x24 print_deadlock_bug+0x388/0x390 __lock_acquire+0x18bc/0x32ec lock_acquire+0x134/0x2b0 down_read+0x50/0x19c i3c_bus_normaluse_lock+0x14/0x24 i3c_device_get_info+0x24/0x58 i3c_device_uevent+0x34/0xa4 dev_uevent+0x310/0x384 kobject_uevent_env+0x244/0x414 kobject_uevent+0x14/0x20 device_add+0x278/0x460 device_register+0x20/0x34 i3c_master_register_new_i3c_devs+0x78/0x154 i3c_master_register+0x6a0/0x6d4 mtk_i3c_master_probe+0x3b8/0x4d8 platform_probe+0xa0/0xe0 really_probe+0x114/0x454 __driver_probe_device+0xa0/0x15c driver_probe_device+0x3c/0x1ac __driver_attach+0xc4/0x1f0 bus_for_each_dev+0x104/0x160 driver_attach+0x24/0x34 bus_add_driver+0x14c/0x294 driver_register+0x68/0x104 __platform_driver_register+0x20/0x30 init_module+0x20/0xfe4 do_one_initcall+0x184/0x464 do_init_module+0x58/0x1ec load_module+0xefc/0x10c8 __arm64_sys_finit_module+0x238/0x33c invoke_syscall+0x58/0x10c el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x50/0xac el0t_64_sync_handler+0x70/0xbc el0t_64_sync+0x1a8/0x1ac
{
"affected": [],
"aliases": [
"CVE-2024-43098"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-11T13:15:21Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ni3c: Use i3cdev-\u003edesc-\u003einfo instead of calling i3c_device_get_info() to avoid deadlock\n\nA deadlock may happen since the i3c_master_register() acquires\n\u0026i3cbus-\u003elock twice. See the log below.\nUse i3cdev-\u003edesc-\u003einfo instead of calling i3c_device_info() to\navoid acquiring the lock twice.\n\nv2:\n - Modified the title and commit message\n\n============================================\nWARNING: possible recursive locking detected\n6.11.0-mainline\n--------------------------------------------\ninit/1 is trying to acquire lock:\nf1ffff80a6a40dc0 (\u0026i3cbus-\u003elock){++++}-{3:3}, at: i3c_bus_normaluse_lock\n\nbut task is already holding lock:\nf1ffff80a6a40dc0 (\u0026i3cbus-\u003elock){++++}-{3:3}, at: i3c_master_register\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(\u0026i3cbus-\u003elock);\n lock(\u0026i3cbus-\u003elock);\n\n *** DEADLOCK ***\n\n May be due to missing lock nesting notation\n\n2 locks held by init/1:\n #0: fcffff809b6798f8 (\u0026dev-\u003emutex){....}-{3:3}, at: __driver_attach\n #1: f1ffff80a6a40dc0 (\u0026i3cbus-\u003elock){++++}-{3:3}, at: i3c_master_register\n\nstack backtrace:\nCPU: 6 UID: 0 PID: 1 Comm: init\nCall trace:\n dump_backtrace+0xfc/0x17c\n show_stack+0x18/0x28\n dump_stack_lvl+0x40/0xc0\n dump_stack+0x18/0x24\n print_deadlock_bug+0x388/0x390\n __lock_acquire+0x18bc/0x32ec\n lock_acquire+0x134/0x2b0\n down_read+0x50/0x19c\n i3c_bus_normaluse_lock+0x14/0x24\n i3c_device_get_info+0x24/0x58\n i3c_device_uevent+0x34/0xa4\n dev_uevent+0x310/0x384\n kobject_uevent_env+0x244/0x414\n kobject_uevent+0x14/0x20\n device_add+0x278/0x460\n device_register+0x20/0x34\n i3c_master_register_new_i3c_devs+0x78/0x154\n i3c_master_register+0x6a0/0x6d4\n mtk_i3c_master_probe+0x3b8/0x4d8\n platform_probe+0xa0/0xe0\n really_probe+0x114/0x454\n __driver_probe_device+0xa0/0x15c\n driver_probe_device+0x3c/0x1ac\n __driver_attach+0xc4/0x1f0\n bus_for_each_dev+0x104/0x160\n driver_attach+0x24/0x34\n bus_add_driver+0x14c/0x294\n driver_register+0x68/0x104\n __platform_driver_register+0x20/0x30\n init_module+0x20/0xfe4\n do_one_initcall+0x184/0x464\n do_init_module+0x58/0x1ec\n load_module+0xefc/0x10c8\n __arm64_sys_finit_module+0x238/0x33c\n invoke_syscall+0x58/0x10c\n el0_svc_common+0xa8/0xdc\n do_el0_svc+0x1c/0x28\n el0_svc+0x50/0xac\n el0t_64_sync_handler+0x70/0xbc\n el0t_64_sync+0x1a8/0x1ac",
"id": "GHSA-g6f8-f8f2-6wh5",
"modified": "2025-11-03T21:32:07Z",
"published": "2025-01-11T15:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43098"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f51ae217d09c361ede900b94735a6d2df6c0344"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2d98fa2a50b8058de52ada168fa5dbabb574711b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5ac1dd51aaa0ce8b5421d1137e857955a4b6f55e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6cf7b65f7029914dc0cd7db86fac9ee5159008c6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/816187b1833908941286e71b0041059a4acd52ed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9a2173660ee53d5699744f02e6ab7bf89fcd0b1a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ffe19e363c6f8b992ba835a361542568dea17409"
},
{
"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-G6HH-758M-XQ4Q
Vulnerability from github – Published: 2026-03-25 12:30 – Updated: 2026-05-29 15:30In the Linux kernel, the following vulnerability has been resolved:
accel/amdxdna: Fix dead lock for suspend and resume
When an application issues a query IOCTL while auto suspend is running, a deadlock can occur. The query path holds dev_lock and then calls pm_runtime_resume_and_get(), which waits for the ongoing suspend to complete. Meanwhile, the suspend callback attempts to acquire dev_lock and blocks, resulting in a deadlock.
Fix this by releasing dev_lock before calling pm_runtime_resume_and_get() and reacquiring it after the call completes. Also acquire dev_lock in the resume callback to keep the locking consistent.
{
"affected": [],
"aliases": [
"CVE-2026-23295"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-25T11:16:24Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\naccel/amdxdna: Fix dead lock for suspend and resume\n\nWhen an application issues a query IOCTL while auto suspend is running,\na deadlock can occur. The query path holds dev_lock and then calls\npm_runtime_resume_and_get(), which waits for the ongoing suspend to\ncomplete. Meanwhile, the suspend callback attempts to acquire dev_lock\nand blocks, resulting in a deadlock.\n\nFix this by releasing dev_lock before calling pm_runtime_resume_and_get()\nand reacquiring it after the call completes. Also acquire dev_lock in the\nresume callback to keep the locking consistent.",
"id": "GHSA-g6hh-758m-xq4q",
"modified": "2026-05-29T15:30:26Z",
"published": "2026-03-25T12:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23295"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1aa82181a3c285c7351523d587f7981ae4c015c8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ac24537478dd8eb2fd3984b4652bb19461e5e74c"
}
],
"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-G72F-6G67-W739
Vulnerability from github – Published: 2025-07-10 09:32 – Updated: 2025-11-18 15:30In the Linux kernel, the following vulnerability has been resolved:
iavf: get rid of the crit lock
Get rid of the crit lock. That frees us from the error prone logic of try_locks.
Thanks to netdev_lock() by Jakub it is now easy, and in most cases we were protected by it already - replace crit lock by netdev lock when it was not the case.
Lockdep reports that we should cancel the work under crit_lock [splat1], and that was the scheme we have mostly followed since [1] by Slawomir. But when that is done we still got into deadlocks [splat2]. So instead we should look at the bigger problem, namely "weird locking/scheduling" of the iavf. The first step to fix that is to remove the crit lock. I will followup with a -next series that simplifies scheduling/tasks.
Cancel the work without netdev lock (weird unlock+lock scheme), to fix the [splat2] (which would be totally ugly if we would kept the crit lock).
Extend protected part of iavf_watchdog_task() to include scheduling more work.
Note that the removed comment in iavf_reset_task() was misplaced, it belonged to inside of the removed if condition, so it's gone now.
[splat1] - w/o this patch - The deadlock during VF removal: WARNING: possible circular locking dependency detected sh/3825 is trying to acquire lock: ((work_completion)(&(&adapter->watchdog_task)->work)){+.+.}-{0:0}, at: start_flush_work+0x1a1/0x470 but task is already holding lock: (&adapter->crit_lock){+.+.}-{4:4}, at: iavf_remove+0xd1/0x690 [iavf] which lock already depends on the new lock.
[splat2] - when cancelling work under crit lock, w/o this series, see [2] for the band aid attempt WARNING: possible circular locking dependency detected sh/3550 is trying to acquire lock: ((wq_completion)iavf){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90 but task is already holding lock: (&dev->lock){+.+.}-{4:4}, at: iavf_remove+0xa6/0x6e0 [iavf] which lock already depends on the new lock.
[1] fc2e6b3b132a ("iavf: Rework mutexes for better synchronisation") [2] https://github.com/pkitszel/linux/commit/52dddbfc2bb60294083f5711a158a
{
"affected": [],
"aliases": [
"CVE-2025-38311"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-10T08:15:30Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\niavf: get rid of the crit lock\n\nGet rid of the crit lock.\nThat frees us from the error prone logic of try_locks.\n\nThanks to netdev_lock() by Jakub it is now easy, and in most cases we were\nprotected by it already - replace crit lock by netdev lock when it was not\nthe case.\n\nLockdep reports that we should cancel the work under crit_lock [splat1],\nand that was the scheme we have mostly followed since [1] by Slawomir.\nBut when that is done we still got into deadlocks [splat2]. So instead\nwe should look at the bigger problem, namely \"weird locking/scheduling\"\nof the iavf. The first step to fix that is to remove the crit lock.\nI will followup with a -next series that simplifies scheduling/tasks.\n\nCancel the work without netdev lock (weird unlock+lock scheme),\nto fix the [splat2] (which would be totally ugly if we would kept\nthe crit lock).\n\nExtend protected part of iavf_watchdog_task() to include scheduling\nmore work.\n\nNote that the removed comment in iavf_reset_task() was misplaced,\nit belonged to inside of the removed if condition, so it\u0027s gone now.\n\n[splat1] - w/o this patch - The deadlock during VF removal:\n WARNING: possible circular locking dependency detected\n sh/3825 is trying to acquire lock:\n ((work_completion)(\u0026(\u0026adapter-\u003ewatchdog_task)-\u003ework)){+.+.}-{0:0}, at: start_flush_work+0x1a1/0x470\n but task is already holding lock:\n (\u0026adapter-\u003ecrit_lock){+.+.}-{4:4}, at: iavf_remove+0xd1/0x690 [iavf]\n which lock already depends on the new lock.\n\n[splat2] - when cancelling work under crit lock, w/o this series,\n\t see [2] for the band aid attempt\n WARNING: possible circular locking dependency detected\n sh/3550 is trying to acquire lock:\n ((wq_completion)iavf){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90\n but task is already holding lock:\n (\u0026dev-\u003elock){+.+.}-{4:4}, at: iavf_remove+0xa6/0x6e0 [iavf]\n which lock already depends on the new lock.\n\n[1] fc2e6b3b132a (\"iavf: Rework mutexes for better synchronisation\")\n[2] https://github.com/pkitszel/linux/commit/52dddbfc2bb60294083f5711a158a",
"id": "GHSA-g72f-6g67-w739",
"modified": "2025-11-18T15:30:40Z",
"published": "2025-07-10T09:32:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38311"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/120f28a6f314fef7f282c99f196923fe44081cad"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/620ab4d6215de0b25227f9fff1a8c7fb66837cb8"
}
],
"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-G7CW-XHG8-933G
Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-07-23 12:32In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp
l2cap_ecred_reconf_rsp() calls l2cap_chan_del() without holding l2cap_chan_lock(). Every other l2cap_chan_del() caller in the file acquires the lock first. A remote BLE device can send a crafted L2CAP ECRED reconfiguration response to corrupt the channel list while another thread is iterating it.
Add l2cap_chan_hold() and l2cap_chan_lock() before l2cap_chan_del(), and l2cap_chan_unlock() and l2cap_chan_put() after, matching the pattern used in l2cap_ecred_conn_rsp() and l2cap_conn_del().
{
"affected": [],
"aliases": [
"CVE-2026-53071"
],
"database_specific": {
"cwe_ids": [
"CWE-414",
"CWE-416",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T17:17:20Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp\n\nl2cap_ecred_reconf_rsp() calls l2cap_chan_del() without holding\nl2cap_chan_lock(). Every other l2cap_chan_del() caller in the file\nacquires the lock first. A remote BLE device can send a crafted\nL2CAP ECRED reconfiguration response to corrupt the channel list\nwhile another thread is iterating it.\n\nAdd l2cap_chan_hold() and l2cap_chan_lock() before l2cap_chan_del(),\nand l2cap_chan_unlock() and l2cap_chan_put() after, matching the\npattern used in l2cap_ecred_conn_rsp() and l2cap_conn_del().",
"id": "GHSA-g7cw-xhg8-933g",
"modified": "2026-07-23T12:32:20Z",
"published": "2026-06-24T18:32:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53071"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:42550"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:42552"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:42919"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:43307"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-53071"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2492458"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0ccd75c51f620374086f359e906917676e699a1c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/330b20ec97916961ee0e6c29c06bc0fa7c96e64c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/42776497cdbc9a665b384a6dcb85f0d4bd927eab"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5501d055a1ce3c747141e3955ba8cf034d193f3e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/77a853aec710b2fdf41fa298ea3cbc9a4358f917"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/96dca51715d86559ed6ed8028e5445cecb80f3ae"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dc89961b76f12aff47124c1df4bdb32a080f4d0c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fe1188abdae9b7a8199dcdfcf9244d5e5d61eb14"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53071.json"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-G7XH-HW6G-XCPW
Vulnerability from github – Published: 2025-09-23 06:30 – Updated: 2026-01-16 21:30In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix recursive semaphore deadlock in fiemap call
syzbot detected a OCFS2 hang due to a recursive semaphore on a FS_IOC_FIEMAP of the extent list on a specially crafted mmap file.
context_switch kernel/sched/core.c:5357 [inline] __schedule+0x1798/0x4cc0 kernel/sched/core.c:6961 __schedule_loop kernel/sched/core.c:7043 [inline] schedule+0x165/0x360 kernel/sched/core.c:7058 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7115 rwsem_down_write_slowpath+0x872/0xfe0 kernel/locking/rwsem.c:1185 __down_write_common kernel/locking/rwsem.c:1317 [inline] __down_write kernel/locking/rwsem.c:1326 [inline] down_write+0x1ab/0x1f0 kernel/locking/rwsem.c:1591 ocfs2_page_mkwrite+0x2ff/0xc40 fs/ocfs2/mmap.c:142 do_page_mkwrite+0x14d/0x310 mm/memory.c:3361 wp_page_shared mm/memory.c:3762 [inline] do_wp_page+0x268d/0x5800 mm/memory.c:3981 handle_pte_fault mm/memory.c:6068 [inline] __handle_mm_fault+0x1033/0x5440 mm/memory.c:6195 handle_mm_fault+0x40a/0x8e0 mm/memory.c:6364 do_user_addr_fault+0x764/0x1390 arch/x86/mm/fault.c:1387 handle_page_fault arch/x86/mm/fault.c:1476 [inline] exc_page_fault+0x76/0xf0 arch/x86/mm/fault.c:1532 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623 RIP: 0010:copy_user_generic arch/x86/include/asm/uaccess_64.h:126 [inline] RIP: 0010:raw_copy_to_user arch/x86/include/asm/uaccess_64.h:147 [inline] RIP: 0010:_inline_copy_to_user include/linux/uaccess.h:197 [inline] RIP: 0010:_copy_to_user+0x85/0xb0 lib/usercopy.c:26 Code: e8 00 bc f7 fc 4d 39 fc 72 3d 4d 39 ec 77 38 e8 91 b9 f7 fc 4c 89 f7 89 de e8 47 25 5b fd 0f 01 cb 4c 89 ff 48 89 d9 4c 89 f6 a4 0f 1f 00 48 89 cb 0f 01 ca 48 89 d8 5b 41 5c 41 5d 41 5e 41 RSP: 0018:ffffc9000403f950 EFLAGS: 00050256 RAX: ffffffff84c7f101 RBX: 0000000000000038 RCX: 0000000000000038 RDX: 0000000000000000 RSI: ffffc9000403f9e0 RDI: 0000200000000060 RBP: ffffc9000403fa90 R08: ffffc9000403fa17 R09: 1ffff92000807f42 R10: dffffc0000000000 R11: fffff52000807f43 R12: 0000200000000098 R13: 00007ffffffff000 R14: ffffc9000403f9e0 R15: 0000200000000060 copy_to_user include/linux/uaccess.h:225 [inline] fiemap_fill_next_extent+0x1c0/0x390 fs/ioctl.c:145 ocfs2_fiemap+0x888/0xc90 fs/ocfs2/extent_map.c:806 ioctl_fiemap fs/ioctl.c:220 [inline] do_vfs_ioctl+0x1173/0x1430 fs/ioctl.c:532 __do_sys_ioctl fs/ioctl.c:596 [inline] __se_sys_ioctl+0x82/0x170 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5f13850fd9 RSP: 002b:00007ffe3b3518b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f5f13850fd9 RDX: 0000200000000040 RSI: 00000000c020660b RDI: 0000000000000004 RBP: 6165627472616568 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe3b3518f0 R13: 00007ffe3b351b18 R14: 431bde82d7b634db R15: 00007f5f1389a03b
ocfs2_fiemap() takes a read lock of the ip_alloc_sem semaphore (since v2.6.22-527-g7307de80510a) and calls fiemap_fill_next_extent() to read the extent list of this running mmap executable. The user supplied buffer to hold the fiemap information page faults calling ocfs2_page_mkwrite() which will take a write lock (since v2.6.27-38-g00dc417fa3e7) of the same semaphore. This recursive semaphore will hold filesystem locks and causes a hang of the fileystem.
The ip_alloc_sem protects the inode extent list and size. Release the read semphore before calling fiemap_fill_next_extent() in ocfs2_fiemap() and ocfs2_fiemap_inline(). This does an unnecessary semaphore lock/unlock on the last extent but simplifies the error path.
{
"affected": [],
"aliases": [
"CVE-2025-39885"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-23T06:15:48Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix recursive semaphore deadlock in fiemap call\n\nsyzbot detected a OCFS2 hang due to a recursive semaphore on a\nFS_IOC_FIEMAP of the extent list on a specially crafted mmap file.\n\ncontext_switch kernel/sched/core.c:5357 [inline]\n __schedule+0x1798/0x4cc0 kernel/sched/core.c:6961\n __schedule_loop kernel/sched/core.c:7043 [inline]\n schedule+0x165/0x360 kernel/sched/core.c:7058\n schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7115\n rwsem_down_write_slowpath+0x872/0xfe0 kernel/locking/rwsem.c:1185\n __down_write_common kernel/locking/rwsem.c:1317 [inline]\n __down_write kernel/locking/rwsem.c:1326 [inline]\n down_write+0x1ab/0x1f0 kernel/locking/rwsem.c:1591\n ocfs2_page_mkwrite+0x2ff/0xc40 fs/ocfs2/mmap.c:142\n do_page_mkwrite+0x14d/0x310 mm/memory.c:3361\n wp_page_shared mm/memory.c:3762 [inline]\n do_wp_page+0x268d/0x5800 mm/memory.c:3981\n handle_pte_fault mm/memory.c:6068 [inline]\n __handle_mm_fault+0x1033/0x5440 mm/memory.c:6195\n handle_mm_fault+0x40a/0x8e0 mm/memory.c:6364\n do_user_addr_fault+0x764/0x1390 arch/x86/mm/fault.c:1387\n handle_page_fault arch/x86/mm/fault.c:1476 [inline]\n exc_page_fault+0x76/0xf0 arch/x86/mm/fault.c:1532\n asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623\nRIP: 0010:copy_user_generic arch/x86/include/asm/uaccess_64.h:126 [inline]\nRIP: 0010:raw_copy_to_user arch/x86/include/asm/uaccess_64.h:147 [inline]\nRIP: 0010:_inline_copy_to_user include/linux/uaccess.h:197 [inline]\nRIP: 0010:_copy_to_user+0x85/0xb0 lib/usercopy.c:26\nCode: e8 00 bc f7 fc 4d 39 fc 72 3d 4d 39 ec 77 38 e8 91 b9 f7 fc 4c 89\nf7 89 de e8 47 25 5b fd 0f 01 cb 4c 89 ff 48 89 d9 4c 89 f6 \u003cf3\u003e a4 0f\n1f 00 48 89 cb 0f 01 ca 48 89 d8 5b 41 5c 41 5d 41 5e 41\nRSP: 0018:ffffc9000403f950 EFLAGS: 00050256\nRAX: ffffffff84c7f101 RBX: 0000000000000038 RCX: 0000000000000038\nRDX: 0000000000000000 RSI: ffffc9000403f9e0 RDI: 0000200000000060\nRBP: ffffc9000403fa90 R08: ffffc9000403fa17 R09: 1ffff92000807f42\nR10: dffffc0000000000 R11: fffff52000807f43 R12: 0000200000000098\nR13: 00007ffffffff000 R14: ffffc9000403f9e0 R15: 0000200000000060\n copy_to_user include/linux/uaccess.h:225 [inline]\n fiemap_fill_next_extent+0x1c0/0x390 fs/ioctl.c:145\n ocfs2_fiemap+0x888/0xc90 fs/ocfs2/extent_map.c:806\n ioctl_fiemap fs/ioctl.c:220 [inline]\n do_vfs_ioctl+0x1173/0x1430 fs/ioctl.c:532\n __do_sys_ioctl fs/ioctl.c:596 [inline]\n __se_sys_ioctl+0x82/0x170 fs/ioctl.c:584\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f5f13850fd9\nRSP: 002b:00007ffe3b3518b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f5f13850fd9\nRDX: 0000200000000040 RSI: 00000000c020660b RDI: 0000000000000004\nRBP: 6165627472616568 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe3b3518f0\nR13: 00007ffe3b351b18 R14: 431bde82d7b634db R15: 00007f5f1389a03b\n\nocfs2_fiemap() takes a read lock of the ip_alloc_sem semaphore (since\nv2.6.22-527-g7307de80510a) and calls fiemap_fill_next_extent() to read the\nextent list of this running mmap executable. The user supplied buffer to\nhold the fiemap information page faults calling ocfs2_page_mkwrite() which\nwill take a write lock (since v2.6.27-38-g00dc417fa3e7) of the same\nsemaphore. This recursive semaphore will hold filesystem locks and causes\na hang of the fileystem.\n\nThe ip_alloc_sem protects the inode extent list and size. Release the\nread semphore before calling fiemap_fill_next_extent() in ocfs2_fiemap()\nand ocfs2_fiemap_inline(). This does an unnecessary semaphore lock/unlock\non the last extent but simplifies the error path.",
"id": "GHSA-g7xh-hw6g-xcpw",
"modified": "2026-01-16T21:30:27Z",
"published": "2025-09-23T06:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39885"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/04100f775c2ea501927f508f17ad824ad1f23c8d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0709bc11b942870fc0a7be150e42aea42321093a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/16e518ca84dfe860c20a62f3615e14e8af0ace57"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1d3c96547ee2ddeaddf8f19a3ef99ea06cc8115e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/36054554772f95d090eb45793faf6aa3c0254b02"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7e1514bd44ef68007703c752c99ff7319f35bce6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9efcb7a8b97310efed995397941a292cf89fa94f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ef30404980e4c832ef9bba1b10c08f67fa77a9ec"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.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-G8V7-WPGP-C9XW
Vulnerability from github – Published: 2025-03-12 12:30 – Updated: 2025-03-13 18:32In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gt: Use spin_lock_irqsave() in interruptible context
spin_lock/unlock() functions used in interrupt contexts could result in a deadlock, as seen in GitLab issue #13399, which occurs when interrupt comes in while holding a lock.
Try to remedy the problem by saving irq state before spin lock acquisition.
v2: add irqs' state save/restore calls to all locks/unlocks in signal_irq_work() execution (Maciej)
v3: use with spin_lock_irqsave() in guc_lrc_desc_unpin() instead of other lock/unlock calls and add Fixes and Cc tags (Tvrtko); change title and commit message
(cherry picked from commit c088387ddd6482b40f21ccf23db1125e8fa4af7e)
{
"affected": [],
"aliases": [
"CVE-2025-21849"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-12T10:15:17Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/gt: Use spin_lock_irqsave() in interruptible context\n\nspin_lock/unlock() functions used in interrupt contexts could\nresult in a deadlock, as seen in GitLab issue #13399,\nwhich occurs when interrupt comes in while holding a lock.\n\nTry to remedy the problem by saving irq state before spin lock\nacquisition.\n\nv2: add irqs\u0027 state save/restore calls to all locks/unlocks in\n signal_irq_work() execution (Maciej)\n\nv3: use with spin_lock_irqsave() in guc_lrc_desc_unpin() instead\n of other lock/unlock calls and add Fixes and Cc tags (Tvrtko);\n change title and commit message\n\n(cherry picked from commit c088387ddd6482b40f21ccf23db1125e8fa4af7e)",
"id": "GHSA-g8v7-wpgp-c9xw",
"modified": "2025-03-13T18:32:20Z",
"published": "2025-03-12T12:30:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21849"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2bf1f4c129db7a10920655b000f0292f1ee509c2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/47ae46ac5407646420e06b78e0dad331e56a4bb4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e49477f7f78598295551d486ecc7f020d796432e"
}
],
"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-G9C8-PHH2-8FQC
Vulnerability from github – Published: 2024-06-19 15:30 – Updated: 2024-11-08 21:33In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix potential hang in nilfs_detach_log_writer()
Syzbot has reported a potential hang in nilfs_detach_log_writer() called during nilfs2 unmount.
Analysis revealed that this is because nilfs_segctor_sync(), which synchronizes with the log writer thread, can be called after nilfs_segctor_destroy() terminates that thread, as shown in the call trace below:
nilfs_detach_log_writer nilfs_segctor_destroy nilfs_segctor_kill_thread --> Shut down log writer thread flush_work nilfs_iput_work_func nilfs_dispose_list iput nilfs_evict_inode nilfs_transaction_commit nilfs_construct_segment (if inode needs sync) nilfs_segctor_sync --> Attempt to synchronize with log writer thread *** DEADLOCK ***
Fix this issue by changing nilfs_segctor_sync() so that the log writer thread returns normally without synchronizing after it terminates, and by forcing tasks that are already waiting to complete once after the thread terminates.
The skipped inode metadata flushout will then be processed together in the subsequent cleanup work in nilfs_segctor_destroy().
{
"affected": [],
"aliases": [
"CVE-2024-38582"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-19T14:15:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix potential hang in nilfs_detach_log_writer()\n\nSyzbot has reported a potential hang in nilfs_detach_log_writer() called\nduring nilfs2 unmount.\n\nAnalysis revealed that this is because nilfs_segctor_sync(), which\nsynchronizes with the log writer thread, can be called after\nnilfs_segctor_destroy() terminates that thread, as shown in the call trace\nbelow:\n\nnilfs_detach_log_writer\n nilfs_segctor_destroy\n nilfs_segctor_kill_thread --\u003e Shut down log writer thread\n flush_work\n nilfs_iput_work_func\n nilfs_dispose_list\n iput\n nilfs_evict_inode\n nilfs_transaction_commit\n nilfs_construct_segment (if inode needs sync)\n nilfs_segctor_sync --\u003e Attempt to synchronize with\n log writer thread\n *** DEADLOCK ***\n\nFix this issue by changing nilfs_segctor_sync() so that the log writer\nthread returns normally without synchronizing after it terminates, and by\nforcing tasks that are already waiting to complete once after the thread\nterminates.\n\nThe skipped inode metadata flushout will then be processed together in the\nsubsequent cleanup work in nilfs_segctor_destroy().",
"id": "GHSA-g9c8-phh2-8fqc",
"modified": "2024-11-08T21:33:51Z",
"published": "2024-06-19T15:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38582"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/06afce714d87c7cd1dcfccbcd800c5c5d2cf1cfd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1c3844c5f4eac043954ebf6403fa9fd1f0e9c1c0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6e5c8e8e024e147b834f56f2115aad241433679b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/911d38be151921a5d152bb55e81fd752384c6830"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a8799662fed1f8747edae87a1937549288baca6a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bc9cee50a4a4ca23bdc49f75ea8242d8a2193b3b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c516db6ab9eabbedbc430b4f93b0d8728e9b427f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eb85dace897c5986bc2f36b3c783c6abb8a4292e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eff7cdf890b02596b8d73e910bdbdd489175dbdb"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-G9JR-CM69-RQC6
Vulnerability from github – Published: 2024-07-16 12:30 – Updated: 2025-10-03 15:31In the Linux kernel, the following vulnerability has been resolved:
ipmr,ip6mr: acquire RTNL before calling ip[6]mr_free_table() on failure path
ip[6]mr_free_table() can only be called under RTNL lock.
RTNL: assertion failed at net/core/dev.c (10367) WARNING: CPU: 1 PID: 5890 at net/core/dev.c:10367 unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367 Modules linked in: CPU: 1 PID: 5890 Comm: syz-executor.2 Not tainted 5.16.0-syzkaller-11627-g422ee58dc0ef #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367 Code: 0f 85 9b ee ff ff e8 69 07 4b fa ba 7f 28 00 00 48 c7 c6 00 90 ae 8a 48 c7 c7 40 90 ae 8a c6 05 6d b1 51 06 01 e8 8c 90 d8 01 <0f> 0b e9 70 ee ff ff e8 3e 07 4b fa 4c 89 e7 e8 86 2a 59 fa e9 ee RSP: 0018:ffffc900046ff6e0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff888050f51d00 RSI: ffffffff815fa008 RDI: fffff520008dfece RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815f3d6e R11: 0000000000000000 R12: 00000000fffffff4 R13: dffffc0000000000 R14: ffffc900046ff750 R15: ffff88807b7dc000 FS: 00007f4ab736e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fee0b4f8990 CR3: 000000001e7d2000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mroute_clean_tables+0x244/0xb40 net/ipv6/ip6mr.c:1509 ip6mr_free_table net/ipv6/ip6mr.c:389 [inline] ip6mr_rules_init net/ipv6/ip6mr.c:246 [inline] ip6mr_net_init net/ipv6/ip6mr.c:1306 [inline] ip6mr_net_init+0x3f0/0x4e0 net/ipv6/ip6mr.c:1298 ops_init+0xaf/0x470 net/core/net_namespace.c:140 setup_net+0x54f/0xbb0 net/core/net_namespace.c:331 copy_net_ns+0x318/0x760 net/core/net_namespace.c:475 create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110 copy_namespaces+0x391/0x450 kernel/nsproxy.c:178 copy_process+0x2e0c/0x7300 kernel/fork.c:2167 kernel_clone+0xe7/0xab0 kernel/fork.c:2555 __do_sys_clone+0xc8/0x110 kernel/fork.c:2672 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f4ab89f9059 Code: Unable to access opcode bytes at RIP 0x7f4ab89f902f. RSP: 002b:00007f4ab736e118 EFLAGS: 00000206 ORIG_RAX: 0000000000000038 RAX: ffffffffffffffda RBX: 00007f4ab8b0bf60 RCX: 00007f4ab89f9059 RDX: 0000000020000280 RSI: 0000000020000270 RDI: 0000000040200000 RBP: 00007f4ab8a5308d R08: 0000000020000300 R09: 0000000020000300 R10: 00000000200002c0 R11: 0000000000000206 R12: 0000000000000000 R13: 00007ffc3977cc1f R14: 00007f4ab736e300 R15: 0000000000022000
{
"affected": [],
"aliases": [
"CVE-2022-48810"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-16T12:15:05Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nipmr,ip6mr: acquire RTNL before calling ip[6]mr_free_table() on failure path\n\nip[6]mr_free_table() can only be called under RTNL lock.\n\nRTNL: assertion failed at net/core/dev.c (10367)\nWARNING: CPU: 1 PID: 5890 at net/core/dev.c:10367 unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367\nModules linked in:\nCPU: 1 PID: 5890 Comm: syz-executor.2 Not tainted 5.16.0-syzkaller-11627-g422ee58dc0ef #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nRIP: 0010:unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367\nCode: 0f 85 9b ee ff ff e8 69 07 4b fa ba 7f 28 00 00 48 c7 c6 00 90 ae 8a 48 c7 c7 40 90 ae 8a c6 05 6d b1 51 06 01 e8 8c 90 d8 01 \u003c0f\u003e 0b e9 70 ee ff ff e8 3e 07 4b fa 4c 89 e7 e8 86 2a 59 fa e9 ee\nRSP: 0018:ffffc900046ff6e0 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000\nRDX: ffff888050f51d00 RSI: ffffffff815fa008 RDI: fffff520008dfece\nRBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\nR10: ffffffff815f3d6e R11: 0000000000000000 R12: 00000000fffffff4\nR13: dffffc0000000000 R14: ffffc900046ff750 R15: ffff88807b7dc000\nFS: 00007f4ab736e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fee0b4f8990 CR3: 000000001e7d2000 CR4: 00000000003506e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u003cTASK\u003e\n mroute_clean_tables+0x244/0xb40 net/ipv6/ip6mr.c:1509\n ip6mr_free_table net/ipv6/ip6mr.c:389 [inline]\n ip6mr_rules_init net/ipv6/ip6mr.c:246 [inline]\n ip6mr_net_init net/ipv6/ip6mr.c:1306 [inline]\n ip6mr_net_init+0x3f0/0x4e0 net/ipv6/ip6mr.c:1298\n ops_init+0xaf/0x470 net/core/net_namespace.c:140\n setup_net+0x54f/0xbb0 net/core/net_namespace.c:331\n copy_net_ns+0x318/0x760 net/core/net_namespace.c:475\n create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110\n copy_namespaces+0x391/0x450 kernel/nsproxy.c:178\n copy_process+0x2e0c/0x7300 kernel/fork.c:2167\n kernel_clone+0xe7/0xab0 kernel/fork.c:2555\n __do_sys_clone+0xc8/0x110 kernel/fork.c:2672\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f4ab89f9059\nCode: Unable to access opcode bytes at RIP 0x7f4ab89f902f.\nRSP: 002b:00007f4ab736e118 EFLAGS: 00000206 ORIG_RAX: 0000000000000038\nRAX: ffffffffffffffda RBX: 00007f4ab8b0bf60 RCX: 00007f4ab89f9059\nRDX: 0000000020000280 RSI: 0000000020000270 RDI: 0000000040200000\nRBP: 00007f4ab8a5308d R08: 0000000020000300 R09: 0000000020000300\nR10: 00000000200002c0 R11: 0000000000000206 R12: 0000000000000000\nR13: 00007ffc3977cc1f R14: 00007f4ab736e300 R15: 0000000000022000\n \u003c/TASK\u003e",
"id": "GHSA-g9jr-cm69-rqc6",
"modified": "2025-10-03T15:31:14Z",
"published": "2024-07-16T12:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48810"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/09ac0fcb0a82d647f2c61d3d488d367b7ee5bd51"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/12b6703e9546902c56b4b9048b893ad49d62bdd4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/16dcfde98a25340ff0f7879a16bea141d824a196"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3cab045c99dbb9a94eb2d1d405f399916eec698a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5611a00697c8ecc5aad04392bea629e9d6a20463"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/80c529322600dfb1f985b5e3f14c3c6f522ce154"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b541845dfc4e7df551955e70deec0921d6b297c3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/feb9597e22755dce782aae26ac0590c06737e049"
}
],
"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-GC8R-VH42-27G4
Vulnerability from github – Published: 2024-05-21 15:31 – Updated: 2024-07-03 18:42In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix soft lookup in subflow_error_report()
Maxim reported a soft lookup in subflow_error_report():
watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0] RIP: 0010:native_queued_spin_lock_slowpath RSP: 0018:ffffa859c0003bc0 EFLAGS: 00000202 RAX: 0000000000000101 RBX: 0000000000000001 RCX: 0000000000000000 RDX: ffff9195c2772d88 RSI: 0000000000000000 RDI: ffff9195c2772d88 RBP: ffff9195c2772d00 R08: 00000000000067b0 R09: c6e31da9eb1e44f4 R10: ffff9195ef379700 R11: ffff9195edb50710 R12: ffff9195c2772d88 R13: ffff9195f500e3d0 R14: ffff9195ef379700 R15: ffff9195ef379700 FS: 0000000000000000(0000) GS:ffff91961f400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c000407000 CR3: 0000000002988000 CR4: 00000000000006f0 Call Trace: _raw_spin_lock_bh subflow_error_report mptcp_subflow_data_available __mptcp_move_skbs_from_subflow mptcp_data_ready tcp_data_queue tcp_rcv_established tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish __netif_receive_skb_one_core netif_receive_skb rtl8139_poll 8139too __napi_poll net_rx_action __do_softirq __irq_exit_rcu common_interrupt
The calling function - mptcp_subflow_data_available() - can be invoked from different contexts: - plain ssk socket lock - ssk socket lock + mptcp_data_lock - ssk socket lock + mptcp_data_lock + msk socket lock.
Since subflow_error_report() tries to acquire the mptcp_data_lock, the latter two call chains will cause soft lookup.
This change addresses the issue moving the error reporting call to outer functions, where the held locks list is known and the we can acquire only the needed one.
{
"affected": [],
"aliases": [
"CVE-2021-47242"
],
"database_specific": {
"cwe_ids": [
"CWE-1281",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T15:15:13Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix soft lookup in subflow_error_report()\n\nMaxim reported a soft lookup in subflow_error_report():\n\n watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]\n RIP: 0010:native_queued_spin_lock_slowpath\n RSP: 0018:ffffa859c0003bc0 EFLAGS: 00000202\n RAX: 0000000000000101 RBX: 0000000000000001 RCX: 0000000000000000\n RDX: ffff9195c2772d88 RSI: 0000000000000000 RDI: ffff9195c2772d88\n RBP: ffff9195c2772d00 R08: 00000000000067b0 R09: c6e31da9eb1e44f4\n R10: ffff9195ef379700 R11: ffff9195edb50710 R12: ffff9195c2772d88\n R13: ffff9195f500e3d0 R14: ffff9195ef379700 R15: ffff9195ef379700\n FS: 0000000000000000(0000) GS:ffff91961f400000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000c000407000 CR3: 0000000002988000 CR4: 00000000000006f0\n Call Trace:\n \u003cIRQ\u003e\n _raw_spin_lock_bh\n subflow_error_report\n mptcp_subflow_data_available\n __mptcp_move_skbs_from_subflow\n mptcp_data_ready\n tcp_data_queue\n tcp_rcv_established\n tcp_v4_do_rcv\n tcp_v4_rcv\n ip_protocol_deliver_rcu\n ip_local_deliver_finish\n __netif_receive_skb_one_core\n netif_receive_skb\n rtl8139_poll 8139too\n __napi_poll\n net_rx_action\n __do_softirq\n __irq_exit_rcu\n common_interrupt\n \u003c/IRQ\u003e\n\nThe calling function - mptcp_subflow_data_available() - can be invoked\nfrom different contexts:\n- plain ssk socket lock\n- ssk socket lock + mptcp_data_lock\n- ssk socket lock + mptcp_data_lock + msk socket lock.\n\nSince subflow_error_report() tries to acquire the mptcp_data_lock, the\nlatter two call chains will cause soft lookup.\n\nThis change addresses the issue moving the error reporting call to\nouter functions, where the held locks list is known and the we can\nacquire only the needed one.",
"id": "GHSA-gc8r-vh42-27g4",
"modified": "2024-07-03T18:42:43Z",
"published": "2024-05-21T15:31:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47242"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/27ef25c72373222aaa5fe7b5cd890ae9cfb89a8d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/499ada5073361c631f2a3c4a8aed44d53b6f82ec"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-GCR7-HVF6-PH59
Vulnerability from github – Published: 2025-04-14 21:32 – Updated: 2025-04-14 21:32In the Linux kernel, the following vulnerability has been resolved:
ceph: fix possible deadlock when holding Fwb to get inline_data
1, mount with wsync. 2, create a file with O_RDWR, and the request was sent to mds.0:
ceph_atomic_open()--> ceph_mdsc_do_request(openc) finish_open(file, dentry, ceph_open)--> ceph_open()--> ceph_init_file()--> ceph_init_file_info()--> ceph_uninline_data()--> { ... if (inline_version == 1 || / initial version, no data / inline_version == CEPH_INLINE_NONE) goto out_unlock; ... }
The inline_version will be 1, which is the initial version for the new create file. And here the ci->i_inline_version will keep with 1, it's buggy.
3, buffer write to the file immediately:
ceph_write_iter()--> ceph_get_caps(file, need=Fw, want=Fb, ...); generic_perform_write()--> a_ops->write_begin()--> ceph_write_begin()--> netfs_write_begin()--> netfs_begin_read()--> netfs_rreq_submit_slice()--> netfs_read_from_server()--> rreq->netfs_ops->issue_read()--> ceph_netfs_issue_read()--> { ... if (ci->i_inline_version != CEPH_INLINE_NONE && ceph_netfs_issue_op_inline(subreq)) return; ... } ceph_put_cap_refs(ci, Fwb);
The ceph_netfs_issue_op_inline() will send a getattr(Fsr) request to mds.1.
4, then the mds.1 will request the rd lock for CInode::filelock from the auth mds.0, the mds.0 will do the CInode::filelock state transation from excl --> sync, but it need to revoke the Fxwb caps back from the clients.
While the kernel client has aleady held the Fwb caps and waiting for the getattr(Fsr).
It's deadlock!
URL: https://tracker.ceph.com/issues/55377
{
"affected": [],
"aliases": [
"CVE-2022-49296"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:06Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix possible deadlock when holding Fwb to get inline_data\n\n1, mount with wsync.\n2, create a file with O_RDWR, and the request was sent to mds.0:\n\n ceph_atomic_open()--\u003e\n ceph_mdsc_do_request(openc)\n finish_open(file, dentry, ceph_open)--\u003e\n ceph_open()--\u003e\n ceph_init_file()--\u003e\n ceph_init_file_info()--\u003e\n ceph_uninline_data()--\u003e\n {\n ...\n if (inline_version == 1 || /* initial version, no data */\n inline_version == CEPH_INLINE_NONE)\n goto out_unlock;\n ...\n }\n\nThe inline_version will be 1, which is the initial version for the\nnew create file. And here the ci-\u003ei_inline_version will keep with 1,\nit\u0027s buggy.\n\n3, buffer write to the file immediately:\n\n ceph_write_iter()--\u003e\n ceph_get_caps(file, need=Fw, want=Fb, ...);\n generic_perform_write()--\u003e\n a_ops-\u003ewrite_begin()--\u003e\n ceph_write_begin()--\u003e\n netfs_write_begin()--\u003e\n netfs_begin_read()--\u003e\n netfs_rreq_submit_slice()--\u003e\n netfs_read_from_server()--\u003e\n rreq-\u003enetfs_ops-\u003eissue_read()--\u003e\n ceph_netfs_issue_read()--\u003e\n {\n ...\n if (ci-\u003ei_inline_version != CEPH_INLINE_NONE \u0026\u0026\n ceph_netfs_issue_op_inline(subreq))\n return;\n ...\n }\n ceph_put_cap_refs(ci, Fwb);\n\nThe ceph_netfs_issue_op_inline() will send a getattr(Fsr) request to\nmds.1.\n\n4, then the mds.1 will request the rd lock for CInode::filelock from\nthe auth mds.0, the mds.0 will do the CInode::filelock state transation\nfrom excl --\u003e sync, but it need to revoke the Fxwb caps back from the\nclients.\n\nWhile the kernel client has aleady held the Fwb caps and waiting for\nthe getattr(Fsr).\n\nIt\u0027s deadlock!\n\nURL: https://tracker.ceph.com/issues/55377",
"id": "GHSA-gcr7-hvf6-ph59",
"modified": "2025-04-14T21:32:20Z",
"published": "2025-04-14T21:32:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49296"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/292b7a7275ce535a1abfa4dd0b2e586162aaae1e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/825978fd6a0defc3c29d8a38b6cea76a0938d21e"
}
],
"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.