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.
721 vulnerabilities reference this CWE, most recent first.
GHSA-CWX4-F9X9-PQHH
Vulnerability from github – Published: 2026-06-25 09:31 – Updated: 2026-07-06 15:30In the Linux kernel, the following vulnerability has been resolved:
xfrm: iptfs: fix ABBA deadlock in iptfs_destroy_state()
iptfs_destroy_state() calls hrtimer_cancel() while holding a spinlock that the timer callback also acquires, leading to an ABBA deadlock on SMP systems.
For the output timer (iptfs_timer): - iptfs_destroy_state() holds x->lock, calls hrtimer_cancel() - iptfs_delay_timer() callback takes x->lock
For the drop timer (drop_timer): - iptfs_destroy_state() holds drop_lock, calls hrtimer_cancel() - iptfs_drop_timer() callback takes drop_lock
Both timers use HRTIMER_MODE_REL_SOFT, so their callbacks run in softirq context. When hrtimer_cancel() is called for a soft timer that is currently executing on another CPU, hrtimer_cancel_wait_running() spins on softirq_expiry_lock -- the same lock held by the softirq running the callback. If the callback is blocked waiting for the spinlock held by the caller of hrtimer_cancel(), a circular dependency forms:
CPU 0: holds lock_A -> waits for softirq_expiry_lock CPU 1: holds softirq_expiry_lock -> waits for lock_A
Fix by calling hrtimer_cancel() before acquiring the respective locks. hrtimer_cancel() is safe to call without holding any lock and will wait for any in-progress callback to complete. For the output timer, the lock is still acquired afterwards to drain the packet queue. For the drop timer, the lock/unlock pair is removed entirely since it only existed to serialize with the timer callback, which hrtimer_cancel() already guarantees.
Found by source code audit.
{
"affected": [],
"aliases": [
"CVE-2026-53197"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-25T09:16:37Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: iptfs: fix ABBA deadlock in iptfs_destroy_state()\n\niptfs_destroy_state() calls hrtimer_cancel() while holding a spinlock\nthat the timer callback also acquires, leading to an ABBA deadlock on\nSMP systems.\n\nFor the output timer (iptfs_timer):\n - iptfs_destroy_state() holds x-\u003elock, calls hrtimer_cancel()\n - iptfs_delay_timer() callback takes x-\u003elock\n\nFor the drop timer (drop_timer):\n - iptfs_destroy_state() holds drop_lock, calls hrtimer_cancel()\n - iptfs_drop_timer() callback takes drop_lock\n\nBoth timers use HRTIMER_MODE_REL_SOFT, so their callbacks run in softirq\ncontext. When hrtimer_cancel() is called for a soft timer that is\ncurrently executing on another CPU, hrtimer_cancel_wait_running() spins\non softirq_expiry_lock -- the same lock held by the softirq running the\ncallback. If the callback is blocked waiting for the spinlock held by\nthe caller of hrtimer_cancel(), a circular dependency forms:\n\n CPU 0: holds lock_A -\u003e waits for softirq_expiry_lock\n CPU 1: holds softirq_expiry_lock -\u003e waits for lock_A\n\nFix by calling hrtimer_cancel() before acquiring the respective locks.\nhrtimer_cancel() is safe to call without holding any lock and will wait\nfor any in-progress callback to complete. For the output timer, the\nlock is still acquired afterwards to drain the packet queue. For the\ndrop timer, the lock/unlock pair is removed entirely since it only\nexisted to serialize with the timer callback, which hrtimer_cancel()\nalready guarantees.\n\nFound by source code audit.",
"id": "GHSA-cwx4-f9x9-pqhh",
"modified": "2026-07-06T15:30:42Z",
"published": "2026-06-25T09:31:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53197"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/822b98d354e63e8249e85473c5f3c519f3c9cecc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a13ca53e47e500854a3b9ec18b5dc83acfec863e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c8a8a75b733467b00c08b91a38dbaf207a08ed6e"
}
],
"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-CX5C-HRVR-85GJ
Vulnerability from github – Published: 2024-05-01 15:30 – Updated: 2026-05-12 12:31In the Linux kernel, the following vulnerability has been resolved:
media: usbtv: Remove useless locks in usbtv_video_free()
Remove locks calls in usbtv_video_free() because are useless and may led to a deadlock as reported here: https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000 Also remove usbtv_stop() call since it will be called when unregistering the device.
Before 'c838530d230b' this issue would only be noticed if you disconnect while streaming and now it is noticeable even when disconnecting while not streaming.
[hverkuil: fix minor spelling mistake in log message]
{
"affected": [],
"aliases": [
"CVE-2024-27072"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T13:15:51Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: usbtv: Remove useless locks in usbtv_video_free()\n\nRemove locks calls in usbtv_video_free() because\nare useless and may led to a deadlock as reported here:\nhttps://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000\nAlso remove usbtv_stop() call since it will be called when\nunregistering the device.\n\nBefore \u0027c838530d230b\u0027 this issue would only be noticed if you\ndisconnect while streaming and now it is noticeable even when\ndisconnecting while not streaming.\n\n\n[hverkuil: fix minor spelling mistake in log message]",
"id": "GHSA-cx5c-hrvr-85gj",
"modified": "2026-05-12T12:31:45Z",
"published": "2024-05-01T15:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27072"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e7d82ebb86e94643bdb30b0b5b077ed27dce1c2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4ec4641df57cbdfdc51bb4959afcdbcf5003ddb9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/65e6a2773d655172143cc0b927cdc89549842895"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bdd82c47b22a8befd617b723098b2a41b77373c7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d5ed208d04acf06781d63d30f9fa991e8d609ebd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dea46e246ef0f98d89d59a4229157cd9ffb636bf"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CX67-J66H-CM23
Vulnerability from github – Published: 2026-06-26 21:32 – Updated: 2026-07-06 21:30In the Linux kernel, the following vulnerability has been resolved:
scsi: sg: Resolve soft lockup issue when opening /dev/sgX
The parameter def_reserved_size defines the default buffer size reserved for each Sg_fd and should be restricted to a range between 0 and 1,048,576 (see https://tldp.org/HOWTO/SCSI-Generic-HOWTO/proc.html). Although the function sg_proc_write_dressz enforces this limit, it is possible to bypass it by directly modifying the module parameter as shown below, which then causes a soft lockup:
echo -1 > /sys/module/sg/parameters/def_reserved_size exec 4<> /dev/sg0
watchdog: BUG: soft lockup - CPU#5 stuck for 26 seconds! [bash:537] Modules loaded: CPU: 5 UID: 0 PID: 537 Command: bash, kernel version 6.19.0-rc3+ #134, PREEMPT disabled Hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS version 1.16.1-2.fc37 dated 04/01/2014 ... Call Trace:
sg_build_reserve+0x5c/0xa0 sg_add_sfp+0x168/0x270 sg_open+0x16e/0x340 chrdev_open+0xbe/0x230 do_dentry_open+0x175/0x480 vfs_open+0x34/0xf0 do_open+0x265/0x3d0 path_openat+0x110/0x290 do_filp_open+0xc3/0x170 do_sys_openat2+0x71/0xe0 __x64_sys_openat+0x6d/0xa0 do_syscall_64+0x62/0x310 entry_SYSCALL_64_after_hwframe+0x76/0x7e
The fix is to use module_param_cb to validate and reject invalid values assigned to def_reserved_size.
{
"affected": [],
"aliases": [
"CVE-2026-53304"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-26T20:17:23Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: sg: Resolve soft lockup issue when opening /dev/sgX\n\nThe parameter def_reserved_size defines the default buffer size reserved\nfor each Sg_fd and should be restricted to a range between 0 and 1,048,576\n(see https://tldp.org/HOWTO/SCSI-Generic-HOWTO/proc.html). Although the\nfunction sg_proc_write_dressz enforces this limit, it is possible to bypass\nit by directly modifying the module parameter as shown below, which then\ncauses a soft lockup:\n\necho -1 \u003e /sys/module/sg/parameters/def_reserved_size\nexec 4\u003c\u003e /dev/sg0\n\nwatchdog: BUG: soft lockup - CPU#5 stuck for 26 seconds! [bash:537]\nModules loaded:\nCPU: 5 UID: 0 PID: 537 Command: bash, kernel version 6.19.0-rc3+ #134,\nPREEMPT disabled\nHardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS version\n1.16.1-2.fc37 dated 04/01/2014\n...\nCall Trace:\n\n sg_build_reserve+0x5c/0xa0\n sg_add_sfp+0x168/0x270\n sg_open+0x16e/0x340\n chrdev_open+0xbe/0x230\n do_dentry_open+0x175/0x480\n vfs_open+0x34/0xf0\n do_open+0x265/0x3d0\n path_openat+0x110/0x290\n do_filp_open+0xc3/0x170\n do_sys_openat2+0x71/0xe0\n __x64_sys_openat+0x6d/0xa0\n do_syscall_64+0x62/0x310\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe fix is to use module_param_cb to validate and reject invalid values\nassigned to def_reserved_size.",
"id": "GHSA-cx67-j66h-cm23",
"modified": "2026-07-06T21:30:25Z",
"published": "2026-06-26T21:32:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53304"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1afd963fcd963db0dc5d47df6dfcf010c9c4647e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3d74e0654ac908c65a8f20373091826fe43b1363"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9676ca7b1ef31a3a65b3e61e7ce3b54ce7364202"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c47ccfb3d80dfed522ca06a5954ac97488d78c5a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c5f4a211e82d04ccc1809311322c47023bbe66e2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d06a310b45e153872033dd0cf19d5a2279121099"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fe671d3c84ffb1b763d590c25195755adeaadaba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/feade299e932967de27519338d41de348fb5b061"
}
],
"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-CX7M-FCGF-9RJ4
Vulnerability from github – Published: 2024-09-18 09:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open
The mcp251x_hw_wake() function is called with the mpc_lock mutex held and disables the interrupt handler so that no interrupts can be processed while waking the device. If an interrupt has already occurred then waiting for the interrupt handler to complete will deadlock because it will be trying to acquire the same mutex.
CPU0 CPU1 ---- ---- mcp251x_open() mutex_lock(&priv->mcp_lock) request_threaded_irq() mcp251x_can_ist() mutex_lock(&priv->mcp_lock) mcp251x_hw_wake() disable_irq() <-- deadlock
Use disable_irq_nosync() instead because the interrupt handler does everything while holding the mutex so it doesn't matter if it's still running.
{
"affected": [],
"aliases": [
"CVE-2024-46791"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-18T08:15:06Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open\n\nThe mcp251x_hw_wake() function is called with the mpc_lock mutex held and\ndisables the interrupt handler so that no interrupts can be processed while\nwaking the device. If an interrupt has already occurred then waiting for\nthe interrupt handler to complete will deadlock because it will be trying\nto acquire the same mutex.\n\nCPU0 CPU1\n---- ----\nmcp251x_open()\n mutex_lock(\u0026priv-\u003emcp_lock)\n request_threaded_irq()\n \u003cinterrupt\u003e\n mcp251x_can_ist()\n mutex_lock(\u0026priv-\u003emcp_lock)\n mcp251x_hw_wake()\n disable_irq() \u003c-- deadlock\n\nUse disable_irq_nosync() instead because the interrupt handler does\neverything while holding the mutex so it doesn\u0027t matter if it\u0027s still\nrunning.",
"id": "GHSA-cx7m-fcgf-9rj4",
"modified": "2025-11-04T00:31:29Z",
"published": "2024-09-18T09:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46791"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3a49b6b1caf5cefc05264d29079d52c99cb188e0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/513c8fc189b52f7922e36bdca58997482b198f0e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7dd9c26bd6cf679bcfdef01a8659791aa6487a29"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8fecde9c3f9a4b97b68bb97c9f47e5b662586ba7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e554113a1cd2a9cfc6c7af7bdea2141c5757e188"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f7ab9e14b23a3eac6714bdc4dba244d8aa1ef646"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.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-CXF4-996M-V4M3
Vulnerability from github – Published: 2024-07-12 15:31 – Updated: 2025-11-04 00:30In the Linux kernel, the following vulnerability has been resolved:
riscv: rewrite __kernel_map_pages() to fix sleeping in invalid context
__kernel_map_pages() is a debug function which clears the valid bit in page table entry for deallocated pages to detect illegal memory accesses to freed pages.
This function set/clear the valid bit using __set_memory(). __set_memory() acquires init_mm's semaphore, and this operation may sleep. This is problematic, because __kernel_map_pages() can be called in atomic context, and thus is illegal to sleep. An example warning that this causes:
BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1578 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, name: kthreadd preempt_count: 2, expected: 0 CPU: 0 PID: 2 Comm: kthreadd Not tainted 6.9.0-g1d4c6d784ef6 #37 Hardware name: riscv-virtio,qemu (DT) Call Trace: [] dump_backtrace+0x1c/0x24 [] show_stack+0x2c/0x38 [] dump_stack_lvl+0x5a/0x72 [] dump_stack+0x14/0x1c [] __might_resched+0x104/0x10e [] __might_sleep+0x3e/0x62 [] down_write+0x20/0x72 [] __set_memory+0x82/0x2fa [] __kernel_map_pages+0x5a/0xd4 [] __alloc_pages_bulk+0x3b2/0x43a [] __vmalloc_node_range+0x196/0x6ba [] copy_process+0x72c/0x17ec [] kernel_clone+0x60/0x2fe [] kernel_thread+0x82/0xa0 [] kthreadd+0x14a/0x1be [] ret_from_fork+0xe/0x1c
Rewrite this function with apply_to_existing_page_range(). It is fine to not have any locking, because __kernel_map_pages() works with pages being allocated/deallocated and those pages are not changed by anyone else in the meantime.
{
"affected": [],
"aliases": [
"CVE-2024-40915"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-12T13:15:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: rewrite __kernel_map_pages() to fix sleeping in invalid context\n\n__kernel_map_pages() is a debug function which clears the valid bit in page\ntable entry for deallocated pages to detect illegal memory accesses to\nfreed pages.\n\nThis function set/clear the valid bit using __set_memory(). __set_memory()\nacquires init_mm\u0027s semaphore, and this operation may sleep. This is\nproblematic, because __kernel_map_pages() can be called in atomic context,\nand thus is illegal to sleep. An example warning that this causes:\n\nBUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1578\nin_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, name: kthreadd\npreempt_count: 2, expected: 0\nCPU: 0 PID: 2 Comm: kthreadd Not tainted 6.9.0-g1d4c6d784ef6 #37\nHardware name: riscv-virtio,qemu (DT)\nCall Trace:\n[\u003cffffffff800060dc\u003e] dump_backtrace+0x1c/0x24\n[\u003cffffffff8091ef6e\u003e] show_stack+0x2c/0x38\n[\u003cffffffff8092baf8\u003e] dump_stack_lvl+0x5a/0x72\n[\u003cffffffff8092bb24\u003e] dump_stack+0x14/0x1c\n[\u003cffffffff8003b7ac\u003e] __might_resched+0x104/0x10e\n[\u003cffffffff8003b7f4\u003e] __might_sleep+0x3e/0x62\n[\u003cffffffff8093276a\u003e] down_write+0x20/0x72\n[\u003cffffffff8000cf00\u003e] __set_memory+0x82/0x2fa\n[\u003cffffffff8000d324\u003e] __kernel_map_pages+0x5a/0xd4\n[\u003cffffffff80196cca\u003e] __alloc_pages_bulk+0x3b2/0x43a\n[\u003cffffffff8018ee82\u003e] __vmalloc_node_range+0x196/0x6ba\n[\u003cffffffff80011904\u003e] copy_process+0x72c/0x17ec\n[\u003cffffffff80012ab4\u003e] kernel_clone+0x60/0x2fe\n[\u003cffffffff80012f62\u003e] kernel_thread+0x82/0xa0\n[\u003cffffffff8003552c\u003e] kthreadd+0x14a/0x1be\n[\u003cffffffff809357de\u003e] ret_from_fork+0xe/0x1c\n\nRewrite this function with apply_to_existing_page_range(). It is fine to\nnot have any locking, because __kernel_map_pages() works with pages being\nallocated/deallocated and those pages are not changed by anyone else in the\nmeantime.",
"id": "GHSA-cxf4-996m-v4m3",
"modified": "2025-11-04T00:30:53Z",
"published": "2024-07-12T15:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40915"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8661a7af04991201640863ad1a0983173f84b5eb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/919f8626099d9909b9a9620b05e8c8ab06581876"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d5257ceb19d92069195254866421f425aea42915"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fb1cf0878328fe75d47f0aed0a65b30126fcefc4"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.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-F225-F9RP-HG69
Vulnerability from github – Published: 2024-12-28 12:30 – Updated: 2025-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
bpf: fix recursive lock when verdict program return SK_PASS
When the stream_verdict program returns SK_PASS, it places the received skb into its own receive queue, but a recursive lock eventually occurs, leading to an operating system deadlock. This issue has been present since v6.9.
''' sk_psock_strp_data_ready write_lock_bh(&sk->sk_callback_lock) strp_data_ready strp_read_sock read_sock -> tcp_read_sock strp_recv cb.rcv_msg -> sk_psock_strp_read # now stream_verdict return SK_PASS without peer sock assign __SK_PASS = sk_psock_map_verd(SK_PASS, NULL) sk_psock_verdict_apply sk_psock_skb_ingress_self sk_psock_skb_ingress_enqueue sk_psock_data_ready read_lock_bh(&sk->sk_callback_lock) <= dead lock
'''
This topic has been discussed before, but it has not been fixed. Previous discussion: https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch
{
"affected": [],
"aliases": [
"CVE-2024-56694"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-28T10:15:15Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: fix recursive lock when verdict program return SK_PASS\n\nWhen the stream_verdict program returns SK_PASS, it places the received skb\ninto its own receive queue, but a recursive lock eventually occurs, leading\nto an operating system deadlock. This issue has been present since v6.9.\n\n\u0027\u0027\u0027\nsk_psock_strp_data_ready\n write_lock_bh(\u0026sk-\u003esk_callback_lock)\n strp_data_ready\n strp_read_sock\n read_sock -\u003e tcp_read_sock\n strp_recv\n cb.rcv_msg -\u003e sk_psock_strp_read\n # now stream_verdict return SK_PASS without peer sock assign\n __SK_PASS = sk_psock_map_verd(SK_PASS, NULL)\n sk_psock_verdict_apply\n sk_psock_skb_ingress_self\n sk_psock_skb_ingress_enqueue\n sk_psock_data_ready\n read_lock_bh(\u0026sk-\u003esk_callback_lock) \u003c= dead lock\n\n\u0027\u0027\u0027\n\nThis topic has been discussed before, but it has not been fixed.\nPrevious discussion:\nhttps://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch",
"id": "GHSA-f225-f9rp-hg69",
"modified": "2025-11-03T21:32:01Z",
"published": "2024-12-28T12:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56694"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/01f1b88acfd79103da0610b45471f6c88ea98d72"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/078f7e1521442a55db4bed812a2fbaf02ac33819"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/221109ba2127eabd0aa64718543638b58b15df56"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/386efa339e08563dd33e83bc951aea5d407fe578"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6694f7acd625ed854bf6342926e771d65dad7f69"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8ca2a1eeadf09862190b2810697702d803ceef2d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/da2bc8a0c8f3ac66fdf980fc59936f851a083561"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f84c5ef6ca23cc2f72f3b830d74f67944684bb05"
},
{
"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-F266-QPMF-VXQX
Vulnerability from github – Published: 2022-05-24 17:31 – Updated: 2022-05-24 17:31This issue was addressed with improved checks. This issue is fixed in iOS 14.0 and iPadOS 14.0, watchOS 7.0. The screen lock may not engage after the specified time period.
{
"affected": [],
"aliases": [
"CVE-2020-9946"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-10-16T17:15:00Z",
"severity": "MODERATE"
},
"details": "This issue was addressed with improved checks. This issue is fixed in iOS 14.0 and iPadOS 14.0, watchOS 7.0. The screen lock may not engage after the specified time period.",
"id": "GHSA-f266-qpmf-vxqx",
"modified": "2022-05-24T17:31:09Z",
"published": "2022-05-24T17:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9946"
},
{
"type": "WEB",
"url": "https://support.apple.com/HT211844"
},
{
"type": "WEB",
"url": "https://support.apple.com/HT211850"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2020/Nov/20"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2020/Nov/22"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F2F9-54CV-V7GF
Vulnerability from github – Published: 2026-07-25 12:31 – Updated: 2026-09-04 15:35In the Linux kernel, the following vulnerability has been resolved:
mm/swap: add cond_resched() in swap_reclaim_full_clusters to prevent softlockup
We hit a real softlockup in an internal stress test environment. The workload was LTP memory/swap stress on a large arm64 machine, with 320 CPUs, about 1TB memory and an 8.6GB swap device. The system was under heavy load and the swap device had a large number of full clusters. The softlockup was triggered during a stress test after about 3 days.
So, add periodic cond_resched() calls during large full_clusters reclaim operations to prevent softlockup issues.
Detailed call trace as follow:
PID: 3817773 TASK: ffff0883bb28b780 CPU: 48 COMMAND: "kworker/48:7" #0 [ffff800080183d10] __crash_kexec at ffffa4c1361e5de4 #1 [ffff800080183d90] panic at ffffa4c1360d5e9c #2 [ffff800080183e20] watchdog_timer_fn at ffffa4c136231fa8 ... #16 [ffff8000c4ad3cb0] swap_cache_del_folio at ffffa4c1363e1614 #17 [ffff8000c4ad3ce0] __try_to_reclaim_swap at ffffa4c1363e4bfc #18 [ffff8000c4ad3d40] swap_reclaim_full_clusters at ffffa4c1363e5474 #19 [ffff8000c4ad3da0] swap_reclaim_work at ffffa4c1363e550c #20 [ffff8000c4ad3dc0] process_one_work at ffffa4c136102edc #21 [ffff8000c4ad3e10] worker_thread at ffffa4c136103398 #22 [ffff8000c4ad3e70] kthread at ffffa4c13610d95c
{
"affected": [],
"aliases": [
"CVE-2026-64415"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-25T10:17:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/swap: add cond_resched() in swap_reclaim_full_clusters to prevent softlockup\n\nWe hit a real softlockup in an internal stress test environment. The\nworkload was LTP memory/swap stress on a large arm64 machine, with 320\nCPUs, about 1TB memory and an 8.6GB swap device. The system was under\nheavy load and the swap device had a large number of full clusters. The\nsoftlockup was triggered during a stress test after about 3 days.\n\nSo, add periodic cond_resched() calls during large full_clusters\nreclaim operations to prevent softlockup issues.\n\nDetailed call trace as follow:\n\nPID: 3817773 TASK: ffff0883bb28b780 CPU: 48 COMMAND: \"kworker/48:7\"\n #0 [ffff800080183d10] __crash_kexec at ffffa4c1361e5de4\n #1 [ffff800080183d90] panic at ffffa4c1360d5e9c\n #2 [ffff800080183e20] watchdog_timer_fn at ffffa4c136231fa8\n ...\n #16 [ffff8000c4ad3cb0] swap_cache_del_folio at ffffa4c1363e1614\n #17 [ffff8000c4ad3ce0] __try_to_reclaim_swap at ffffa4c1363e4bfc\n #18 [ffff8000c4ad3d40] swap_reclaim_full_clusters at ffffa4c1363e5474\n #19 [ffff8000c4ad3da0] swap_reclaim_work at ffffa4c1363e550c\n #20 [ffff8000c4ad3dc0] process_one_work at ffffa4c136102edc\n #21 [ffff8000c4ad3e10] worker_thread at ffffa4c136103398\n #22 [ffff8000c4ad3e70] kthread at ffffa4c13610d95c",
"id": "GHSA-f2f9-54cv-v7gf",
"modified": "2026-09-04T15:35:54Z",
"published": "2026-07-25T12:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64415"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2a55fdf9f746a1a6ced7fd62ea1080b8a917e0b0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/60cbe67d1342f34b66df1c2ee328e3cd333767d7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/66366d291f666ddeda5f8c84f253e308de3e6b55"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/69c0e6246575b780ae0d3f411c749bcf13c221f3"
}
],
"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-F3MP-M5HM-H688
Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-07-20 15:31In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix missing barriers when accessing stream->subrequests locklessly
The list of subrequests attached to stream->subrequests is accessed without locks by netfs_collect_read_results() and netfs_collect_write_results(), and then they access subreq->flags without taking a barrier after getting the subreq pointer from the list. Relatedly, the functions that build the list don't use any sort of write barrier when constructing the list to make sure that the NETFS_SREQ_IN_PROGRESS flag is perceived to be set first if no lock is taken.
Fix this by:
(1) Add a new list_add_tail_release() function that uses a release barrier to set the pointer to the new member of the list.
(2) Add a new list_first_entry_or_null_acquire() function that uses an acquire barrier to read the pointer to the first member in a list (or return NULL).
(3) Use list_add_tail_release() when adding a subreq to ->subrequests.
(4) Use list_first_entry_or_null_acquire() when initially accessing the front of the list (when an item is removed, the pointer to the new front iterm is obtained under the same lock).
{
"affected": [],
"aliases": [
"CVE-2026-64067"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-19T16:17:47Z",
"severity": "CRITICAL"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix missing barriers when accessing stream-\u003esubrequests locklessly\n\nThe list of subrequests attached to stream-\u003esubrequests is accessed without\nlocks by netfs_collect_read_results() and netfs_collect_write_results(),\nand then they access subreq-\u003eflags without taking a barrier after getting\nthe subreq pointer from the list. Relatedly, the functions that build the\nlist don\u0027t use any sort of write barrier when constructing the list to make\nsure that the NETFS_SREQ_IN_PROGRESS flag is perceived to be set first if\nno lock is taken.\n\nFix this by:\n\n (1) Add a new list_add_tail_release() function that uses a release barrier\n to set the pointer to the new member of the list.\n\n (2) Add a new list_first_entry_or_null_acquire() function that uses an\n acquire barrier to read the pointer to the first member in a list (or\n return NULL).\n\n (3) Use list_add_tail_release() when adding a subreq to -\u003esubrequests.\n\n (4) Use list_first_entry_or_null_acquire() when initially accessing the\n front of the list (when an item is removed, the pointer to the new\n front iterm is obtained under the same lock).",
"id": "GHSA-f3mp-m5hm-h688",
"modified": "2026-07-20T15:31:58Z",
"published": "2026-07-19T18:31:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64067"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/293a4532c36f38458e38b8879b174ab797718b9d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b5782e2d462c028096f922abca46318cec890670"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F3WQ-3888-8Q7G
Vulnerability from github – Published: 2025-07-28 12:30 – Updated: 2026-05-12 15:30In the Linux kernel, the following vulnerability has been resolved:
mptcp: make fallback action and fallback decision atomic
Syzkaller reported the following splat:
WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 __mptcp_do_fallback net/mptcp/protocol.h:1223 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcp_do_fallback net/mptcp/protocol.h:1244 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 check_fully_established net/mptcp/options.c:982 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153 Modules linked in: CPU: 1 UID: 0 PID: 7704 Comm: syz.3.1419 Not tainted 6.16.0-rc3-gbd5ce2324dba #20 PREEMPT(voluntary) Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:__mptcp_do_fallback net/mptcp/protocol.h:1223 [inline] RIP: 0010:mptcp_do_fallback net/mptcp/protocol.h:1244 [inline] RIP: 0010:check_fully_established net/mptcp/options.c:982 [inline] RIP: 0010:mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153 Code: 24 18 e8 bb 2a 00 fd e9 1b df ff ff e8 b1 21 0f 00 e8 ec 5f c4 fc 44 0f b7 ac 24 b0 00 00 00 e9 54 f1 ff ff e8 d9 5f c4 fc 90 <0f> 0b 90 e9 b8 f4 ff ff e8 8b 2a 00 fd e9 8d e6 ff ff e8 81 2a 00 RSP: 0018:ffff8880a3f08448 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880180a8000 RCX: ffffffff84afcf45 RDX: ffff888090223700 RSI: ffffffff84afdaa7 RDI: 0000000000000001 RBP: ffff888017955780 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff8880180a8910 R14: ffff8880a3e9d058 R15: 0000000000000000 FS: 00005555791b8500(0000) GS:ffff88811c495000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c2800b7 CR3: 0000000058e44000 CR4: 0000000000350ef0 Call Trace: tcp_reset+0x26f/0x2b0 net/ipv4/tcp_input.c:4432 tcp_validate_incoming+0x1057/0x1b60 net/ipv4/tcp_input.c:5975 tcp_rcv_established+0x5b5/0x21f0 net/ipv4/tcp_input.c:6166 tcp_v4_do_rcv+0x5dc/0xa70 net/ipv4/tcp_ipv4.c:1925 tcp_v4_rcv+0x3473/0x44a0 net/ipv4/tcp_ipv4.c:2363 ip_protocol_deliver_rcu+0xba/0x480 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2f1/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:317 [inline] NF_HOOK include/linux/netfilter.h:311 [inline] ip_local_deliver+0x1be/0x560 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:469 [inline] ip_rcv_finish net/ipv4/ip_input.c:447 [inline] NF_HOOK include/linux/netfilter.h:317 [inline] NF_HOOK include/linux/netfilter.h:311 [inline] ip_rcv+0x514/0x810 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core+0x197/0x1e0 net/core/dev.c:5975 __netif_receive_skb+0x1f/0x120 net/core/dev.c:6088 process_backlog+0x301/0x1360 net/core/dev.c:6440 __napi_poll.constprop.0+0xba/0x550 net/core/dev.c:7453 napi_poll net/core/dev.c:7517 [inline] net_rx_action+0xb44/0x1010 net/core/dev.c:7644 handle_softirqs+0x1d0/0x770 kernel/softirq.c:579 do_softirq+0x3f/0x90 kernel/softirq.c:480 __local_bh_enable_ip+0xed/0x110 kernel/softirq.c:407 local_bh_enable include/linux/bottom_half.h:33 [inline] inet_csk_listen_stop+0x2c5/0x1070 net/ipv4/inet_connection_sock.c:1524 mptcp_check_listen_stop.part.0+0x1cc/0x220 net/mptcp/protocol.c:2985 mptcp_check_listen_stop net/mptcp/mib.h:118 [inline] __mptcp_close+0x9b9/0xbd0 net/mptcp/protocol.c:3000 mptcp_close+0x2f/0x140 net/mptcp/protocol.c:3066 inet_release+0xed/0x200 net/ipv4/af_inet.c:435 inet6_release+0x4f/0x70 net/ipv6/af_inet6.c:487 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x402/0xb70 fs/file_table.c:465 task_work_run+0x150/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xd4 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2025-38491"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-28T12:15:31Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: make fallback action and fallback decision atomic\n\nSyzkaller reported the following splat:\n\n WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 __mptcp_do_fallback net/mptcp/protocol.h:1223 [inline]\n WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcp_do_fallback net/mptcp/protocol.h:1244 [inline]\n WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 check_fully_established net/mptcp/options.c:982 [inline]\n WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153\n Modules linked in:\n CPU: 1 UID: 0 PID: 7704 Comm: syz.3.1419 Not tainted 6.16.0-rc3-gbd5ce2324dba #20 PREEMPT(voluntary)\n Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n RIP: 0010:__mptcp_do_fallback net/mptcp/protocol.h:1223 [inline]\n RIP: 0010:mptcp_do_fallback net/mptcp/protocol.h:1244 [inline]\n RIP: 0010:check_fully_established net/mptcp/options.c:982 [inline]\n RIP: 0010:mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153\n Code: 24 18 e8 bb 2a 00 fd e9 1b df ff ff e8 b1 21 0f 00 e8 ec 5f c4 fc 44 0f b7 ac 24 b0 00 00 00 e9 54 f1 ff ff e8 d9 5f c4 fc 90 \u003c0f\u003e 0b 90 e9 b8 f4 ff ff e8 8b 2a 00 fd e9 8d e6 ff ff e8 81 2a 00\n RSP: 0018:ffff8880a3f08448 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: ffff8880180a8000 RCX: ffffffff84afcf45\n RDX: ffff888090223700 RSI: ffffffff84afdaa7 RDI: 0000000000000001\n RBP: ffff888017955780 R08: 0000000000000001 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000\n R13: ffff8880180a8910 R14: ffff8880a3e9d058 R15: 0000000000000000\n FS: 00005555791b8500(0000) GS:ffff88811c495000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000110c2800b7 CR3: 0000000058e44000 CR4: 0000000000350ef0\n Call Trace:\n \u003cIRQ\u003e\n tcp_reset+0x26f/0x2b0 net/ipv4/tcp_input.c:4432\n tcp_validate_incoming+0x1057/0x1b60 net/ipv4/tcp_input.c:5975\n tcp_rcv_established+0x5b5/0x21f0 net/ipv4/tcp_input.c:6166\n tcp_v4_do_rcv+0x5dc/0xa70 net/ipv4/tcp_ipv4.c:1925\n tcp_v4_rcv+0x3473/0x44a0 net/ipv4/tcp_ipv4.c:2363\n ip_protocol_deliver_rcu+0xba/0x480 net/ipv4/ip_input.c:205\n ip_local_deliver_finish+0x2f1/0x500 net/ipv4/ip_input.c:233\n NF_HOOK include/linux/netfilter.h:317 [inline]\n NF_HOOK include/linux/netfilter.h:311 [inline]\n ip_local_deliver+0x1be/0x560 net/ipv4/ip_input.c:254\n dst_input include/net/dst.h:469 [inline]\n ip_rcv_finish net/ipv4/ip_input.c:447 [inline]\n NF_HOOK include/linux/netfilter.h:317 [inline]\n NF_HOOK include/linux/netfilter.h:311 [inline]\n ip_rcv+0x514/0x810 net/ipv4/ip_input.c:567\n __netif_receive_skb_one_core+0x197/0x1e0 net/core/dev.c:5975\n __netif_receive_skb+0x1f/0x120 net/core/dev.c:6088\n process_backlog+0x301/0x1360 net/core/dev.c:6440\n __napi_poll.constprop.0+0xba/0x550 net/core/dev.c:7453\n napi_poll net/core/dev.c:7517 [inline]\n net_rx_action+0xb44/0x1010 net/core/dev.c:7644\n handle_softirqs+0x1d0/0x770 kernel/softirq.c:579\n do_softirq+0x3f/0x90 kernel/softirq.c:480\n \u003c/IRQ\u003e\n \u003cTASK\u003e\n __local_bh_enable_ip+0xed/0x110 kernel/softirq.c:407\n local_bh_enable include/linux/bottom_half.h:33 [inline]\n inet_csk_listen_stop+0x2c5/0x1070 net/ipv4/inet_connection_sock.c:1524\n mptcp_check_listen_stop.part.0+0x1cc/0x220 net/mptcp/protocol.c:2985\n mptcp_check_listen_stop net/mptcp/mib.h:118 [inline]\n __mptcp_close+0x9b9/0xbd0 net/mptcp/protocol.c:3000\n mptcp_close+0x2f/0x140 net/mptcp/protocol.c:3066\n inet_release+0xed/0x200 net/ipv4/af_inet.c:435\n inet6_release+0x4f/0x70 net/ipv6/af_inet6.c:487\n __sock_release+0xb3/0x270 net/socket.c:649\n sock_close+0x1c/0x30 net/socket.c:1439\n __fput+0x402/0xb70 fs/file_table.c:465\n task_work_run+0x150/0x240 kernel/task_work.c:227\n resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n exit_to_user_mode_loop+0xd4\n---truncated---",
"id": "GHSA-f3wq-3888-8q7g",
"modified": "2026-05-12T15:30:58Z",
"published": "2025-07-28T12:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38491"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1d82a8fe6ee4afdc92f4e8808c9dad2a6095bbc5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/54999dea879fecb761225e28f274b40662918c30"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5586518bec27666c747cd52aabb62d485686d0bf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/75a4c9ab8a7af0d76b31ccd1188ed178c38b35d2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f8a1d9b18c5efc76784f5a326e905f641f839894"
},
{
"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"
}
]
}
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.