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.
729 vulnerabilities reference this CWE, most recent first.
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"
}
]
}
GHSA-XMV4-4P35-4553
Vulnerability from github – Published: 2022-04-30 18:22 – Updated: 2024-02-08 21:30dump 0.4 b10 through b29 allows local users to cause a denial of service (execution prevention) by using flock() to lock the /etc/dumpdates file.
{
"affected": [],
"aliases": [
"CVE-2002-1914"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2002-12-31T05:00:00Z",
"severity": "LOW"
},
"details": "dump 0.4 b10 through b29 allows local users to cause a denial of service (execution prevention) by using flock() to lock the /etc/dumpdates file.",
"id": "GHSA-xmv4-4p35-4553",
"modified": "2024-02-08T21:30:29Z",
"published": "2022-04-30T18:22:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2002-1914"
},
{
"type": "WEB",
"url": "http://online.securityfocus.com/archive/1/283033"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/21520"
},
{
"type": "WEB",
"url": "http://support.avaya.com/elmodocs2/security/ASA-2006-156.htm"
},
{
"type": "WEB",
"url": "http://www.iss.net/security_center/static/9632.php"
},
{
"type": "WEB",
"url": "http://www.redhat.com/support/errata/RHSA-2005-583.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/5264"
}
],
"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-XMXX-577P-GQGC
Vulnerability from github – Published: 2024-05-17 15:31 – Updated: 2025-09-25 18:30In the Linux kernel, the following vulnerability has been resolved:
ALSA: scarlett2: Add missing mutex lock around get meter levels
As scarlett2_meter_ctl_get() uses meter_level_map[], the data_mutex should be locked while accessing it.
{
"affected": [],
"aliases": [
"CVE-2023-52689"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-17T15:15:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: scarlett2: Add missing mutex lock around get meter levels\n\nAs scarlett2_meter_ctl_get() uses meter_level_map[], the data_mutex\nshould be locked while accessing it.",
"id": "GHSA-xmxx-577p-gqgc",
"modified": "2025-09-25T18:30:28Z",
"published": "2024-05-17T15:31:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52689"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/74e3de7cdcc31ce75ab42350ae0946eff62a2da2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/993f7b42fa066b055e3a19b7f76ad8157c0927a0"
}
],
"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-XPH2-RHPH-VXVM
Vulnerability from github – Published: 2024-12-27 15:31 – Updated: 2025-09-23 21:30In the Linux kernel, the following vulnerability has been resolved:
mm/vmalloc: combine all TLB flush operations of KASAN shadow virtual address into one operation
When compiling kernel source 'make -j $(nproc)' with the up-and-running KASAN-enabled kernel on a 256-core machine, the following soft lockup is shown:
watchdog: BUG: soft lockup - CPU#28 stuck for 22s! [kworker/28:1:1760] CPU: 28 PID: 1760 Comm: kworker/28:1 Kdump: loaded Not tainted 6.10.0-rc5 #95 Workqueue: events drain_vmap_area_work RIP: 0010:smp_call_function_many_cond+0x1d8/0xbb0 Code: 38 c8 7c 08 84 c9 0f 85 49 08 00 00 8b 45 08 a8 01 74 2e 48 89 f1 49 89 f7 48 c1 e9 03 41 83 e7 07 4c 01 e9 41 83 c7 03 f3 90 <0f> b6 01 41 38 c7 7c 08 84 c0 0f 85 d4 06 00 00 8b 45 08 a8 01 75 RSP: 0018:ffffc9000cb3fb60 EFLAGS: 00000202 RAX: 0000000000000011 RBX: ffff8883bc4469c0 RCX: ffffed10776e9949 RDX: 0000000000000002 RSI: ffff8883bb74ca48 RDI: ffffffff8434dc50 RBP: ffff8883bb74ca40 R08: ffff888103585dc0 R09: ffff8884533a1800 R10: 0000000000000004 R11: ffffffffffffffff R12: ffffed1077888d39 R13: dffffc0000000000 R14: ffffed1077888d38 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff8883bc400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005577b5c8d158 CR3: 0000000004850000 CR4: 0000000000350ef0 Call Trace: ? watchdog_timer_fn+0x2cd/0x390 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x300/0x6d0 ? sched_clock_cpu+0x69/0x4e0 ? __pfxhrtimerrun_queues+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? ktime_get_update_offsets_now+0x7f/0x2a0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? hrtimer_interrupt+0x2ca/0x760 ? sysvec_apic_timer_interrupt+0x8c/0x2b0 ? sysvec_apic_timer_interrupt+0x6a/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? smp_call_function_many_cond+0x1d8/0xbb0 ? __pfx_do_kernel_range_flush+0x10/0x10 on_each_cpu_cond_mask+0x20/0x40 flush_tlb_kernel_range+0x19b/0x250 ? srso_return_thunk+0x5/0x5f ? kasan_release_vmalloc+0xa7/0xc0 purge_vmap_node+0x357/0x820 ? __pfx_purge_vmap_node+0x10/0x10 __purge_vmap_area_lazy+0x5b8/0xa10 drain_vmap_area_work+0x21/0x30 process_one_work+0x661/0x10b0 worker_thread+0x844/0x10e0 ? srso_return_thunk+0x5/0x5f ? __kthread_parkme+0x82/0x140 ? __pfx_worker_thread+0x10/0x10 kthread+0x2a5/0x370 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30
Debugging Analysis:
-
The following ftrace log shows that the lockup CPU spends too much time iterating vmap_nodes and flushing TLB when purging vm_area structures. (Some info is trimmed).
kworker: funcgraph_entry: | drain_vmap_area_work() { kworker: funcgraph_entry: | mutex_lock() { kworker: funcgraph_entry: 1.092 us | __cond_resched(); kworker: funcgraph_exit: 3.306 us | } ... ... kworker: funcgraph_entry: | flush_tlb_kernel_range() { ... ... kworker: funcgraph_exit: # 7533.649 us | } ... ... kworker: funcgraph_entry: 2.344 us | mutex_unlock(); kworker: funcgraph_exit: $ 23871554 us | }
The drain_vmap_area_work() spends over 23 seconds.
There are 2805 flush_tlb_kernel_range() calls in the ftrace log. * One is called in __purge_vmap_area_lazy(). * Others are called by purge_vmap_node->kasan_release_vmalloc. purge_vmap_node() iteratively releases kasan vmalloc allocations and flushes TLB for each vmap_area. - [Rough calculation] Each flush_tlb_kernel_range() runs about 7.5ms. -- 2804 * 7.5ms = 21.03 seconds. -- That's why a soft lock is triggered.
-
Extending the soft lockup time can work around the issue (For example, # echo ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-56559"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-27T15:15:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmalloc: combine all TLB flush operations of KASAN shadow virtual address into one operation\n\nWhen compiling kernel source \u0027make -j $(nproc)\u0027 with the up-and-running\nKASAN-enabled kernel on a 256-core machine, the following soft lockup is\nshown:\n\nwatchdog: BUG: soft lockup - CPU#28 stuck for 22s! [kworker/28:1:1760]\nCPU: 28 PID: 1760 Comm: kworker/28:1 Kdump: loaded Not tainted 6.10.0-rc5 #95\nWorkqueue: events drain_vmap_area_work\nRIP: 0010:smp_call_function_many_cond+0x1d8/0xbb0\nCode: 38 c8 7c 08 84 c9 0f 85 49 08 00 00 8b 45 08 a8 01 74 2e 48 89 f1 49 89 f7 48 c1 e9 03 41 83 e7 07 4c 01 e9 41 83 c7 03 f3 90 \u003c0f\u003e b6 01 41 38 c7 7c 08 84 c0 0f 85 d4 06 00 00 8b 45 08 a8 01 75\nRSP: 0018:ffffc9000cb3fb60 EFLAGS: 00000202\nRAX: 0000000000000011 RBX: ffff8883bc4469c0 RCX: ffffed10776e9949\nRDX: 0000000000000002 RSI: ffff8883bb74ca48 RDI: ffffffff8434dc50\nRBP: ffff8883bb74ca40 R08: ffff888103585dc0 R09: ffff8884533a1800\nR10: 0000000000000004 R11: ffffffffffffffff R12: ffffed1077888d39\nR13: dffffc0000000000 R14: ffffed1077888d38 R15: 0000000000000003\nFS: 0000000000000000(0000) GS:ffff8883bc400000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00005577b5c8d158 CR3: 0000000004850000 CR4: 0000000000350ef0\nCall Trace:\n \u003cIRQ\u003e\n ? watchdog_timer_fn+0x2cd/0x390\n ? __pfx_watchdog_timer_fn+0x10/0x10\n ? __hrtimer_run_queues+0x300/0x6d0\n ? sched_clock_cpu+0x69/0x4e0\n ? __pfx___hrtimer_run_queues+0x10/0x10\n ? srso_return_thunk+0x5/0x5f\n ? ktime_get_update_offsets_now+0x7f/0x2a0\n ? srso_return_thunk+0x5/0x5f\n ? srso_return_thunk+0x5/0x5f\n ? hrtimer_interrupt+0x2ca/0x760\n ? __sysvec_apic_timer_interrupt+0x8c/0x2b0\n ? sysvec_apic_timer_interrupt+0x6a/0x90\n \u003c/IRQ\u003e\n \u003cTASK\u003e\n ? asm_sysvec_apic_timer_interrupt+0x16/0x20\n ? smp_call_function_many_cond+0x1d8/0xbb0\n ? __pfx_do_kernel_range_flush+0x10/0x10\n on_each_cpu_cond_mask+0x20/0x40\n flush_tlb_kernel_range+0x19b/0x250\n ? srso_return_thunk+0x5/0x5f\n ? kasan_release_vmalloc+0xa7/0xc0\n purge_vmap_node+0x357/0x820\n ? __pfx_purge_vmap_node+0x10/0x10\n __purge_vmap_area_lazy+0x5b8/0xa10\n drain_vmap_area_work+0x21/0x30\n process_one_work+0x661/0x10b0\n worker_thread+0x844/0x10e0\n ? srso_return_thunk+0x5/0x5f\n ? __kthread_parkme+0x82/0x140\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x2a5/0x370\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x30/0x70\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u003c/TASK\u003e\n\nDebugging Analysis:\n\n 1. The following ftrace log shows that the lockup CPU spends too much\n time iterating vmap_nodes and flushing TLB when purging vm_area\n structures. (Some info is trimmed).\n\n kworker: funcgraph_entry: | drain_vmap_area_work() {\n kworker: funcgraph_entry: | mutex_lock() {\n kworker: funcgraph_entry: 1.092 us | __cond_resched();\n kworker: funcgraph_exit: 3.306 us | }\n ... ...\n kworker: funcgraph_entry: | flush_tlb_kernel_range() {\n ... ...\n kworker: funcgraph_exit: # 7533.649 us | }\n ... ...\n kworker: funcgraph_entry: 2.344 us | mutex_unlock();\n kworker: funcgraph_exit: $ 23871554 us | }\n\n The drain_vmap_area_work() spends over 23 seconds.\n\n There are 2805 flush_tlb_kernel_range() calls in the ftrace log.\n * One is called in __purge_vmap_area_lazy().\n * Others are called by purge_vmap_node-\u003ekasan_release_vmalloc.\n purge_vmap_node() iteratively releases kasan vmalloc\n allocations and flushes TLB for each vmap_area.\n - [Rough calculation] Each flush_tlb_kernel_range() runs\n about 7.5ms.\n -- 2804 * 7.5ms = 21.03 seconds.\n -- That\u0027s why a soft lock is triggered.\n\n 2. Extending the soft lockup time can work around the issue (For example,\n # echo\n---truncated---",
"id": "GHSA-xph2-rhph-vxvm",
"modified": "2025-09-23T21:30:53Z",
"published": "2024-12-27T15:31:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56559"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9e9e085effe9b7e342138fde3cf8577d22509932"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f9a18889aad9b4c19c6c4550c67ad4f9ed2a354f"
}
],
"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.