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.
692 vulnerabilities reference this CWE, most recent first.
GHSA-X97P-H9J9-9889
Vulnerability from github – Published: 2025-04-14 21:32 – Updated: 2025-04-14 21:32In the Linux kernel, the following vulnerability has been resolved:
drivers: usb: host: Fix deadlock in oxu_bus_suspend()
There is a deadlock in oxu_bus_suspend(), which is shown below:
(Thread 1) | (Thread 2) | timer_action() oxu_bus_suspend() | mod_timer() spin_lock_irq() //(1) | (wait a time) ... | oxu_watchdog() del_timer_sync() | spin_lock_irq() //(2) (wait timer to stop) | ...
We hold oxu->lock in position (1) of thread 1, and use del_timer_sync() to wait timer to stop, but timer handler also need oxu->lock in position (2) of thread 2. As a result, oxu_bus_suspend() will block forever.
This patch extracts del_timer_sync() from the protection of spin_lock_irq(), which could let timer handler to obtain the needed lock.
{
"affected": [],
"aliases": [
"CVE-2022-49313"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: usb: host: Fix deadlock in oxu_bus_suspend()\n\nThere is a deadlock in oxu_bus_suspend(), which is shown below:\n\n (Thread 1) | (Thread 2)\n | timer_action()\noxu_bus_suspend() | mod_timer()\n spin_lock_irq() //(1) | (wait a time)\n ... | oxu_watchdog()\n del_timer_sync() | spin_lock_irq() //(2)\n (wait timer to stop) | ...\n\nWe hold oxu-\u003elock in position (1) of thread 1, and use\ndel_timer_sync() to wait timer to stop, but timer handler\nalso need oxu-\u003elock in position (2) of thread 2. As a result,\noxu_bus_suspend() will block forever.\n\nThis patch extracts del_timer_sync() from the protection of\nspin_lock_irq(), which could let timer handler to obtain\nthe needed lock.",
"id": "GHSA-x97p-h9j9-9889",
"modified": "2025-04-14T21:32:21Z",
"published": "2025-04-14T21:32:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49313"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2dcec0bc142be2096af71a5703d63237127db204"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4187b291a76664a3c03d3f0d9bfadc8322881868"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4d378f2ae58138d4c55684e1d274e7dd94aa6524"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b58d255f27b0ed6a2e43208960864d67579db58"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a3d380188bde8900c3f604e82b56572896499124"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b97aae8b43b718314012e8170b7e03dbfd2e7677"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d888753872190abd18f68a7d77b9c7c367f0a7ab"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f8242044c91cafbba9e320b0fb31abf2429a3221"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ffe9440d698274c6462d2e304562c6ddfc8c84df"
}
],
"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-X9P6-4MGW-JM88
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-24 18:32In the Linux kernel, the following vulnerability has been resolved:
ksmbd: call ksmbd_vfs_kern_path_end_removing() on some error paths
There are two places where ksmbd_vfs_kern_path_end_removing() needs to be called in order to balance what the corresponding successful call to ksmbd_vfs_kern_path_start_removing() has done, i.e. drop inode locks and put the taken references. Otherwise there might be potential deadlocks and unbalanced locks which are caught like:
BUG: workqueue leaked lock or atomic: kworker/5:21/0x00000000/7596 last function: handle_ksmbd_work 2 locks held by kworker/5:21/7596: #0: ffff8881051ae448 (sb_writers#3){.+.+}-{0:0}, at: ksmbd_vfs_kern_path_locked+0x142/0x660 #1: ffff888130e966c0 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: ksmbd_vfs_kern_path_locked+0x17d/0x660 CPU: 5 PID: 7596 Comm: kworker/5:21 Not tainted 6.1.162-00456-gc29b353f383b #138 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 Workqueue: ksmbd-io handle_ksmbd_work Call Trace: dump_stack_lvl+0x44/0x5b process_one_work.cold+0x57/0x5c worker_thread+0x82/0x600 kthread+0x153/0x190 ret_from_fork+0x22/0x30
Found by Linux Verification Center (linuxtesting.org).
{
"affected": [],
"aliases": [
"CVE-2026-45924"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: call ksmbd_vfs_kern_path_end_removing() on some error paths\n\nThere are two places where ksmbd_vfs_kern_path_end_removing() needs to be\ncalled in order to balance what the corresponding successful call to\nksmbd_vfs_kern_path_start_removing() has done, i.e. drop inode locks and\nput the taken references. Otherwise there might be potential deadlocks\nand unbalanced locks which are caught like:\n\nBUG: workqueue leaked lock or atomic: kworker/5:21/0x00000000/7596\n last function: handle_ksmbd_work\n2 locks held by kworker/5:21/7596:\n #0: ffff8881051ae448 (sb_writers#3){.+.+}-{0:0}, at: ksmbd_vfs_kern_path_locked+0x142/0x660\n #1: ffff888130e966c0 (\u0026type-\u003ei_mutex_dir_key#3/1){+.+.}-{4:4}, at: ksmbd_vfs_kern_path_locked+0x17d/0x660\nCPU: 5 PID: 7596 Comm: kworker/5:21 Not tainted 6.1.162-00456-gc29b353f383b #138\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014\nWorkqueue: ksmbd-io handle_ksmbd_work\nCall Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x44/0x5b\n process_one_work.cold+0x57/0x5c\n worker_thread+0x82/0x600\n kthread+0x153/0x190\n ret_from_fork+0x22/0x30\n \u003c/TASK\u003e\n\nFound by Linux Verification Center (linuxtesting.org).",
"id": "GHSA-x9p6-4mgw-jm88",
"modified": "2026-06-24T18:32:28Z",
"published": "2026-05-27T15:33:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45924"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0c578e8065c4b08d5635a4cbc0f6321df9d20f79"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/34d6691933682f0516259a31b39d2cebcedec0a5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4c38600feb81c670edb82e49d201d3d2d00cd4c3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8e3a3192ef78d8302916408d62813b1fddfc8972"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a09dc10d1353f0e92c21eae2a79af1c2b1ddcde8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cf29329a13df79c198b45dfc92577638d30b56fa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f221baa80e5959a0c08a7e34abbf2a4d3cf0e1c2"
}
],
"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-X9Q8-72P3-MMVX
Vulnerability from github – Published: 2024-03-03 00:30 – Updated: 2025-01-13 21:30In the Linux kernel, the following vulnerability has been resolved:
net: nfc: llcp: Add lock when modifying device list
The device list needs its associated lock held when modifying it, or the list could become corrupted, as syzbot discovered.
{
"affected": [],
"aliases": [
"CVE-2023-52524"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-02T22:15:48Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: nfc: llcp: Add lock when modifying device list\n\nThe device list needs its associated lock held when modifying it, or the\nlist could become corrupted, as syzbot discovered.",
"id": "GHSA-x9q8-72p3-mmvx",
"modified": "2025-01-13T21:30:47Z",
"published": "2024-03-03T00:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52524"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/191d87a19cf1005ecf41e1ae08d74e17379e8391"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/29c16c2bf5866326d5fbc4a537b3997fcac23391"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4837a192f6d06d5bb2f3f47d6ce5353ab69bf86b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7562780e32b84196731d57dd24563546fcf6d082"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dba849cc98113b145c6e720122942c00b8012bdb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dfc7f7a988dad34c3bf4c053124fb26aa6c5f916"
}
],
"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"
}
]
}
GHSA-X9QW-9CW3-55VF
Vulnerability from github – Published: 2025-04-01 18:30 – Updated: 2025-04-15 18:31In the Linux kernel, the following vulnerability has been resolved:
drm/imagination: avoid deadlock on fence release
Do scheduler queue fence release processing on a workqueue, rather than in the release function itself.
Fixes deadlock issues such as the following:
[ 607.400437] ============================================ [ 607.405755] WARNING: possible recursive locking detected [ 607.415500] -------------------------------------------- [ 607.420817] weston:zfq0/24149 is trying to acquire lock: [ 607.426131] ffff000017d041a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: pvr_gem_object_vunmap+0x40/0xc0 [powervr] [ 607.436728] but task is already holding lock: [ 607.442554] ffff000017d105a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: dma_buf_ioctl+0x250/0x554 [ 607.451727] other info that might help us debug this: [ 607.458245] Possible unsafe locking scenario:
[ 607.464155] CPU0 [ 607.466601] ---- [ 607.469044] lock(reservation_ww_class_mutex); [ 607.473584] lock(reservation_ww_class_mutex); [ 607.478114] *** DEADLOCK ***
{
"affected": [],
"aliases": [
"CVE-2025-21911"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-01T16:15:21Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/imagination: avoid deadlock on fence release\n\nDo scheduler queue fence release processing on a workqueue, rather\nthan in the release function itself.\n\nFixes deadlock issues such as the following:\n\n[ 607.400437] ============================================\n[ 607.405755] WARNING: possible recursive locking detected\n[ 607.415500] --------------------------------------------\n[ 607.420817] weston:zfq0/24149 is trying to acquire lock:\n[ 607.426131] ffff000017d041a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: pvr_gem_object_vunmap+0x40/0xc0 [powervr]\n[ 607.436728]\n but task is already holding lock:\n[ 607.442554] ffff000017d105a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: dma_buf_ioctl+0x250/0x554\n[ 607.451727]\n other info that might help us debug this:\n[ 607.458245] Possible unsafe locking scenario:\n\n[ 607.464155] CPU0\n[ 607.466601] ----\n[ 607.469044] lock(reservation_ww_class_mutex);\n[ 607.473584] lock(reservation_ww_class_mutex);\n[ 607.478114]\n *** DEADLOCK ***",
"id": "GHSA-x9qw-9cw3-55vf",
"modified": "2025-04-15T18:31:42Z",
"published": "2025-04-01T18:30:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21911"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9bd8b8d34cf4efba18766d64f817c819ed1bbde7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d993ae7360923efd6ade43a32043459a121c28c1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/df1a1ed5e1bdd9cc13148e0e5549f5ebcf76cf13"
}
],
"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-XCJG-G59X-3948
Vulnerability from github – Published: 2024-12-27 15:31 – Updated: 2025-11-03 21:31In the Linux kernel, the following vulnerability has been resolved:
ALSA: usx2y: Use snd_card_free_when_closed() at disconnection
The USB disconnect callback is supposed to be short and not too-long waiting. OTOH, the current code uses snd_card_free() at disconnection, but this waits for the close of all used fds, hence it can take long. It eventually blocks the upper layer USB ioctls, which may trigger a soft lockup.
An easy workaround is to replace snd_card_free() with snd_card_free_when_closed(). This variant returns immediately while the release of resources is done asynchronously by the card device release at the last close.
{
"affected": [],
"aliases": [
"CVE-2024-56533"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-27T14:15:32Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usx2y: Use snd_card_free_when_closed() at disconnection\n\nThe USB disconnect callback is supposed to be short and not too-long\nwaiting. OTOH, the current code uses snd_card_free() at\ndisconnection, but this waits for the close of all used fds, hence it\ncan take long. It eventually blocks the upper layer USB ioctls, which\nmay trigger a soft lockup.\n\nAn easy workaround is to replace snd_card_free() with\nsnd_card_free_when_closed(). This variant returns immediately while\nthe release of resources is done asynchronously by the card device\nrelease at the last close.",
"id": "GHSA-xcjg-g59x-3948",
"modified": "2025-11-03T21:31:50Z",
"published": "2024-12-27T15:31:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56533"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/24fe9f7ca83ec9acf765339054951f5cd9ae5c5d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7bd8838c0ea886679a32834fdcacab296d072fbe"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/befcca1777525e37c659b4129d8ac7463b07ef67"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dafb28f02be407e07a6f679e922a626592b481b0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e07605d855c4104d981653146a330ea48f6266ed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e869642a77a9b3b98b0ab2c8fec7af4385140909"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ffbfc6c4330fc233698529656798bee44fea96f5"
},
{
"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-XFP4-237C-CHRM
Vulnerability from github – Published: 2025-01-11 15:30 – Updated: 2025-01-16 15:32In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix TCP timers deadlock after rmmod
Commit ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") fixed a netns UAF by manually enabled socket refcounting (sk->sk_net_refcnt=1 and sock_inuse_add(net, 1)).
The reason the patch worked for that bug was because we now hold references to the netns (get_net_track() gets a ref internally) and they're properly released (internally, on __sk_destruct()), but only because sk->sk_net_refcnt was set.
Problem: (this happens regardless of CONFIG_NET_NS_REFCNT_TRACKER and regardless if init_net or other)
Setting sk->sk_net_refcnt=1 manually and after socket creation is not only out of cifs scope, but also technically wrong -- it's set conditionally based on user (=1) vs kernel (=0) sockets. And net/ implementations seem to base their user vs kernel space operations on it.
e.g. upon TCP socket close, the TCP timers are not cleared because sk->sk_net_refcnt=1: (cf. commit 151c9c724d05 ("tcp: properly terminate timers for kernel sockets"))
net/ipv4/tcp.c: void tcp_close(struct sock *sk, long timeout) { lock_sock(sk); __tcp_close(sk, timeout); release_sock(sk); if (!sk->sk_net_refcnt) inet_csk_clear_xmit_timers_sync(sk); sock_put(sk); }
Which will throw a lockdep warning and then, as expected, deadlock on tcp_write_timer().
A way to reproduce this is by running the reproducer from ef7134c7fc48 and then 'rmmod cifs'. A few seconds later, the deadlock/lockdep warning shows up.
Fix: We shouldn't mess with socket internals ourselves, so do not set sk_net_refcnt manually.
Also change __sock_create() to sock_create_kern() for explicitness.
As for non-init_net network namespaces, we deal with it the best way we can -- hold an extra netns reference for server->ssocket and drop it when it's released. This ensures that the netns still exists whenever we need to create/destroy server->ssocket, but is not directly tied to it.
{
"affected": [],
"aliases": [
"CVE-2024-54680"
],
"database_specific": {
"cwe_ids": [
"CWE-416",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-11T13:15:27Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix TCP timers deadlock after rmmod\n\nCommit ef7134c7fc48 (\"smb: client: Fix use-after-free of network namespace.\")\nfixed a netns UAF by manually enabled socket refcounting\n(sk-\u003esk_net_refcnt=1 and sock_inuse_add(net, 1)).\n\nThe reason the patch worked for that bug was because we now hold\nreferences to the netns (get_net_track() gets a ref internally)\nand they\u0027re properly released (internally, on __sk_destruct()),\nbut only because sk-\u003esk_net_refcnt was set.\n\nProblem:\n(this happens regardless of CONFIG_NET_NS_REFCNT_TRACKER and regardless\nif init_net or other)\n\nSetting sk-\u003esk_net_refcnt=1 *manually* and *after* socket creation is not\nonly out of cifs scope, but also technically wrong -- it\u0027s set conditionally\nbased on user (=1) vs kernel (=0) sockets. And net/ implementations\nseem to base their user vs kernel space operations on it.\n\ne.g. upon TCP socket close, the TCP timers are not cleared because\nsk-\u003esk_net_refcnt=1:\n(cf. commit 151c9c724d05 (\"tcp: properly terminate timers for kernel sockets\"))\n\nnet/ipv4/tcp.c:\n void tcp_close(struct sock *sk, long timeout)\n {\n \tlock_sock(sk);\n \t__tcp_close(sk, timeout);\n \trelease_sock(sk);\n \tif (!sk-\u003esk_net_refcnt)\n \t\tinet_csk_clear_xmit_timers_sync(sk);\n \tsock_put(sk);\n }\n\nWhich will throw a lockdep warning and then, as expected, deadlock on\ntcp_write_timer().\n\nA way to reproduce this is by running the reproducer from ef7134c7fc48\nand then \u0027rmmod cifs\u0027. A few seconds later, the deadlock/lockdep\nwarning shows up.\n\nFix:\nWe shouldn\u0027t mess with socket internals ourselves, so do not set\nsk_net_refcnt manually.\n\nAlso change __sock_create() to sock_create_kern() for explicitness.\n\nAs for non-init_net network namespaces, we deal with it the best way\nwe can -- hold an extra netns reference for server-\u003essocket and drop it\nwhen it\u0027s released. This ensures that the netns still exists whenever\nwe need to create/destroy server-\u003essocket, but is not directly tied to\nit.",
"id": "GHSA-xfp4-237c-chrm",
"modified": "2025-01-16T15:32:09Z",
"published": "2025-01-11T15:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54680"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/127e907e11ccd54b59bb78fc22c43ccb76c71079"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/906807c734ed219dcb2e7bbfde5c4168ed72a3d0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e9f2517a3e18a54a3943c098d2226b245d488801"
}
],
"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-XFPM-Q238-HR33
Vulnerability from github – Published: 2022-08-26 00:03 – Updated: 2022-08-31 00:00A race condition was found in the Linux kernel's watch queue due to a missing lock in pipe_resize_ring(). The specific flaw exists within the handling of pipe buffers. The issue results from the lack of proper locking when performing operations on an object. This flaw allows a local user to crash the system or escalate their privileges on the system.
{
"affected": [],
"aliases": [
"CVE-2022-2959"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-08-25T18:15:00Z",
"severity": "HIGH"
},
"details": "A race condition was found in the Linux kernel\u0027s watch queue due to a missing lock in pipe_resize_ring(). The specific flaw exists within the handling of pipe buffers. The issue results from the lack of proper locking when performing operations on an object. This flaw allows a local user to crash the system or escalate their privileges on the system.",
"id": "GHSA-xfpm-q238-hr33",
"modified": "2022-08-31T00:00:20Z",
"published": "2022-08-26T00:03:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2959"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/189b0ddc245139af81198d1a3637cac74f96e13a"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20230214-0005"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-22-1165"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XFPP-3CJF-2X3V
Vulnerability from github – Published: 2024-06-19 15:30 – Updated: 2024-10-31 15:30In the Linux kernel, the following vulnerability has been resolved:
audit: improve robustness of the audit queue handling
If the audit daemon were ever to get stuck in a stopped state the kernel's kauditd_thread() could get blocked attempting to send audit records to the userspace audit daemon. With the kernel thread blocked it is possible that the audit queue could grow unbounded as certain audit record generating events must be exempt from the queue limits else the system enter a deadlock state.
This patch resolves this problem by lowering the kernel thread's socket sending timeout from MAX_SCHEDULE_TIMEOUT to HZ/10 and tweaks the kauditd_send_queue() function to better manage the various audit queues when connection problems occur between the kernel and the audit daemon. With this patch, the backlog may temporarily grow beyond the defined limits when the audit daemon is stopped and the system is under heavy audit pressure, but kauditd_thread() will continue to make progress and drain the queues as it would for other connection problems. For example, with the audit daemon put into a stopped state and the system configured to audit every syscall it was still possible to shutdown the system without a kernel panic, deadlock, etc.; granted, the system was slow to shutdown but that is to be expected given the extreme pressure of recording every syscall.
The timeout value of HZ/10 was chosen primarily through experimentation and this developer's "gut feeling". There is likely no one perfect value, but as this scenario is limited in scope (root privileges would be needed to send SIGSTOP to the audit daemon), it is likely not worth exposing this as a tunable at present. This can always be done at a later date if it proves necessary.
{
"affected": [],
"aliases": [
"CVE-2021-47603"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-19T15:15:54Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\naudit: improve robustness of the audit queue handling\n\nIf the audit daemon were ever to get stuck in a stopped state the\nkernel\u0027s kauditd_thread() could get blocked attempting to send audit\nrecords to the userspace audit daemon. With the kernel thread\nblocked it is possible that the audit queue could grow unbounded as\ncertain audit record generating events must be exempt from the queue\nlimits else the system enter a deadlock state.\n\nThis patch resolves this problem by lowering the kernel thread\u0027s\nsocket sending timeout from MAX_SCHEDULE_TIMEOUT to HZ/10 and tweaks\nthe kauditd_send_queue() function to better manage the various audit\nqueues when connection problems occur between the kernel and the\naudit daemon. With this patch, the backlog may temporarily grow\nbeyond the defined limits when the audit daemon is stopped and the\nsystem is under heavy audit pressure, but kauditd_thread() will\ncontinue to make progress and drain the queues as it would for other\nconnection problems. For example, with the audit daemon put into a\nstopped state and the system configured to audit every syscall it\nwas still possible to shutdown the system without a kernel panic,\ndeadlock, etc.; granted, the system was slow to shutdown but that is\nto be expected given the extreme pressure of recording every syscall.\n\nThe timeout value of HZ/10 was chosen primarily through\nexperimentation and this developer\u0027s \"gut feeling\". There is likely\nno one perfect value, but as this scenario is limited in scope (root\nprivileges would be needed to send SIGSTOP to the audit daemon), it\nis likely not worth exposing this as a tunable at present. This can\nalways be done at a later date if it proves necessary.",
"id": "GHSA-xfpp-3cjf-2x3v",
"modified": "2024-10-31T15:30:58Z",
"published": "2024-06-19T15:30:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47603"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0d3277eabd542fb662be23696e5ec9f390d688e1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4cc6badff97f74d0fce65f9784b5df3b64e4250b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/75fdb751f84727d614deea0571a1490c3225d83a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8389f50ceb854cb437fefb9330d5024ed3c7c1f5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a5f4d17daf2e6cd7c1d9676b476147f6b4ac53f2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f4b3ee3c85551d2d343a3ba159304066523f730f"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XJM8-9W9G-9H2F
Vulnerability from github – Published: 2023-07-13 00:30 – Updated: 2025-02-13 18:31In multiple functions of io_uring.c, there is a possible kernel memory corruption due to improper locking. This could lead to local escalation of privilege in the kernel with System execution privileges needed. User interaction is not needed for exploitation.
{
"affected": [],
"aliases": [
"CVE-2023-21400"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-13T00:15:24Z",
"severity": "MODERATE"
},
"details": "In multiple functions of io_uring.c, there is a possible kernel memory corruption due to improper locking. This could lead to local escalation of privilege in the kernel with System execution privileges needed. User interaction is not needed for exploitation.",
"id": "GHSA-xjm8-9w9g-9h2f",
"modified": "2025-02-13T18:31:40Z",
"published": "2023-07-13T00:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21400"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240119-0012"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2023-07-01"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2023/dsa-5480"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2023/07/14/2"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2023/07/19/2"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2023/07/19/7"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2023/07/25/7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XJRJ-HM29-QRJC
Vulnerability from github – Published: 2025-04-16 15:34 – Updated: 2025-10-31 21:30In the Linux kernel, the following vulnerability has been resolved:
smb: client: Fix netns refcount imbalance causing leaks and use-after-free
Commit ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") attempted to fix a netns use-after-free issue by manually adjusting reference counts via sk->sk_net_refcnt and sock_inuse_add().
However, a later commit e9f2517a3e18 ("smb: client: fix TCP timers deadlock after rmmod") pointed out that the approach of manually setting sk->sk_net_refcnt in the first commit was technically incorrect, as sk->sk_net_refcnt should only be set for user sockets. It led to issues like TCP timers not being cleared properly on close. The second commit moved to a model of just holding an extra netns reference for server->ssocket using get_net(), and dropping it when the server is torn down.
But there remain some gaps in the get_net()/put_net() balancing added by these commits. The incomplete reference handling in these fixes results in two issues:
- Netns refcount leaks[1]
The problem process is as follows:
mount.cifs cifsd
cifs_do_mount
cifs_mount
cifs_mount_get_session
cifs_get_tcp_session
get_net() /* First get net. */
ip_connect
generic_ip_connect /* Try port 445 */
get_net()
->connect() /* Failed */
put_net()
generic_ip_connect /* Try port 139 */
get_net() /* Missing matching put_net() for this get_net().*/
cifs_get_smb_ses
cifs_negotiate_protocol
smb2_negotiate
SMB2_negotiate
cifs_send_recv
wait_for_response
cifs_demultiplex_thread
cifs_read_from_socket
cifs_readv_from_socket
cifs_reconnect
cifs_abort_connection
sock_release();
server->ssocket = NULL;
/* Missing put_net() here. */
generic_ip_connect
get_net()
->connect() /* Failed */
put_net()
sock_release();
server->ssocket = NULL;
free_rsp_buf
...
clean_demultiplex_info
/* It's only called once here. */
put_net()
When cifs_reconnect() is triggered, the server->ssocket is released without a corresponding put_net() for the reference acquired in generic_ip_connect() before. it ends up calling generic_ip_connect() again to retry get_net(). After that, server->ssocket is set to NULL in the error path of generic_ip_connect(), and the net count cannot be released in the final clean_demultiplex_info() function.
- Potential use-after-free
The current refcounting scheme can lead to a potential use-after-free issue in the following scenario:
cifs_do_mount
cifs_mount
cifs_mount_get_session
cifs_get_tcp_session
get_net() /* First get net */
ip_connect
generic_ip_connect
get_net()
bind_socket
kernel_bind /* failed */
put_net()
/* after out_err_crypto_release label */
put_net()
/* after out_err label */
put_net()
In the exception handling process where binding the socket fails, the get_net() and put_net() calls are unbalanced, which may cause the server->net reference count to drop to zero and be prematurely released.
To address both issues, this patch ties the netns reference counti ---truncated---
{
"affected": [],
"aliases": [
"CVE-2025-22077"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-16T15:16:01Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: Fix netns refcount imbalance causing leaks and use-after-free\n\nCommit ef7134c7fc48 (\"smb: client: Fix use-after-free of network\nnamespace.\") attempted to fix a netns use-after-free issue by manually\nadjusting reference counts via sk-\u003esk_net_refcnt and sock_inuse_add().\n\nHowever, a later commit e9f2517a3e18 (\"smb: client: fix TCP timers deadlock\nafter rmmod\") pointed out that the approach of manually setting\nsk-\u003esk_net_refcnt in the first commit was technically incorrect, as\nsk-\u003esk_net_refcnt should only be set for user sockets. It led to issues\nlike TCP timers not being cleared properly on close. The second commit\nmoved to a model of just holding an extra netns reference for\nserver-\u003essocket using get_net(), and dropping it when the server is torn\ndown.\n\nBut there remain some gaps in the get_net()/put_net() balancing added by\nthese commits. The incomplete reference handling in these fixes results\nin two issues:\n\n1. Netns refcount leaks[1]\n\nThe problem process is as follows:\n\n```\nmount.cifs cifsd\n\ncifs_do_mount\n cifs_mount\n cifs_mount_get_session\n cifs_get_tcp_session\n get_net() /* First get net. */\n ip_connect\n generic_ip_connect /* Try port 445 */\n get_net()\n -\u003econnect() /* Failed */\n put_net()\n generic_ip_connect /* Try port 139 */\n get_net() /* Missing matching put_net() for this get_net().*/\n cifs_get_smb_ses\n cifs_negotiate_protocol\n smb2_negotiate\n SMB2_negotiate\n cifs_send_recv\n wait_for_response\n cifs_demultiplex_thread\n cifs_read_from_socket\n cifs_readv_from_socket\n cifs_reconnect\n cifs_abort_connection\n sock_release();\n server-\u003essocket = NULL;\n /* Missing put_net() here. */\n generic_ip_connect\n get_net()\n -\u003econnect() /* Failed */\n put_net()\n sock_release();\n server-\u003essocket = NULL;\n free_rsp_buf\n ...\n clean_demultiplex_info\n /* It\u0027s only called once here. */\n put_net()\n```\n\nWhen cifs_reconnect() is triggered, the server-\u003essocket is released\nwithout a corresponding put_net() for the reference acquired in\ngeneric_ip_connect() before. it ends up calling generic_ip_connect()\nagain to retry get_net(). After that, server-\u003essocket is set to NULL\nin the error path of generic_ip_connect(), and the net count cannot be\nreleased in the final clean_demultiplex_info() function.\n\n2. Potential use-after-free\n\nThe current refcounting scheme can lead to a potential use-after-free issue\nin the following scenario:\n\n```\n cifs_do_mount\n cifs_mount\n cifs_mount_get_session\n cifs_get_tcp_session\n get_net() /* First get net */\n ip_connect\n generic_ip_connect\n get_net()\n bind_socket\n\t kernel_bind /* failed */\n put_net()\n /* after out_err_crypto_release label */\n put_net()\n /* after out_err label */\n put_net()\n```\n\nIn the exception handling process where binding the socket fails, the\nget_net() and put_net() calls are unbalanced, which may cause the\nserver-\u003enet reference count to drop to zero and be prematurely released.\n\nTo address both issues, this patch ties the netns reference counti\n---truncated---",
"id": "GHSA-xjrj-hm29-qrjc",
"modified": "2025-10-31T21:30:55Z",
"published": "2025-04-16T15:34:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22077"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/476617a4ca0123f0df677d547a82a110c27c8c74"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4b6f6bf1bde8d6045c389fda8d21c304dfe49384"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4e7f1644f2ac6d01dc584f6301c3b1d5aac4eaef"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7d8dfc27d90d41627c0d6ada97ed0ab57b3dae25"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8dbf060480236877703bff0106fc984576184d11"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/95d2b9f693ff2a1180a23d7d59acc0c4e72f4c41"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/961755d0055e0e96d1849cc0425da966c8a64e53"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c6b6b8dcef4adf8ee4e439bb97e74106096c71b8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f761eeefd531e6550cd3a5c047835b4892acb00d"
}
],
"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.