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.
713 vulnerabilities reference this CWE, most recent first.
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"
}
]
}
GHSA-Q86W-66M5-QPJ3
Vulnerability from github – Published: 2025-04-01 18:30 – Updated: 2025-11-03 21:33In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix bug on trap in smb2_lock
If lock count is greater than 1, flags could be old value. It should be checked with flags of smb_lock, not flags. It will cause bug-on trap from locks_free_lock in error handling routine.
{
"affected": [],
"aliases": [
"CVE-2025-21944"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-01T16:15:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix bug on trap in smb2_lock\n\nIf lock count is greater than 1, flags could be old value.\nIt should be checked with flags of smb_lock, not flags.\nIt will cause bug-on trap from locks_free_lock in error handling\nroutine.",
"id": "GHSA-q86w-66m5-qpj3",
"modified": "2025-11-03T21:33:24Z",
"published": "2025-04-01T18:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21944"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/11e0e74e14f1832a95092f2c98ed3b99f57797ee"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2b70e3ac79eacbdf32571f7af48dd81cdd957ca8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8994f0ce8259f812b4f4a681d8298c6ff682efaa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dbcd7fdd86f77529210fe8978154a81cd479844c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e26e2d2e15daf1ab33e0135caf2304a0cfa2744b"
},
{
"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-Q8VW-4H9F-5745
Vulnerability from github – Published: 2022-05-24 16:44 – Updated: 2024-02-15 18:30The coredump implementation in the Linux kernel before 5.0.10 does not use locking or other mechanisms to prevent vma layout or vma flags changes while it runs, which allows local users to obtain sensitive information, cause a denial of service, or possibly have unspecified other impact by triggering a race condition with mmget_not_zero or get_task_mm calls. This is related to fs/userfaultfd.c, mm/mmap.c, fs/proc/task_mmu.c, and drivers/infiniband/core/uverbs_main.c.
{
"affected": [],
"aliases": [
"CVE-2019-11599"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-04-29T18:29:00Z",
"severity": "HIGH"
},
"details": "The coredump implementation in the Linux kernel before 5.0.10 does not use locking or other mechanisms to prevent vma layout or vma flags changes while it runs, which allows local users to obtain sensitive information, cause a denial of service, or possibly have unspecified other impact by triggering a race condition with mmget_not_zero or get_task_mm calls. This is related to fs/userfaultfd.c, mm/mmap.c, fs/proc/task_mmu.c, and drivers/infiniband/core/uverbs_main.c.",
"id": "GHSA-q8vw-4h9f-5745",
"modified": "2024-02-15T18:30:39Z",
"published": "2022-05-24T16:44:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11599"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/04f5866e41fb70690e28397487d8bd8eea7d712a"
},
{
"type": "WEB",
"url": "https://seclists.org/bugtraq/2019/Jul/33"
},
{
"type": "WEB",
"url": "https://seclists.org/bugtraq/2019/Jun/26"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20190517-0002"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20200608-0001"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K51674118"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K51674118?utm_source=f5support\u0026amp%3Butm_medium=RSS"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K51674118?utm_source=f5support\u0026amp;utm_medium=RSS"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4069-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4069-2"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4095-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4115-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4118-1"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2019/dsa-4465"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/46781"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/06/msg00011.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/05/msg00042.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/05/msg00041.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=04f5866e41fb70690e28397487d8bd8eea7d712a"
},
{
"type": "WEB",
"url": "https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.0.10"
},
{
"type": "WEB",
"url": "https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.37"
},
{
"type": "WEB",
"url": "https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.114"
},
{
"type": "WEB",
"url": "https://bugs.chromium.org/p/project-zero/issues/detail?id=1790"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:0543"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:0179"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:0103"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:0100"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3517"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3309"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2043"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2029"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-07/msg00014.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-07/msg00025.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/152663/Linux-Missing-Lockdown.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/153702/Slackware-Security-Advisory-Slackware-14.2-kernel-Updates.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2019/04/29/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2019/04/29/2"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2019/04/30/1"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/108113"
}
],
"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-Q945-MJ3H-45F2
Vulnerability from github – Published: 2023-04-25 00:30 – Updated: 2024-01-19 18:30The specific flaw exists within the DPT I2O Controller driver. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this in conjunction with other vulnerabilities to escalate privileges and execute arbitrary code in the context of the kernel.
{
"affected": [],
"aliases": [
"CVE-2023-2007"
],
"database_specific": {
"cwe_ids": [
"CWE-367",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-24T23:15:18Z",
"severity": "HIGH"
},
"details": "The specific flaw exists within the DPT I2O Controller driver. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this in conjunction with other vulnerabilities to escalate privileges and execute arbitrary code in the context of the kernel.",
"id": "GHSA-q945-mj3h-45f2",
"modified": "2024-01-19T18:30:22Z",
"published": "2023-04-25T00:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2007"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/b04e75a4a8a81887386a0d2dbf605a48e779d2a0"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240119-0011"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2023/dsa-5480"
}
],
"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-Q9QQ-7XQR-6GXF
Vulnerability from github – Published: 2022-05-24 17:44 – Updated: 2022-05-24 17:44An issue was discovered in fs/io_uring.c in the Linux kernel through 5.11.8. It allows attackers to cause a denial of service (deadlock) because exit may be waiting to park a SQPOLL thread, but concurrently that SQPOLL thread is waiting for a signal to start, aka CID-3ebba796fa25.
{
"affected": [],
"aliases": [
"CVE-2021-28951"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-03-20T20:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in fs/io_uring.c in the Linux kernel through 5.11.8. It allows attackers to cause a denial of service (deadlock) because exit may be waiting to park a SQPOLL thread, but concurrently that SQPOLL thread is waiting for a signal to start, aka CID-3ebba796fa25.",
"id": "GHSA-q9qq-7xqr-6gxf",
"modified": "2022-05-24T17:44:58Z",
"published": "2022-05-24T17:44:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28951"
},
{
"type": "WEB",
"url": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3ebba796fa251d042be42b929a2d916ee5c34a49"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4VCKIOXCOZGXBEZMO5LGGV5MWCHO6FT3"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PTRNPQTZ4GVS46SZ4OBXY5YDOGVPSTGQ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/T2S3I4SLRNRUQDOFYUS6IUAZMQNMPNLG"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210430-0003"
}
],
"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-QC5G-94X3-GF9G
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-14 18:31In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix locking in rxrpc's sendmsg
Fix three bugs in the rxrpc's sendmsg implementation:
(1) rxrpc_new_client_call() should release the socket lock when returning an error from rxrpc_get_call_slot().
(2) rxrpc_wait_for_tx_window_intr() will return without the call mutex held in the event that we're interrupted by a signal whilst waiting for tx space on the socket or relocking the call mutex afterwards.
Fix this by: (a) moving the unlock/lock of the call mutex up to
rxrpc_send_data() such that the lock is not held around all of
rxrpc_wait_for_tx_window*() and (b) indicating to higher callers
whether we're return with the lock dropped. Note that this means
recvmsg() will not block on this call whilst we're waiting.
(3) After dropping and regaining the call mutex, rxrpc_send_data() needs to go and recheck the state of the tx_pending buffer and the tx_total_len check in case we raced with another sendmsg() on the same call.
Thinking on this some more, it might make sense to have different locks for sendmsg() and recvmsg(). There's probably no need to make recvmsg() wait for sendmsg(). It does mean that recvmsg() can return MSG_EOR indicating that a call is dead before a sendmsg() to that call returns - but that can currently happen anyway.
Without fix (2), something like the following can be induced:
WARNING: bad unlock balance detected!
5.16.0-rc6-syzkaller #0 Not tainted
-------------------------------------
syz-executor011/3597 is trying to release lock (&call->user_mutex) at:
[<ffffffff885163a3>] rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748
but there are no more locks to release!
other info that might help us debug this:
no locks held by syz-executor011/3597.
...
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_unlock_imbalance_bug include/trace/events/lock.h:58 [inline]
__lock_release kernel/locking/lockdep.c:5306 [inline]
lock_release.cold+0x49/0x4e kernel/locking/lockdep.c:5657
__mutex_unlock_slowpath+0x99/0x5e0 kernel/locking/mutex.c:900
rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748
rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:561
sock_sendmsg_nosec net/socket.c:704 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:724
____sys_sendmsg+0x6e8/0x810 net/socket.c:2409
___sys_sendmsg+0xf3/0x170 net/socket.c:2463
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2492
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
[Thanks to Hawkins Jiawei and Khalid Masum for their attempts to fix this]
{
"affected": [],
"aliases": [
"CVE-2022-49998"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:27Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Fix locking in rxrpc\u0027s sendmsg\n\nFix three bugs in the rxrpc\u0027s sendmsg implementation:\n\n (1) rxrpc_new_client_call() should release the socket lock when returning\n an error from rxrpc_get_call_slot().\n\n (2) rxrpc_wait_for_tx_window_intr() will return without the call mutex\n held in the event that we\u0027re interrupted by a signal whilst waiting\n for tx space on the socket or relocking the call mutex afterwards.\n\n Fix this by: (a) moving the unlock/lock of the call mutex up to\n rxrpc_send_data() such that the lock is not held around all of\n rxrpc_wait_for_tx_window*() and (b) indicating to higher callers\n whether we\u0027re return with the lock dropped. Note that this means\n recvmsg() will not block on this call whilst we\u0027re waiting.\n\n (3) After dropping and regaining the call mutex, rxrpc_send_data() needs\n to go and recheck the state of the tx_pending buffer and the\n tx_total_len check in case we raced with another sendmsg() on the same\n call.\n\nThinking on this some more, it might make sense to have different locks for\nsendmsg() and recvmsg(). There\u0027s probably no need to make recvmsg() wait\nfor sendmsg(). It does mean that recvmsg() can return MSG_EOR indicating\nthat a call is dead before a sendmsg() to that call returns - but that can\ncurrently happen anyway.\n\nWithout fix (2), something like the following can be induced:\n\n\tWARNING: bad unlock balance detected!\n\t5.16.0-rc6-syzkaller #0 Not tainted\n\t-------------------------------------\n\tsyz-executor011/3597 is trying to release lock (\u0026call-\u003euser_mutex) at:\n\t[\u003cffffffff885163a3\u003e] rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748\n\tbut there are no more locks to release!\n\n\tother info that might help us debug this:\n\tno locks held by syz-executor011/3597.\n\t...\n\tCall Trace:\n\t \u003cTASK\u003e\n\t __dump_stack lib/dump_stack.c:88 [inline]\n\t dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\n\t print_unlock_imbalance_bug include/trace/events/lock.h:58 [inline]\n\t __lock_release kernel/locking/lockdep.c:5306 [inline]\n\t lock_release.cold+0x49/0x4e kernel/locking/lockdep.c:5657\n\t __mutex_unlock_slowpath+0x99/0x5e0 kernel/locking/mutex.c:900\n\t rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748\n\t rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:561\n\t sock_sendmsg_nosec net/socket.c:704 [inline]\n\t sock_sendmsg+0xcf/0x120 net/socket.c:724\n\t ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409\n\t ___sys_sendmsg+0xf3/0x170 net/socket.c:2463\n\t __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492\n\t do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n\t do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n\t entry_SYSCALL_64_after_hwframe+0x44/0xae\n\n[Thanks to Hawkins Jiawei and Khalid Masum for their attempts to fix this]",
"id": "GHSA-qc5g-94x3-gf9g",
"modified": "2025-11-14T18:31:24Z",
"published": "2025-06-18T12:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49998"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/091dc91e119fdd61432347231724f4e861c6b465"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2bc769b8edb158be7379d15f36e23d66cf850053"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/79e2ca7aa96e80961828ab6312264633b66183cc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b0f571ecd7943423c25947439045f0d352ca3dbf"
}
],
"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-QCGC-5P4X-HXC8
Vulnerability from github – Published: 2025-09-16 15:32 – Updated: 2025-12-03 18:30In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix lockdep assertion on sync reset unload event
Fix lockdep assertion triggered during sync reset unload event. When the sync reset flow is initiated using the devlink reload fw_activate option, the PF already holds the devlink lock while handling unload event. In this case, delegate sync reset unload event handling back to the devlink callback process to avoid double-locking and resolve the lockdep warning.
Kernel log: WARNING: CPU: 9 PID: 1578 at devl_assert_locked+0x31/0x40 [...] Call Trace: mlx5_unload_one_devl_locked+0x2c/0xc0 [mlx5_core] mlx5_sync_reset_unload_event+0xaf/0x2f0 [mlx5_core] process_one_work+0x222/0x640 worker_thread+0x199/0x350 kthread+0x10b/0x230 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x8e/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30
{
"affected": [],
"aliases": [
"CVE-2025-39832"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-16T14:15:51Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix lockdep assertion on sync reset unload event\n\nFix lockdep assertion triggered during sync reset unload event. When the\nsync reset flow is initiated using the devlink reload fw_activate\noption, the PF already holds the devlink lock while handling unload\nevent. In this case, delegate sync reset unload event handling back to\nthe devlink callback process to avoid double-locking and resolve the\nlockdep warning.\n\nKernel log:\nWARNING: CPU: 9 PID: 1578 at devl_assert_locked+0x31/0x40\n[...]\nCall Trace:\n\u003cTASK\u003e\n mlx5_unload_one_devl_locked+0x2c/0xc0 [mlx5_core]\n mlx5_sync_reset_unload_event+0xaf/0x2f0 [mlx5_core]\n process_one_work+0x222/0x640\n worker_thread+0x199/0x350\n kthread+0x10b/0x230\n ? __pfx_worker_thread+0x10/0x10\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x8e/0x100\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n\u003c/TASK\u003e",
"id": "GHSA-qcgc-5p4x-hxc8",
"modified": "2025-12-03T18:30:20Z",
"published": "2025-09-16T15:32:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39832"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/06d897148e79638651800d851a69547b56b4be2e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0c87dba9ccd3801d3b503f0b4fd41be343af4f06"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/902a8bc23a24882200f57cadc270e15a2cfaf2bb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ddac9d0fe2493dd550cbfc75eeaf31e9b6dac959"
}
],
"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.