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.
720 vulnerabilities reference this CWE, most recent first.
GHSA-Q27Q-H2JW-QQ6C
Vulnerability from github – Published: 2022-03-04 00:00 – Updated: 2024-04-01 15:30An improper locking issue was found in the virStoragePoolLookupByTargetPath API of libvirt. It occurs in the storagePoolLookupByTargetPath function where a locked virStoragePoolObj object is not properly released on ACL permission failure. Clients connecting to the read-write socket with limited ACL permissions could use this flaw to acquire the lock and prevent other users from accessing storage pool/volume APIs, resulting in a denial of service condition. The highest threat from this vulnerability is to system availability.
{
"affected": [],
"aliases": [
"CVE-2021-3667"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-02T23:15:00Z",
"severity": "MODERATE"
},
"details": "An improper locking issue was found in the virStoragePoolLookupByTargetPath API of libvirt. It occurs in the storagePoolLookupByTargetPath function where a locked virStoragePoolObj object is not properly released on ACL permission failure. Clients connecting to the read-write socket with limited ACL permissions could use this flaw to acquire the lock and prevent other users from accessing storage pool/volume APIs, resulting in a denial of service condition. The highest threat from this vulnerability is to system availability.",
"id": "GHSA-q27q-h2jw-qq6c",
"modified": "2024-04-01T15:30:27Z",
"published": "2022-03-04T00:00:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3667"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2021:3703"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2021:3704"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2021:4191"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2021-3667"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1986094"
},
{
"type": "WEB",
"url": "https://gitlab.com/libvirt/libvirt/-/commit/447f69dec47e1b0bd15ecd7cd49a9fd3b050fb87"
},
{
"type": "WEB",
"url": "https://libvirt.org/git/?p=libvirt.git%3Ba=commit%3Bh=447f69dec47e1b0bd15ecd7cd49a9fd3b050fb87"
},
{
"type": "WEB",
"url": "https://libvirt.org/git/?p=libvirt.git;a=commit;h=447f69dec47e1b0bd15ecd7cd49a9fd3b050fb87"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/04/msg00000.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202210-06"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20220331-0005"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-Q2GX-5VC4-PJJW
Vulnerability from github – Published: 2024-09-04 21:30 – Updated: 2024-09-06 18:31In the Linux kernel, the following vulnerability has been resolved:
drm/xe/preempt_fence: enlarge the fence critical section
It is really easy to introduce subtle deadlocks in preempt_fence_work_func() since we operate on single global ordered-wq for signalling our preempt fences behind the scenes, so even though we signal a particular fence, everything in the callback should be in the fence critical section, since blocking in the callback will prevent other published fences from signalling. If we enlarge the fence critical section to cover the entire callback, then lockdep should be able to understand this better, and complain if we grab a sensitive lock like vm->lock, which is also held when waiting on preempt fences.
{
"affected": [],
"aliases": [
"CVE-2024-44956"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-04T19:15:30Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/preempt_fence: enlarge the fence critical section\n\nIt is really easy to introduce subtle deadlocks in\npreempt_fence_work_func() since we operate on single global ordered-wq\nfor signalling our preempt fences behind the scenes, so even though we\nsignal a particular fence, everything in the callback should be in the\nfence critical section, since blocking in the callback will prevent\nother published fences from signalling. If we enlarge the fence critical\nsection to cover the entire callback, then lockdep should be able to\nunderstand this better, and complain if we grab a sensitive lock like\nvm-\u003elock, which is also held when waiting on preempt fences.",
"id": "GHSA-q2gx-5vc4-pjjw",
"modified": "2024-09-06T18:31:28Z",
"published": "2024-09-04T21:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44956"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3cd1585e57908b6efcd967465ef7685f40b2a294"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/458bb83119dfee5d14c677f7846dd9363817006f"
}
],
"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-Q2H8-9338-55XQ
Vulnerability from github – Published: 2025-05-01 15:31 – Updated: 2025-11-04 18:31In the Linux kernel, the following vulnerability has been resolved:
jfs: Prevent copying of nlink with value 0 from disk inode
syzbot report a deadlock in diFree. [1]
When calling "ioctl$LOOP_SET_STATUS64", the offset value passed in is 4, which does not match the mounted loop device, causing the mapping of the mounted loop device to be invalidated.
When creating the directory and creating the inode of iag in diReadSpecial(), read the page of fixed disk inode (AIT) in raw mode in read_metapage(), the metapage data it returns is corrupted, which causes the nlink value of 0 to be assigned to the iag inode when executing copy_from_dinode(), which ultimately causes a deadlock when entering diFree().
To avoid this, first check the nlink value of dinode before setting iag inode.
[1] WARNING: possible recursive locking detected 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted
syz-executor301/5309 is trying to acquire lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889
but task is already holding lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630
other info that might help us debug this: Possible unsafe locking scenario:
CPU0
----
lock(&(imap->im_aglock[index])); lock(&(imap->im_aglock[index]));
*** DEADLOCK ***
May be due to missing lock nesting notation
5 locks held by syz-executor301/5309: #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515 #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline] #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026 #2: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630 #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669 #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669
stack backtrace: CPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037 check_deadlock kernel/locking/lockdep.c:3089 [inline] validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891 __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889 jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156 evict+0x4e8/0x9b0 fs/inode.c:725 diFreeSpecial fs/jfs/jfs_imap.c:552 [inline] duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022 diNewIAG fs/jfs/jfs_imap.c:2597 [inline] diAllocExt fs/jfs/jfs_imap.c:1905 [inline] diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669 diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 do_syscall_x64 arch/x86/en ---truncated---
{
"affected": [],
"aliases": [
"CVE-2025-37741"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-01T13:15:52Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\njfs: Prevent copying of nlink with value 0 from disk inode\n\nsyzbot report a deadlock in diFree. [1]\n\nWhen calling \"ioctl$LOOP_SET_STATUS64\", the offset value passed in is 4,\nwhich does not match the mounted loop device, causing the mapping of the\nmounted loop device to be invalidated.\n\nWhen creating the directory and creating the inode of iag in diReadSpecial(),\nread the page of fixed disk inode (AIT) in raw mode in read_metapage(), the\nmetapage data it returns is corrupted, which causes the nlink value of 0 to be\nassigned to the iag inode when executing copy_from_dinode(), which ultimately\ncauses a deadlock when entering diFree().\n\nTo avoid this, first check the nlink value of dinode before setting iag inode.\n\n[1]\nWARNING: possible recursive locking detected\n6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted\n--------------------------------------------\nsyz-executor301/5309 is trying to acquire lock:\nffff888044548920 (\u0026(imap-\u003eim_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889\n\nbut task is already holding lock:\nffff888044548920 (\u0026(imap-\u003eim_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(\u0026(imap-\u003eim_aglock[index]));\n lock(\u0026(imap-\u003eim_aglock[index]));\n\n *** DEADLOCK ***\n\n May be due to missing lock nesting notation\n\n5 locks held by syz-executor301/5309:\n #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515\n #1: ffff88804755b390 (\u0026type-\u003ei_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline]\n #1: ffff88804755b390 (\u0026type-\u003ei_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026\n #2: ffff888044548920 (\u0026(imap-\u003eim_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630\n #3: ffff888044548890 (\u0026imap-\u003eim_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline]\n #3: ffff888044548890 (\u0026imap-\u003eim_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n #3: ffff888044548890 (\u0026imap-\u003eim_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669\n #4: ffff88804755a618 (\u0026jfs_ip-\u003erdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline]\n #4: ffff88804755a618 (\u0026jfs_ip-\u003erdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n #4: ffff88804755a618 (\u0026jfs_ip-\u003erdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669\n\nstack backtrace:\nCPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nCall Trace:\n \u003cTASK\u003e\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037\n check_deadlock kernel/locking/lockdep.c:3089 [inline]\n validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891\n __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825\n __mutex_lock_common kernel/locking/mutex.c:608 [inline]\n __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752\n diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889\n jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156\n evict+0x4e8/0x9b0 fs/inode.c:725\n diFreeSpecial fs/jfs/jfs_imap.c:552 [inline]\n duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022\n diNewIAG fs/jfs/jfs_imap.c:2597 [inline]\n diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669\n diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590\n ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56\n jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225\n vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257\n do_mkdirat+0x264/0x3a0 fs/namei.c:4280\n __do_sys_mkdirat fs/namei.c:4295 [inline]\n __se_sys_mkdirat fs/namei.c:4293 [inline]\n __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293\n do_syscall_x64 arch/x86/en\n---truncated---",
"id": "GHSA-q2h8-9338-55xq",
"modified": "2025-11-04T18:31:32Z",
"published": "2025-05-01T15:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37741"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5b2f26d3fba4e9aac314f8bc0963b3fc28c0e456"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/86bfeaa18f9e4615b97f2d613e0fcc4ced196527"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8b5ce75f8bd3ddf480cc0a240d7ff5cdea0444f9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/994787341358816d91b2fded288ecb7f129f2b27"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a2b560815528ae8e266fca6038bb5585d13aaef4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aeb926e605f97857504bdf748f575e40617e2ef9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b3c4884b987e5d8d0ec061a4d52653c4f4b9c37e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b61e69bb1c049cf507e3c654fa3dc1568231bd07"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c9541c2bd0edbdbc5c1148a84d3b48dc8d1b8af2"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.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-Q37H-R28R-J29C
Vulnerability from github – Published: 2025-05-02 18:31 – Updated: 2025-11-12 18:31In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: u_audio: don't let userspace block driver unbind
In the unbind callback for f_uac1 and f_uac2, a call to snd_card_free() via g_audio_cleanup() will disconnect the card and then wait for all resources to be released, which happens when the refcount falls to zero. Since userspace can keep the refcount incremented by not closing the relevant file descriptor, the call to unbind may block indefinitely. This can cause a deadlock during reboot, as evidenced by the following blocked task observed on my machine:
task:reboot state:D stack:0 pid:2827 ppid:569 flags:0x0000000c Call trace: __switch_to+0xc8/0x140 __schedule+0x2f0/0x7c0 schedule+0x60/0xd0 schedule_timeout+0x180/0x1d4 wait_for_completion+0x78/0x180 snd_card_free+0x90/0xa0 g_audio_cleanup+0x2c/0x64 afunc_unbind+0x28/0x60 ... kernel_restart+0x4c/0xac __do_sys_reboot+0xcc/0x1ec __arm64_sys_reboot+0x28/0x30 invoke_syscall+0x4c/0x110 ...
The issue can also be observed by opening the card with arecord and then stopping the process through the shell before unbinding:
# arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null Recording WAVE '/dev/null' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo ^Z[1]+ Stopped arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null # echo gadget.0 > /sys/bus/gadget/drivers/configfs-gadget/unbind (observe that the unbind command never finishes)
Fix the problem by using snd_card_free_when_closed() instead, which will still disconnect the card as desired, but defer the task of freeing the resources to the core once userspace closes its file descriptor.
{
"affected": [],
"aliases": [
"CVE-2023-53045"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-02T16:15:23Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: u_audio: don\u0027t let userspace block driver unbind\n\nIn the unbind callback for f_uac1 and f_uac2, a call to snd_card_free()\nvia g_audio_cleanup() will disconnect the card and then wait for all\nresources to be released, which happens when the refcount falls to zero.\nSince userspace can keep the refcount incremented by not closing the\nrelevant file descriptor, the call to unbind may block indefinitely.\nThis can cause a deadlock during reboot, as evidenced by the following\nblocked task observed on my machine:\n\n task:reboot state:D stack:0 pid:2827 ppid:569 flags:0x0000000c\n Call trace:\n __switch_to+0xc8/0x140\n __schedule+0x2f0/0x7c0\n schedule+0x60/0xd0\n schedule_timeout+0x180/0x1d4\n wait_for_completion+0x78/0x180\n snd_card_free+0x90/0xa0\n g_audio_cleanup+0x2c/0x64\n afunc_unbind+0x28/0x60\n ...\n kernel_restart+0x4c/0xac\n __do_sys_reboot+0xcc/0x1ec\n __arm64_sys_reboot+0x28/0x30\n invoke_syscall+0x4c/0x110\n ...\n\nThe issue can also be observed by opening the card with arecord and\nthen stopping the process through the shell before unbinding:\n\n # arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null\n Recording WAVE \u0027/dev/null\u0027 : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo\n ^Z[1]+ Stopped arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null\n # echo gadget.0 \u003e /sys/bus/gadget/drivers/configfs-gadget/unbind\n (observe that the unbind command never finishes)\n\nFix the problem by using snd_card_free_when_closed() instead, which will\nstill disconnect the card as desired, but defer the task of freeing the\nresources to the core once userspace closes its file descriptor.",
"id": "GHSA-q37h-r28r-j29c",
"modified": "2025-11-12T18:31:03Z",
"published": "2025-05-02T18:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53045"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0eda2004f38d95ef5715d62be884cd344260535b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3256e152b645fc1e788ba44c2d8ced690113e3e6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/33f341c1fc60e172a3515c51bdabee11e83d1ee9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3bc7324e4911351e39c54a62e6ca46321cb10faf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e016ef2e72da93a2ea7afbb45de1b481b44d761"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/43ca70753dfffd517d2af126da28690f8f615605"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6c67ed9ad9b83e453e808f9b31a931a20a25629b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b131989797f7287d7fdadb2bababc05a15d44750"
}
],
"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-Q383-XWJ3-RCF5
Vulnerability from github – Published: 2025-02-27 03:34 – Updated: 2025-12-16 18:31In the Linux kernel, the following vulnerability has been resolved:
tcp: correct handling of extreme memory squeeze
Testing with iperf3 using the "pasta" protocol splicer has revealed a problem in the way tcp handles window advertising in extreme memory squeeze situations.
Under memory pressure, a socket endpoint may temporarily advertise a zero-sized window, but this is not stored as part of the socket data. The reasoning behind this is that it is considered a temporary setting which shouldn't influence any further calculations.
However, if we happen to stall at an unfortunate value of the current window size, the algorithm selecting a new value will consistently fail to advertise a non-zero window once we have freed up enough memory. This means that this side's notion of the current window size is different from the one last advertised to the peer, causing the latter to not send any data to resolve the sitution.
The problem occurs on the iperf3 server side, and the socket in question is a completely regular socket with the default settings for the fedora40 kernel. We do not use SO_PEEK or SO_RCVBUF on the socket.
The following excerpt of a logging session, with own comments added, shows more in detail what is happening:
// tcp_v4_rcv(->) // tcp_rcv_established(->) 5201<->39222: ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ====
5201<->39222: DROPPING skb [265600160..265665640], reason: SKB_DROP_REASON_PROTO_MEM [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184] [copied_seq 259909392->260034360 (124968), unread 5565800, qlen 85, ofoq 0] [OFO queue: gap: 65480, len: 0]
[tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]
5201<->39222: (inet_csk(sk)->icsk_ack.pending & ICSK_ACK_NOMEM) ? --> TRUE [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160] returning 0
5201<->39222: ADVERTISING WIN 0, ACK_SEQ: 265600160
// Receive queue is at 85 buffers and we are out of memory. // We drop the incoming buffer, although it is in sequence, and decide // to send an advertisement with a window of zero. // We don't update tp->rcv_wnd and tp->rcv_wup accordingly, which means // we unconditionally shrink the window.
5201<->39222: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160 5201<->39222: new_win = 0, win_now = 131184, 2 * win_now = 262368: new_win >= (2 * win_now) ? --> time_to_ack = 0: NOT calling tcp_send_ack() [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]
[rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]
[copied_seq 260040464->260040464 (0), unread 5559696, qlen 85, ofoq 0]
returning 6104 bytes
// After each read, the algorithm for calculating the new receive // window in __tcp_cleanup_rbuf() finds it is too small to advertise // or to update tp->rcv_wnd. // Meanwhile, the peer thinks the window is zero, and will not send // any more data to trigger an update from the interrupt mode side.
5201<->39222: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160 5201<->39222: [new_win = 262144, win_now = 131184, 2 * win_n ---truncated---
{
"affected": [],
"aliases": [
"CVE-2025-21710"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-27T02:15:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: correct handling of extreme memory squeeze\n\nTesting with iperf3 using the \"pasta\" protocol splicer has revealed\na problem in the way tcp handles window advertising in extreme memory\nsqueeze situations.\n\nUnder memory pressure, a socket endpoint may temporarily advertise\na zero-sized window, but this is not stored as part of the socket data.\nThe reasoning behind this is that it is considered a temporary setting\nwhich shouldn\u0027t influence any further calculations.\n\nHowever, if we happen to stall at an unfortunate value of the current\nwindow size, the algorithm selecting a new value will consistently fail\nto advertise a non-zero window once we have freed up enough memory.\nThis means that this side\u0027s notion of the current window size is\ndifferent from the one last advertised to the peer, causing the latter\nto not send any data to resolve the sitution.\n\nThe problem occurs on the iperf3 server side, and the socket in question\nis a completely regular socket with the default settings for the\nfedora40 kernel. We do not use SO_PEEK or SO_RCVBUF on the socket.\n\nThe following excerpt of a logging session, with own comments added,\nshows more in detail what is happening:\n\n// tcp_v4_rcv(-\u003e)\n// tcp_rcv_established(-\u003e)\n[5201\u003c-\u003e39222]: ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ====\n[5201\u003c-\u003e39222]: tcp_data_queue(-\u003e)\n[5201\u003c-\u003e39222]: DROPPING skb [265600160..265665640], reason: SKB_DROP_REASON_PROTO_MEM\n [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]\n [copied_seq 259909392-\u003e260034360 (124968), unread 5565800, qlen 85, ofoq 0]\n [OFO queue: gap: 65480, len: 0]\n[5201\u003c-\u003e39222]: tcp_data_queue(\u003c-)\n[5201\u003c-\u003e39222]: __tcp_transmit_skb(-\u003e)\n [tp-\u003ercv_wup: 265469200, tp-\u003ercv_wnd: 262144, tp-\u003ercv_nxt 265600160]\n[5201\u003c-\u003e39222]: tcp_select_window(-\u003e)\n[5201\u003c-\u003e39222]: (inet_csk(sk)-\u003eicsk_ack.pending \u0026 ICSK_ACK_NOMEM) ? --\u003e TRUE\n [tp-\u003ercv_wup: 265469200, tp-\u003ercv_wnd: 262144, tp-\u003ercv_nxt 265600160]\n returning 0\n[5201\u003c-\u003e39222]: tcp_select_window(\u003c-)\n[5201\u003c-\u003e39222]: ADVERTISING WIN 0, ACK_SEQ: 265600160\n[5201\u003c-\u003e39222]: [__tcp_transmit_skb(\u003c-)\n[5201\u003c-\u003e39222]: tcp_rcv_established(\u003c-)\n[5201\u003c-\u003e39222]: tcp_v4_rcv(\u003c-)\n\n// Receive queue is at 85 buffers and we are out of memory.\n// We drop the incoming buffer, although it is in sequence, and decide\n// to send an advertisement with a window of zero.\n// We don\u0027t update tp-\u003ercv_wnd and tp-\u003ercv_wup accordingly, which means\n// we unconditionally shrink the window.\n\n[5201\u003c-\u003e39222]: tcp_recvmsg_locked(-\u003e)\n[5201\u003c-\u003e39222]: __tcp_cleanup_rbuf(-\u003e) tp-\u003ercv_wup: 265469200, tp-\u003ercv_wnd: 262144, tp-\u003ercv_nxt 265600160\n[5201\u003c-\u003e39222]: [new_win = 0, win_now = 131184, 2 * win_now = 262368]\n[5201\u003c-\u003e39222]: [new_win \u003e= (2 * win_now) ? --\u003e time_to_ack = 0]\n[5201\u003c-\u003e39222]: NOT calling tcp_send_ack()\n [tp-\u003ercv_wup: 265469200, tp-\u003ercv_wnd: 262144, tp-\u003ercv_nxt 265600160]\n[5201\u003c-\u003e39222]: __tcp_cleanup_rbuf(\u003c-)\n [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]\n [copied_seq 260040464-\u003e260040464 (0), unread 5559696, qlen 85, ofoq 0]\n returning 6104 bytes\n[5201\u003c-\u003e39222]: tcp_recvmsg_locked(\u003c-)\n\n// After each read, the algorithm for calculating the new receive\n// window in __tcp_cleanup_rbuf() finds it is too small to advertise\n// or to update tp-\u003ercv_wnd.\n// Meanwhile, the peer thinks the window is zero, and will not send\n// any more data to trigger an update from the interrupt mode side.\n\n[5201\u003c-\u003e39222]: tcp_recvmsg_locked(-\u003e)\n[5201\u003c-\u003e39222]: __tcp_cleanup_rbuf(-\u003e) tp-\u003ercv_wup: 265469200, tp-\u003ercv_wnd: 262144, tp-\u003ercv_nxt 265600160\n[5201\u003c-\u003e39222]: [new_win = 262144, win_now = 131184, 2 * win_n\n---truncated---",
"id": "GHSA-q383-xwj3-rcf5",
"modified": "2025-12-16T18:31:27Z",
"published": "2025-02-27T03:34:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21710"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1dd823a46e25ffde1492c391934f69a9e5eb574f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8c670bdfa58e48abad1d5b6ca1ee843ca91f7303"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b01e7ceb35dcb7ffad413da657b78c3340a09039"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b4055e2fe96f4ef101d8af0feb056d78d77514ff"
}
],
"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-Q3V6-CHW5-G495
Vulnerability from github – Published: 2025-05-01 15:31 – Updated: 2025-11-05 18:14In the Linux kernel, the following vulnerability has been resolved:
PCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t type
The access to the PCI config space via pci_ops::read and pci_ops::write is a low-level hardware access. The functions can be accessed with disabled interrupts even on PREEMPT_RT. The pci_lock is a raw_spinlock_t for this purpose.
A spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot be acquired with disabled interrupts. The vmd_dev::cfg_lock is accessed in the same context as the pci_lock.
Make vmd_dev::cfg_lock a raw_spinlock_t type so it can be used with interrupts disabled.
This was reported as:
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 Call Trace: rt_spin_lock+0x4e/0x130 vmd_pci_read+0x8d/0x100 [vmd] pci_user_read_config_byte+0x6f/0xe0 pci_read_config+0xfe/0x290 sysfs_kf_bin_read+0x68/0x90
[bigeasy: reword commit message] Tested-off-by: Luis Claudio R. Goncalves lgoncalv@redhat.com [kwilczynski: commit log] [bhelgaas: add back report info from https://lore.kernel.org/lkml/20241218115951.83062-1-ryotkkr98@gmail.com/]
{
"affected": [],
"aliases": [
"CVE-2025-23161"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-01T13:15:52Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t type\n\nThe access to the PCI config space via pci_ops::read and pci_ops::write is\na low-level hardware access. The functions can be accessed with disabled\ninterrupts even on PREEMPT_RT. The pci_lock is a raw_spinlock_t for this\npurpose.\n\nA spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot be\nacquired with disabled interrupts. The vmd_dev::cfg_lock is accessed in\nthe same context as the pci_lock.\n\nMake vmd_dev::cfg_lock a raw_spinlock_t type so it can be used with\ninterrupts disabled.\n\nThis was reported as:\n\n BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n Call Trace:\n rt_spin_lock+0x4e/0x130\n vmd_pci_read+0x8d/0x100 [vmd]\n pci_user_read_config_byte+0x6f/0xe0\n pci_read_config+0xfe/0x290\n sysfs_kf_bin_read+0x68/0x90\n\n[bigeasy: reword commit message]\nTested-off-by: Luis Claudio R. Goncalves \u003clgoncalv@redhat.com\u003e\n[kwilczynski: commit log]\n[bhelgaas: add back report info from\nhttps://lore.kernel.org/lkml/20241218115951.83062-1-ryotkkr98@gmail.com/]",
"id": "GHSA-q3v6-chw5-g495",
"modified": "2025-11-05T18:14:26Z",
"published": "2025-05-01T15:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23161"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/13e5148f70e81991acbe0bab5b1b50ba699116e7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/18056a48669a040bef491e63b25896561ee14d90"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/20d0a9062c031068fa39f725a32f182b709b5525"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2358046ead696ca5c7c628d6c0e2c6792619a3e5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5c3cfcf0b4bf43530788b08a8eaf7896ec567484"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c250262d6485ca333e9821f85b07eb383ec546b1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c2968c812339593ac6e2bdd5cc3adabe3f05fa53"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.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-Q4HG-RMQ2-52Q9
Vulnerability from github – Published: 2019-06-26 01:09 – Updated: 2024-03-11 15:39The fix for CVE-2019-0199 was incomplete and did not address HTTP/2 connection window exhaustion on write in Apache Tomcat versions 9.0.0.M1 to 9.0.19 and 8.5.0 to 8.5.40 . By not sending WINDOW_UPDATE messages for the connection window (stream 0) clients were able to cause server-side threads to block eventually leading to thread exhaustion and a DoS.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0.M1"
},
{
"fixed": "9.0.20"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "8.5.0"
},
{
"fixed": "8.5.41"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-10072"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": true,
"github_reviewed_at": "2019-06-26T00:56:45Z",
"nvd_published_at": "2019-06-21T18:15:00Z",
"severity": "HIGH"
},
"details": "The fix for CVE-2019-0199 was incomplete and did not address HTTP/2 connection window exhaustion on write in Apache Tomcat versions 9.0.0.M1 to 9.0.19 and 8.5.0 to 8.5.40 . By not sending WINDOW_UPDATE messages for the connection window (stream 0) clients were able to cause server-side threads to block eventually leading to thread exhaustion and a DoS.",
"id": "GHSA-q4hg-rmq2-52q9",
"modified": "2024-03-11T15:39:14Z",
"published": "2019-06-26T01:09:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10072"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/0bcd69c9dd8ae0ff424f2cd46de51583510b7f35"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/7f748eb6bfaba5207c89dbd7d5adf50fae847145"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/8d14c6f21d29768a39be4b6b9517060dc6606758"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/ada725a50a60867af3422c8e612aecaeea856a9a"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20190625-0002"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K17321505"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-8.html"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-9.html"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4128-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4128-2"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20200227033743/http://www.securityfocus.com/bid/108874"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2020/dsa-4680"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2020.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2020.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2020.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/technetwork/security-advisory/cpuoct2019-5072832.html"
},
{
"type": "WEB",
"url": "https://www.synology.com/security/advisory/Synology_SA_19_29"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/raba0fabaf4d56d4325ab2aca8814f0b30a237ab83d8106b115ee279a@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/raba0fabaf4d56d4325ab2aca8814f0b30a237ab83d8106b115ee279a%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r6ccee4e849bc77df0840c7f853f6bd09d426f6741247da2b7429d5d9@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r6ccee4e849bc77df0840c7f853f6bd09d426f6741247da2b7429d5d9%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r48c1444845fe15a823e1374674bfc297d5008a5453788099ea14caf0@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r48c1444845fe15a823e1374674bfc297d5008a5453788099ea14caf0%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3bbb800a816d0a51eccc5a228c58736960a9fffafa581a225834d97d@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3bbb800a816d0a51eccc5a228c58736960a9fffafa581a225834d97d%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/df1a2c1b87c8a6c500ecdbbaf134c7f1491c8d79d98b48c6b9f0fa6a@%3Cannounce.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/df1a2c1b87c8a6c500ecdbbaf134c7f1491c8d79d98b48c6b9f0fa6a%40%3Cannounce.tomcat.apache.org%3E"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/tomcat"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3931"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3929"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-01/msg00013.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Improper Locking in Apache Tomcat"
}
GHSA-Q4JH-G383-RJCG
Vulnerability from github – Published: 2024-04-03 18:30 – Updated: 2025-02-03 18:30In the Linux kernel, the following vulnerability has been resolved:
net: implement lockless setsockopt(SO_PEEK_OFF)
syzbot reported a lockdep violation [1] involving af_unix support of SO_PEEK_OFF.
Since SO_PEEK_OFF is inherently not thread safe (it uses a per-socket sk_peek_off field), there is really no point to enforce a pointless thread safety in the kernel.
After this patch :
-
setsockopt(SO_PEEK_OFF) no longer acquires the socket lock.
-
skb_consume_udp() no longer has to acquire the socket lock.
-
af_unix no longer needs a special version of sk_set_peek_off(), because it does not lock u->iolock anymore.
As a followup, we could replace prot->set_peek_off to be a boolean and avoid an indirect call, since we always use sk_set_peek_off().
[1]
WARNING: possible circular locking dependency detected 6.8.0-rc4-syzkaller-00267-g0f1dd5e91e2b #0 Not tainted
syz-executor.2/30025 is trying to acquire lock: ffff8880765e7d80 (&u->iolock){+.+.}-{3:3}, at: unix_set_peek_off+0x26/0xa0 net/unix/af_unix.c:789
but task is already holding lock: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1691 [inline] ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sockopt_lock_sock net/core/sock.c:1060 [inline] ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sk_setsockopt+0xe52/0x3360 net/core/sock.c:1193
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (sk_lock-AF_UNIX){+.+.}-{0:0}: lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 lock_sock_nested+0x48/0x100 net/core/sock.c:3524 lock_sock include/net/sock.h:1691 [inline] __unix_dgram_recvmsg+0x1275/0x12c0 net/unix/af_unix.c:2415 sock_recvmsg_nosec+0x18e/0x1d0 net/socket.c:1046 _sysrecvmsg+0x3c0/0x470 net/socket.c:2801 _sys_recvmsg net/socket.c:2845 [inline] do_recvmmsg+0x474/0xae0 net/socket.c:2939 __sys_recvmmsg net/socket.c:3018 [inline] __do_sys_recvmmsg net/socket.c:3041 [inline] __se_sys_recvmmsg net/socket.c:3034 [inline] __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77
-> #0 (&u->iolock){+.+.}-{3:3}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 unix_set_peek_off+0x26/0xa0 net/unix/af_unix.c:789 sk_setsockopt+0x207e/0x3360 do_sock_setsockopt+0x2fb/0x720 net/socket.c:2307 __sys_setsockopt+0x1ad/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(sk_lock-AF_UNIX); lock(&u->iolock); lock(sk_lock-AF_UNIX); lock(&u->iolock);
*** DEADLOCK ***
1 lock held by syz-executor.2/30025: #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1691 [inline] #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sockopt_lock_sock net/core/sock.c:1060 [inline] #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sk_setsockopt+0xe52/0x3360 net/core/sock.c:1193
stack backtrace: CPU: 0 PID: 30025 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00267-g0f1dd5e91e2b #0 Hardware name: Google Google C ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-26732"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-03T17:15:50Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: implement lockless setsockopt(SO_PEEK_OFF)\n\nsyzbot reported a lockdep violation [1] involving af_unix\nsupport of SO_PEEK_OFF.\n\nSince SO_PEEK_OFF is inherently not thread safe (it uses a per-socket\nsk_peek_off field), there is really no point to enforce a pointless\nthread safety in the kernel.\n\nAfter this patch :\n\n- setsockopt(SO_PEEK_OFF) no longer acquires the socket lock.\n\n- skb_consume_udp() no longer has to acquire the socket lock.\n\n- af_unix no longer needs a special version of sk_set_peek_off(),\n because it does not lock u-\u003eiolock anymore.\n\nAs a followup, we could replace prot-\u003eset_peek_off to be a boolean\nand avoid an indirect call, since we always use sk_set_peek_off().\n\n[1]\n\nWARNING: possible circular locking dependency detected\n6.8.0-rc4-syzkaller-00267-g0f1dd5e91e2b #0 Not tainted\n\nsyz-executor.2/30025 is trying to acquire lock:\n ffff8880765e7d80 (\u0026u-\u003eiolock){+.+.}-{3:3}, at: unix_set_peek_off+0x26/0xa0 net/unix/af_unix.c:789\n\nbut task is already holding lock:\n ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1691 [inline]\n ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sockopt_lock_sock net/core/sock.c:1060 [inline]\n ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sk_setsockopt+0xe52/0x3360 net/core/sock.c:1193\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u003e #1 (sk_lock-AF_UNIX){+.+.}-{0:0}:\n lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754\n lock_sock_nested+0x48/0x100 net/core/sock.c:3524\n lock_sock include/net/sock.h:1691 [inline]\n __unix_dgram_recvmsg+0x1275/0x12c0 net/unix/af_unix.c:2415\n sock_recvmsg_nosec+0x18e/0x1d0 net/socket.c:1046\n ____sys_recvmsg+0x3c0/0x470 net/socket.c:2801\n ___sys_recvmsg net/socket.c:2845 [inline]\n do_recvmmsg+0x474/0xae0 net/socket.c:2939\n __sys_recvmmsg net/socket.c:3018 [inline]\n __do_sys_recvmmsg net/socket.c:3041 [inline]\n __se_sys_recvmmsg net/socket.c:3034 [inline]\n __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034\n do_syscall_64+0xf9/0x240\n entry_SYSCALL_64_after_hwframe+0x6f/0x77\n\n-\u003e #0 (\u0026u-\u003eiolock){+.+.}-{3:3}:\n check_prev_add kernel/locking/lockdep.c:3134 [inline]\n check_prevs_add kernel/locking/lockdep.c:3253 [inline]\n validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869\n __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137\n lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754\n __mutex_lock_common kernel/locking/mutex.c:608 [inline]\n __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752\n unix_set_peek_off+0x26/0xa0 net/unix/af_unix.c:789\n sk_setsockopt+0x207e/0x3360\n do_sock_setsockopt+0x2fb/0x720 net/socket.c:2307\n __sys_setsockopt+0x1ad/0x250 net/socket.c:2334\n __do_sys_setsockopt net/socket.c:2343 [inline]\n __se_sys_setsockopt net/socket.c:2340 [inline]\n __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xf9/0x240\n entry_SYSCALL_64_after_hwframe+0x6f/0x77\n\nother info that might help us debug this:\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(sk_lock-AF_UNIX);\n lock(\u0026u-\u003eiolock);\n lock(sk_lock-AF_UNIX);\n lock(\u0026u-\u003eiolock);\n\n *** DEADLOCK ***\n\n1 lock held by syz-executor.2/30025:\n #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1691 [inline]\n #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sockopt_lock_sock net/core/sock.c:1060 [inline]\n #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sk_setsockopt+0xe52/0x3360 net/core/sock.c:1193\n\nstack backtrace:\nCPU: 0 PID: 30025 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00267-g0f1dd5e91e2b #0\nHardware name: Google Google C\n---truncated---",
"id": "GHSA-q4jh-g383-rjcg",
"modified": "2025-02-03T18:30:35Z",
"published": "2024-04-03T18:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26732"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/56667da7399eb19af857e30f41bea89aa6fa812c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/897f75e2cde8a5f9f7529b55249af1fa4248c83b"
}
],
"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-Q63X-GG9G-Q34F
Vulnerability from github – Published: 2026-01-13 18:31 – Updated: 2026-07-14 15:31In the Linux kernel, the following vulnerability has been resolved:
net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write
A deadlock can occur between nfc_unregister_device() and rfkill_fop_write() due to lock ordering inversion between device_lock and rfkill_global_mutex.
The problematic lock order is:
Thread A (rfkill_fop_write): rfkill_fop_write() mutex_lock(&rfkill_global_mutex) rfkill_set_block() nfc_rfkill_set_block() nfc_dev_down() device_lock(&dev->dev) <- waits for device_lock
Thread B (nfc_unregister_device): nfc_unregister_device() device_lock(&dev->dev) rfkill_unregister() mutex_lock(&rfkill_global_mutex) <- waits for rfkill_global_mutex
This creates a classic ABBA deadlock scenario.
Fix this by moving rfkill_unregister() and rfkill_destroy() outside the device_lock critical section. Store the rfkill pointer in a local variable before releasing the lock, then call rfkill_unregister() after releasing device_lock.
This change is safe because rfkill_fop_write() holds rfkill_global_mutex while calling the rfkill callbacks, and rfkill_unregister() also acquires rfkill_global_mutex before cleanup. Therefore, rfkill_unregister() will wait for any ongoing callback to complete before proceeding, and device_del() is only called after rfkill_unregister() returns, preventing any use-after-free.
The similar lock ordering in nfc_register_device() (device_lock -> rfkill_global_mutex via rfkill_register) is safe because during registration the device is not yet in rfkill_list, so no concurrent rfkill operations can occur on this device.
{
"affected": [],
"aliases": [
"CVE-2025-71079"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-13T16:16:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write\n\nA deadlock can occur between nfc_unregister_device() and rfkill_fop_write()\ndue to lock ordering inversion between device_lock and rfkill_global_mutex.\n\nThe problematic lock order is:\n\nThread A (rfkill_fop_write):\n rfkill_fop_write()\n mutex_lock(\u0026rfkill_global_mutex)\n rfkill_set_block()\n nfc_rfkill_set_block()\n nfc_dev_down()\n device_lock(\u0026dev-\u003edev) \u003c- waits for device_lock\n\nThread B (nfc_unregister_device):\n nfc_unregister_device()\n device_lock(\u0026dev-\u003edev)\n rfkill_unregister()\n mutex_lock(\u0026rfkill_global_mutex) \u003c- waits for rfkill_global_mutex\n\nThis creates a classic ABBA deadlock scenario.\n\nFix this by moving rfkill_unregister() and rfkill_destroy() outside the\ndevice_lock critical section. Store the rfkill pointer in a local variable\nbefore releasing the lock, then call rfkill_unregister() after releasing\ndevice_lock.\n\nThis change is safe because rfkill_fop_write() holds rfkill_global_mutex\nwhile calling the rfkill callbacks, and rfkill_unregister() also acquires\nrfkill_global_mutex before cleanup. Therefore, rfkill_unregister() will\nwait for any ongoing callback to complete before proceeding, and\ndevice_del() is only called after rfkill_unregister() returns, preventing\nany use-after-free.\n\nThe similar lock ordering in nfc_register_device() (device_lock -\u003e\nrfkill_global_mutex via rfkill_register) is safe because during\nregistration the device is not yet in rfkill_list, so no concurrent\nrfkill operations can occur on this device.",
"id": "GHSA-q63x-gg9g-q34f",
"modified": "2026-07-14T15:31:31Z",
"published": "2026-01-13T18:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71079"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1ab526d97a57e44d26fadcc0e9adeb9c0c0182f5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2e0831e9fc46a06daa6d4d8d57a2738e343130c3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6b93c8ab6f6cda8818983a4ae3fcf84b023037b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8fc4632fb508432895430cd02b38086bdd649083"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e02a1c33f10a0ed3aba855ab8ae2b6c4c5be8012"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ee41f4f3ccf8cd6ba3732e867abbec7e6d8d12e5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f3a8a7c1aa278f2378b2f3a10500c6674dffdfda"
}
],
"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-Q6X6-WRP8-56VH
Vulnerability from github – Published: 2023-02-28 18:30 – Updated: 2023-03-06 21:30In multiple functions of looper_backed_event_loop.cpp, there is a possible way to corrupt memory due to improper locking. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-12 Android-12L Android-13Android ID: A-243362981
{
"affected": [],
"aliases": [
"CVE-2023-20939"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-28T17:15:00Z",
"severity": "HIGH"
},
"details": "In multiple functions of looper_backed_event_loop.cpp, there is a possible way to corrupt memory due to improper locking. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-12 Android-12L Android-13Android ID: A-243362981",
"id": "GHSA-q6x6-wrp8-56vh",
"modified": "2023-03-06T21:30:19Z",
"published": "2023-02-28T18:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20939"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2023-02-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/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.