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-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"
}
]
}
GHSA-GCXJ-24RJ-3795
Vulnerability from github – Published: 2024-11-19 03:31 – Updated: 2025-09-19 21:31In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix missing locking causing hanging calls
If a call gets aborted (e.g. because kafs saw a signal) between it being queued for connection and the I/O thread picking up the call, the abort will be prioritised over the connection and it will be removed from local->new_client_calls by rxrpc_disconnect_client_call() without a lock being held. This may cause other calls on the list to disappear if a race occurs.
Fix this by taking the client_call_lock when removing a call from whatever list its ->wait_link happens to be on.
{
"affected": [],
"aliases": [
"CVE-2024-50294"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-19T02:16:31Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Fix missing locking causing hanging calls\n\nIf a call gets aborted (e.g. because kafs saw a signal) between it being\nqueued for connection and the I/O thread picking up the call, the abort\nwill be prioritised over the connection and it will be removed from\nlocal-\u003enew_client_calls by rxrpc_disconnect_client_call() without a lock\nbeing held. This may cause other calls on the list to disappear if a race\noccurs.\n\nFix this by taking the client_call_lock when removing a call from whatever\nlist its -\u003ewait_link happens to be on.",
"id": "GHSA-gcxj-24rj-3795",
"modified": "2025-09-19T21:31:15Z",
"published": "2024-11-19T03:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50294"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/996a7208dadbf2cdda8d51444d5ee1fdd1ccbc92"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b1fdb0bb3b6513f5bd26f92369fd6ac1a2422d8b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fc9de52de38f656399d2ce40f7349a6b5f86e787"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-GF27-P5CC-4MQ4
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2026-06-01 18:31In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: fix deadlock and link starvation in outgoing data path
The current implementation queues up new control and user packets as needed and processes this queue down to the ldisc in the same code path. That means that the upper and the lower layer are hard coupled in the code. Due to this deadlocks can happen as seen below while transmitting data, especially during ldisc congestion. Furthermore, the data channels starve the control channel on high transmission load on the ldisc.
Introduce an additional control channel data queue to prevent timeouts and link hangups during ldisc congestion. This is being processed before the user channel data queue in gsm_data_kick(), i.e. with the highest priority. Put the queue to ldisc data path into a workqueue and trigger it whenever new data has been put into the transmission queue. Change gsm_dlci_data_sweep() accordingly to fill up the transmission queue until TX_THRESH_HI. This solves the locking issue, keeps latency low and provides good performance on high data load. Note that now all packets from a DLCI are removed from the internal queue if the associated DLCI was closed. This ensures that no data is sent by the introduced write task to an already closed DLCI.
BUG: spinlock recursion on CPU#0, test_v24_loop/124 lock: serial8250_ports+0x3a8/0x7500, .magic: dead4ead, .owner: test_v24_loop/124, .owner_cpu: 0 CPU: 0 PID: 124 Comm: test_v24_loop Tainted: G O 5.18.0-rc2 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x34/0x44 do_raw_spin_lock+0x76/0xa0 _raw_spin_lock_irqsave+0x72/0x80 uart_write_room+0x3b/0xc0 gsm_data_kick+0x14b/0x240 [n_gsm] gsmld_write_wakeup+0x35/0x70 [n_gsm] tty_wakeup+0x53/0x60 tty_port_default_wakeup+0x1b/0x30 serial8250_tx_chars+0x12f/0x220 serial8250_handle_irq.part.0+0xfe/0x150 serial8250_default_handle_irq+0x48/0x80 serial8250_interrupt+0x56/0xa0 __handle_irq_event_percpu+0x78/0x1f0 handle_irq_event+0x34/0x70 handle_fasteoi_irq+0x90/0x1e0 __common_interrupt+0x69/0x100 common_interrupt+0x48/0xc0 asm_common_interrupt+0x1e/0x40 RIP: 0010:__do_softirq+0x83/0x34e Code: 2a 0a ff 0f b7 ed c7 44 24 10 0a 00 00 00 48 c7 c7 51 2a 64 82 e8 2d e2 d5 ff 65 66 c7 05 83 af 1e 7e 00 00 fb b8 ff ff ff ff <49> c7 c2 40 61 80 82 0f bc c5 41 89 c4 41 83 c4 01 0f 84 e6 00 00 RSP: 0018:ffffc90000003f98 EFLAGS: 00000286 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff82642a51 RDI: ffffffff825bb5e7 RBP: 0000000000000200 R08: 00000008de3271a8 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000030 R14: 0000000000000000 R15: 0000000000000000 ? __do_softirq+0x73/0x34e irq_exit_rcu+0xb5/0x100 common_interrupt+0xa4/0xc0 asm_common_interrupt+0x1e/0x40 RIP: 0010:_raw_spin_unlock_irqrestore+0x2e/0x50 Code: 00 55 48 89 fd 48 83 c7 18 53 48 89 f3 48 8b 74 24 10 e8 85 28 36 ff 48 89 ef e8 cd 58 36 ff 80 e7 02 74 01 fb bf 01 00 00 00 3d 97 33 ff 65 8b 05 96 23 2b 7e 85 c0 74 03 5b 5d c3 0f 1f 44 RSP: 0018:ffffc9000020fd08 EFLAGS: 00000202 RAX: 0000000000000000 RBX: 0000000000000246 RCX: 0000000000000000 RDX: 0000000000000004 RSI: ffffffff8257fd74 RDI: 0000000000000001 RBP: ffff8880057de3a0 R08: 00000008de233000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000100 R14: 0000000000000202 R15: ffff8880057df0b8 ? _raw_spin_unlock_irqrestore+0x23/0x50 gsmtty_write+0x65/0x80 [n_gsm] n_tty_write+0x33f/0x530 ? swake_up_all+0xe0/0xe0 file_tty_write.constprop.0+0x1b1/0x320 ? n_tty_flush_buffer+0xb0/0xb0 new_sync_write+0x10c/0x190 vfs_write+0x282/0x310 ksys_write+0x68/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f3e5e35c15c Code: 8b 7c 24 08 89 c5 e8 c5 ff ff ff 89 ef 89 44 24 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2022-50116"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:41Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntty: n_gsm: fix deadlock and link starvation in outgoing data path\n\nThe current implementation queues up new control and user packets as needed\nand processes this queue down to the ldisc in the same code path.\nThat means that the upper and the lower layer are hard coupled in the code.\nDue to this deadlocks can happen as seen below while transmitting data,\nespecially during ldisc congestion. Furthermore, the data channels starve\nthe control channel on high transmission load on the ldisc.\n\nIntroduce an additional control channel data queue to prevent timeouts and\nlink hangups during ldisc congestion. This is being processed before the\nuser channel data queue in gsm_data_kick(), i.e. with the highest priority.\nPut the queue to ldisc data path into a workqueue and trigger it whenever\nnew data has been put into the transmission queue. Change\ngsm_dlci_data_sweep() accordingly to fill up the transmission queue until\nTX_THRESH_HI. This solves the locking issue, keeps latency low and provides\ngood performance on high data load.\nNote that now all packets from a DLCI are removed from the internal queue\nif the associated DLCI was closed. This ensures that no data is sent by the\nintroduced write task to an already closed DLCI.\n\nBUG: spinlock recursion on CPU#0, test_v24_loop/124\n lock: serial8250_ports+0x3a8/0x7500, .magic: dead4ead, .owner: test_v24_loop/124, .owner_cpu: 0\nCPU: 0 PID: 124 Comm: test_v24_loop Tainted: G O 5.18.0-rc2 #3\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nCall Trace:\n \u003cIRQ\u003e\n dump_stack_lvl+0x34/0x44\n do_raw_spin_lock+0x76/0xa0\n _raw_spin_lock_irqsave+0x72/0x80\n uart_write_room+0x3b/0xc0\n gsm_data_kick+0x14b/0x240 [n_gsm]\n gsmld_write_wakeup+0x35/0x70 [n_gsm]\n tty_wakeup+0x53/0x60\n tty_port_default_wakeup+0x1b/0x30\n serial8250_tx_chars+0x12f/0x220\n serial8250_handle_irq.part.0+0xfe/0x150\n serial8250_default_handle_irq+0x48/0x80\n serial8250_interrupt+0x56/0xa0\n __handle_irq_event_percpu+0x78/0x1f0\n handle_irq_event+0x34/0x70\n handle_fasteoi_irq+0x90/0x1e0\n __common_interrupt+0x69/0x100\n common_interrupt+0x48/0xc0\n asm_common_interrupt+0x1e/0x40\nRIP: 0010:__do_softirq+0x83/0x34e\nCode: 2a 0a ff 0f b7 ed c7 44 24 10 0a 00 00 00 48 c7 c7 51 2a 64 82 e8 2d\ne2 d5 ff 65 66 c7 05 83 af 1e 7e 00 00 fb b8 ff ff ff ff \u003c49\u003e c7 c2 40 61\n80 82 0f bc c5 41 89 c4 41 83 c4 01 0f 84 e6 00 00\nRSP: 0018:ffffc90000003f98 EFLAGS: 00000286\nRAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffffffff82642a51 RDI: ffffffff825bb5e7\nRBP: 0000000000000200 R08: 00000008de3271a8 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000\nR13: 0000000000000030 R14: 0000000000000000 R15: 0000000000000000\n ? __do_softirq+0x73/0x34e\n irq_exit_rcu+0xb5/0x100\n common_interrupt+0xa4/0xc0\n \u003c/IRQ\u003e\n \u003cTASK\u003e\n asm_common_interrupt+0x1e/0x40\nRIP: 0010:_raw_spin_unlock_irqrestore+0x2e/0x50\nCode: 00 55 48 89 fd 48 83 c7 18 53 48 89 f3 48 8b 74 24 10 e8 85 28 36 ff\n48 89 ef e8 cd 58 36 ff 80 e7 02 74 01 fb bf 01 00 00 00 \u003ce8\u003e 3d 97 33 ff\n65 8b 05 96 23 2b 7e 85 c0 74 03 5b 5d c3 0f 1f 44\nRSP: 0018:ffffc9000020fd08 EFLAGS: 00000202\nRAX: 0000000000000000 RBX: 0000000000000246 RCX: 0000000000000000\nRDX: 0000000000000004 RSI: ffffffff8257fd74 RDI: 0000000000000001\nRBP: ffff8880057de3a0 R08: 00000008de233000 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000\nR13: 0000000000000100 R14: 0000000000000202 R15: ffff8880057df0b8\n ? _raw_spin_unlock_irqrestore+0x23/0x50\n gsmtty_write+0x65/0x80 [n_gsm]\n n_tty_write+0x33f/0x530\n ? swake_up_all+0xe0/0xe0\n file_tty_write.constprop.0+0x1b1/0x320\n ? n_tty_flush_buffer+0xb0/0xb0\n new_sync_write+0x10c/0x190\n vfs_write+0x282/0x310\n ksys_write+0x68/0xe0\n do_syscall_64+0x3b/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f3e5e35c15c\nCode: 8b 7c 24 08 89 c5 e8 c5 ff ff ff 89 ef 89 44 24\n---truncated---",
"id": "GHSA-gf27-p5cc-4mq4",
"modified": "2026-06-01T18:31:20Z",
"published": "2025-06-18T12:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50116"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0af021678d5d30c31f5a6b631f404ead3575212a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5020173e7e7725110a8d4be1359bf1dfc4b1814d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7962a4b900099cf90e02859bb297f2c618d8d940"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c165698c9919b000bdbe73859d3bb7b33bdb9223"
}
],
"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-GF8P-7594-M58R
Vulnerability from github – Published: 2025-02-27 03:34 – Updated: 2026-02-06 18:30In the Linux kernel, the following vulnerability has been resolved:
ptr_ring: do not block hard interrupts in ptr_ring_resize_multiple()
Jakub added a lockdep_assert_no_hardirq() check in __page_pool_put_page() to increase test coverage.
syzbot found a splat caused by hard irq blocking in ptr_ring_resize_multiple() [1]
As current users of ptr_ring_resize_multiple() do not require hard irqs being masked, replace it to only block BH.
Rename helpers to better reflect they are safe against BH only.
- ptr_ring_resize_multiple() to ptr_ring_resize_multiple_bh()
- skb_array_resize_multiple() to skb_array_resize_multiple_bh()
[1]
WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 __page_pool_put_page net/core/page_pool.c:709 [inline] WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780 Modules linked in: CPU: 1 UID: 0 PID: 9150 Comm: syz.1.1052 Not tainted 6.11.0-rc3-syzkaller-00202-gf8669d7b5f5d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__page_pool_put_page net/core/page_pool.c:709 [inline] RIP: 0010:page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780 Code: 74 0e e8 7c aa fb f7 eb 43 e8 75 aa fb f7 eb 3c 65 8b 1d 38 a8 6a 76 31 ff 89 de e8 a3 ae fb f7 85 db 74 0b e8 5a aa fb f7 90 <0f> 0b 90 eb 1d 65 8b 1d 15 a8 6a 76 31 ff 89 de e8 84 ae fb f7 85 RSP: 0018:ffffc9000bda6b58 EFLAGS: 00010083 RAX: ffffffff8997e523 RBX: 0000000000000000 RCX: 0000000000040000 RDX: ffffc9000fbd0000 RSI: 0000000000001842 RDI: 0000000000001843 RBP: 0000000000000000 R08: ffffffff8997df2c R09: 1ffffd40003a000d R10: dffffc0000000000 R11: fffff940003a000e R12: ffffea0001d00040 R13: ffff88802e8a4000 R14: dffffc0000000000 R15: 00000000ffffffff FS: 00007fb7aaf716c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa15a0d4b72 CR3: 00000000561b0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: tun_ptr_free drivers/net/tun.c:617 [inline] __ptr_ring_swap_queue include/linux/ptr_ring.h:571 [inline] ptr_ring_resize_multiple_noprof include/linux/ptr_ring.h:643 [inline] tun_queue_resize drivers/net/tun.c:3694 [inline] tun_device_event+0xaaf/0x1080 drivers/net/tun.c:3714 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] dev_change_tx_queue_len+0x158/0x2a0 net/core/dev.c:9024 do_setlink+0xff6/0x41f0 net/core/rtnetlink.c:2923 rtnl_setlink+0x40d/0x5a0 net/core/rtnetlink.c:3201 rtnetlink_rcv_msg+0x73f/0xcf0 net/core/rtnetlink.c:6647 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2550
{
"affected": [],
"aliases": [
"CVE-2024-57994"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-27T02:15:13Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nptr_ring: do not block hard interrupts in ptr_ring_resize_multiple()\n\nJakub added a lockdep_assert_no_hardirq() check in __page_pool_put_page()\nto increase test coverage.\n\nsyzbot found a splat caused by hard irq blocking in\nptr_ring_resize_multiple() [1]\n\nAs current users of ptr_ring_resize_multiple() do not require\nhard irqs being masked, replace it to only block BH.\n\nRename helpers to better reflect they are safe against BH only.\n\n- ptr_ring_resize_multiple() to ptr_ring_resize_multiple_bh()\n- skb_array_resize_multiple() to skb_array_resize_multiple_bh()\n\n[1]\n\nWARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 __page_pool_put_page net/core/page_pool.c:709 [inline]\nWARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780\nModules linked in:\nCPU: 1 UID: 0 PID: 9150 Comm: syz.1.1052 Not tainted 6.11.0-rc3-syzkaller-00202-gf8669d7b5f5d #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\nRIP: 0010:__page_pool_put_page net/core/page_pool.c:709 [inline]\nRIP: 0010:page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780\nCode: 74 0e e8 7c aa fb f7 eb 43 e8 75 aa fb f7 eb 3c 65 8b 1d 38 a8 6a 76 31 ff 89 de e8 a3 ae fb f7 85 db 74 0b e8 5a aa fb f7 90 \u003c0f\u003e 0b 90 eb 1d 65 8b 1d 15 a8 6a 76 31 ff 89 de e8 84 ae fb f7 85\nRSP: 0018:ffffc9000bda6b58 EFLAGS: 00010083\nRAX: ffffffff8997e523 RBX: 0000000000000000 RCX: 0000000000040000\nRDX: ffffc9000fbd0000 RSI: 0000000000001842 RDI: 0000000000001843\nRBP: 0000000000000000 R08: ffffffff8997df2c R09: 1ffffd40003a000d\nR10: dffffc0000000000 R11: fffff940003a000e R12: ffffea0001d00040\nR13: ffff88802e8a4000 R14: dffffc0000000000 R15: 00000000ffffffff\nFS: 00007fb7aaf716c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fa15a0d4b72 CR3: 00000000561b0000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u003cTASK\u003e\n tun_ptr_free drivers/net/tun.c:617 [inline]\n __ptr_ring_swap_queue include/linux/ptr_ring.h:571 [inline]\n ptr_ring_resize_multiple_noprof include/linux/ptr_ring.h:643 [inline]\n tun_queue_resize drivers/net/tun.c:3694 [inline]\n tun_device_event+0xaaf/0x1080 drivers/net/tun.c:3714\n notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93\n call_netdevice_notifiers_extack net/core/dev.c:2032 [inline]\n call_netdevice_notifiers net/core/dev.c:2046 [inline]\n dev_change_tx_queue_len+0x158/0x2a0 net/core/dev.c:9024\n do_setlink+0xff6/0x41f0 net/core/rtnetlink.c:2923\n rtnl_setlink+0x40d/0x5a0 net/core/rtnetlink.c:3201\n rtnetlink_rcv_msg+0x73f/0xcf0 net/core/rtnetlink.c:6647\n netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2550",
"id": "GHSA-gf8p-7594-m58r",
"modified": "2026-02-06T18:30:26Z",
"published": "2025-02-27T03:34:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57994"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3257dac521d0ac6653108c755141dce634bb8ff2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/572777a258c048e0d0fb3a0c47430eadcefe80c0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a126061c80d5efb4baef4bcf346094139cd81df6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e74801b7628dc52b17471aec729bc675479ddc73"
}
],
"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-GF8V-7H89-7W9J
Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-07-14 18:31In the Linux kernel, the following vulnerability has been resolved:
net: psp: check for device unregister when creating assoc
psp_assoc_device_get_locked() obtains a psp_dev reference via psp_dev_get_for_sock() (which uses psp_dev_tryget() under RCU); it then acquires psd->lock and drops the reference. Before the lock is taken, psp_dev_unregister() can run to completion: take psd->lock, clear out state, unlock, drop the registration reference.
The expectation is that the lock prevents device unregistration, but much like with netdevs special care has to be taken when "upgrading" a reference to a locked device. Add the missing check if device is still alive. psp_dev_is_registered() exists already but had no callers, which makes me wonder if I either forgot to add this or lost the check during refactoring...
{
"affected": [],
"aliases": [
"CVE-2026-52979"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T17:17:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: psp: check for device unregister when creating assoc\n\npsp_assoc_device_get_locked() obtains a psp_dev reference via\npsp_dev_get_for_sock() (which uses psp_dev_tryget() under RCU);\nit then acquires psd-\u003elock and drops the reference. Before\nthe lock is taken, psp_dev_unregister() can run to completion:\ntake psd-\u003elock, clear out state, unlock, drop the registration\nreference.\n\nThe expectation is that the lock prevents device unregistration,\nbut much like with netdevs special care has to be taken when\n\"upgrading\" a reference to a locked device. Add the missing\ncheck if device is still alive. psp_dev_is_registered() exists\nalready but had no callers, which makes me wonder if I either\nforgot to add this or lost the check during refactoring...",
"id": "GHSA-gf8v-7h89-7w9j",
"modified": "2026-07-14T18:31:49Z",
"published": "2026-06-24T18:32:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52979"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b89769f936a8fa9e66de72ddc1b71a9745a488e6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d90df5ce6deb2424de3ad89bcc693ac1b67accc9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e201c57073e624dd2ba5beaf9eda31e19b77b332"
}
],
"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.