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.
693 vulnerabilities reference this CWE, most recent first.
GHSA-Q37H-R28R-J29C
Vulnerability from github – Published: 2025-05-02 18:31 – Updated: 2025-11-12 18:31In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: u_audio: don't let userspace block driver unbind
In the unbind callback for f_uac1 and f_uac2, a call to snd_card_free() via g_audio_cleanup() will disconnect the card and then wait for all resources to be released, which happens when the refcount falls to zero. Since userspace can keep the refcount incremented by not closing the relevant file descriptor, the call to unbind may block indefinitely. This can cause a deadlock during reboot, as evidenced by the following blocked task observed on my machine:
task:reboot state:D stack:0 pid:2827 ppid:569 flags:0x0000000c Call trace: __switch_to+0xc8/0x140 __schedule+0x2f0/0x7c0 schedule+0x60/0xd0 schedule_timeout+0x180/0x1d4 wait_for_completion+0x78/0x180 snd_card_free+0x90/0xa0 g_audio_cleanup+0x2c/0x64 afunc_unbind+0x28/0x60 ... kernel_restart+0x4c/0xac __do_sys_reboot+0xcc/0x1ec __arm64_sys_reboot+0x28/0x30 invoke_syscall+0x4c/0x110 ...
The issue can also be observed by opening the card with arecord and then stopping the process through the shell before unbinding:
# arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null Recording WAVE '/dev/null' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo ^Z[1]+ Stopped arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null # echo gadget.0 > /sys/bus/gadget/drivers/configfs-gadget/unbind (observe that the unbind command never finishes)
Fix the problem by using snd_card_free_when_closed() instead, which will still disconnect the card as desired, but defer the task of freeing the resources to the core once userspace closes its file descriptor.
{
"affected": [],
"aliases": [
"CVE-2023-53045"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-02T16:15:23Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: u_audio: don\u0027t let userspace block driver unbind\n\nIn the unbind callback for f_uac1 and f_uac2, a call to snd_card_free()\nvia g_audio_cleanup() will disconnect the card and then wait for all\nresources to be released, which happens when the refcount falls to zero.\nSince userspace can keep the refcount incremented by not closing the\nrelevant file descriptor, the call to unbind may block indefinitely.\nThis can cause a deadlock during reboot, as evidenced by the following\nblocked task observed on my machine:\n\n task:reboot state:D stack:0 pid:2827 ppid:569 flags:0x0000000c\n Call trace:\n __switch_to+0xc8/0x140\n __schedule+0x2f0/0x7c0\n schedule+0x60/0xd0\n schedule_timeout+0x180/0x1d4\n wait_for_completion+0x78/0x180\n snd_card_free+0x90/0xa0\n g_audio_cleanup+0x2c/0x64\n afunc_unbind+0x28/0x60\n ...\n kernel_restart+0x4c/0xac\n __do_sys_reboot+0xcc/0x1ec\n __arm64_sys_reboot+0x28/0x30\n invoke_syscall+0x4c/0x110\n ...\n\nThe issue can also be observed by opening the card with arecord and\nthen stopping the process through the shell before unbinding:\n\n # arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null\n Recording WAVE \u0027/dev/null\u0027 : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo\n ^Z[1]+ Stopped arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null\n # echo gadget.0 \u003e /sys/bus/gadget/drivers/configfs-gadget/unbind\n (observe that the unbind command never finishes)\n\nFix the problem by using snd_card_free_when_closed() instead, which will\nstill disconnect the card as desired, but defer the task of freeing the\nresources to the core once userspace closes its file descriptor.",
"id": "GHSA-q37h-r28r-j29c",
"modified": "2025-11-12T18:31:03Z",
"published": "2025-05-02T18:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53045"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0eda2004f38d95ef5715d62be884cd344260535b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3256e152b645fc1e788ba44c2d8ced690113e3e6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/33f341c1fc60e172a3515c51bdabee11e83d1ee9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3bc7324e4911351e39c54a62e6ca46321cb10faf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e016ef2e72da93a2ea7afbb45de1b481b44d761"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/43ca70753dfffd517d2af126da28690f8f615605"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6c67ed9ad9b83e453e808f9b31a931a20a25629b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b131989797f7287d7fdadb2bababc05a15d44750"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-Q383-XWJ3-RCF5
Vulnerability from github – Published: 2025-02-27 03:34 – Updated: 2025-12-16 18:31In the Linux kernel, the following vulnerability has been resolved:
tcp: correct handling of extreme memory squeeze
Testing with iperf3 using the "pasta" protocol splicer has revealed a problem in the way tcp handles window advertising in extreme memory squeeze situations.
Under memory pressure, a socket endpoint may temporarily advertise a zero-sized window, but this is not stored as part of the socket data. The reasoning behind this is that it is considered a temporary setting which shouldn't influence any further calculations.
However, if we happen to stall at an unfortunate value of the current window size, the algorithm selecting a new value will consistently fail to advertise a non-zero window once we have freed up enough memory. This means that this side's notion of the current window size is different from the one last advertised to the peer, causing the latter to not send any data to resolve the sitution.
The problem occurs on the iperf3 server side, and the socket in question is a completely regular socket with the default settings for the fedora40 kernel. We do not use SO_PEEK or SO_RCVBUF on the socket.
The following excerpt of a logging session, with own comments added, shows more in detail what is happening:
// tcp_v4_rcv(->) // tcp_rcv_established(->) 5201<->39222: ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ====
5201<->39222: DROPPING skb [265600160..265665640], reason: SKB_DROP_REASON_PROTO_MEM [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184] [copied_seq 259909392->260034360 (124968), unread 5565800, qlen 85, ofoq 0] [OFO queue: gap: 65480, len: 0]
[tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]
5201<->39222: (inet_csk(sk)->icsk_ack.pending & ICSK_ACK_NOMEM) ? --> TRUE [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160] returning 0
5201<->39222: ADVERTISING WIN 0, ACK_SEQ: 265600160
// Receive queue is at 85 buffers and we are out of memory. // We drop the incoming buffer, although it is in sequence, and decide // to send an advertisement with a window of zero. // We don't update tp->rcv_wnd and tp->rcv_wup accordingly, which means // we unconditionally shrink the window.
5201<->39222: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160 5201<->39222: new_win = 0, win_now = 131184, 2 * win_now = 262368: new_win >= (2 * win_now) ? --> time_to_ack = 0: NOT calling tcp_send_ack() [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]
[rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]
[copied_seq 260040464->260040464 (0), unread 5559696, qlen 85, ofoq 0]
returning 6104 bytes
// After each read, the algorithm for calculating the new receive // window in __tcp_cleanup_rbuf() finds it is too small to advertise // or to update tp->rcv_wnd. // Meanwhile, the peer thinks the window is zero, and will not send // any more data to trigger an update from the interrupt mode side.
5201<->39222: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160 5201<->39222: [new_win = 262144, win_now = 131184, 2 * win_n ---truncated---
{
"affected": [],
"aliases": [
"CVE-2025-21710"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-27T02:15:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: correct handling of extreme memory squeeze\n\nTesting with iperf3 using the \"pasta\" protocol splicer has revealed\na problem in the way tcp handles window advertising in extreme memory\nsqueeze situations.\n\nUnder memory pressure, a socket endpoint may temporarily advertise\na zero-sized window, but this is not stored as part of the socket data.\nThe reasoning behind this is that it is considered a temporary setting\nwhich shouldn\u0027t influence any further calculations.\n\nHowever, if we happen to stall at an unfortunate value of the current\nwindow size, the algorithm selecting a new value will consistently fail\nto advertise a non-zero window once we have freed up enough memory.\nThis means that this side\u0027s notion of the current window size is\ndifferent from the one last advertised to the peer, causing the latter\nto not send any data to resolve the sitution.\n\nThe problem occurs on the iperf3 server side, and the socket in question\nis a completely regular socket with the default settings for the\nfedora40 kernel. We do not use SO_PEEK or SO_RCVBUF on the socket.\n\nThe following excerpt of a logging session, with own comments added,\nshows more in detail what is happening:\n\n// tcp_v4_rcv(-\u003e)\n// tcp_rcv_established(-\u003e)\n[5201\u003c-\u003e39222]: ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ====\n[5201\u003c-\u003e39222]: tcp_data_queue(-\u003e)\n[5201\u003c-\u003e39222]: DROPPING skb [265600160..265665640], reason: SKB_DROP_REASON_PROTO_MEM\n [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]\n [copied_seq 259909392-\u003e260034360 (124968), unread 5565800, qlen 85, ofoq 0]\n [OFO queue: gap: 65480, len: 0]\n[5201\u003c-\u003e39222]: tcp_data_queue(\u003c-)\n[5201\u003c-\u003e39222]: __tcp_transmit_skb(-\u003e)\n [tp-\u003ercv_wup: 265469200, tp-\u003ercv_wnd: 262144, tp-\u003ercv_nxt 265600160]\n[5201\u003c-\u003e39222]: tcp_select_window(-\u003e)\n[5201\u003c-\u003e39222]: (inet_csk(sk)-\u003eicsk_ack.pending \u0026 ICSK_ACK_NOMEM) ? --\u003e TRUE\n [tp-\u003ercv_wup: 265469200, tp-\u003ercv_wnd: 262144, tp-\u003ercv_nxt 265600160]\n returning 0\n[5201\u003c-\u003e39222]: tcp_select_window(\u003c-)\n[5201\u003c-\u003e39222]: ADVERTISING WIN 0, ACK_SEQ: 265600160\n[5201\u003c-\u003e39222]: [__tcp_transmit_skb(\u003c-)\n[5201\u003c-\u003e39222]: tcp_rcv_established(\u003c-)\n[5201\u003c-\u003e39222]: tcp_v4_rcv(\u003c-)\n\n// Receive queue is at 85 buffers and we are out of memory.\n// We drop the incoming buffer, although it is in sequence, and decide\n// to send an advertisement with a window of zero.\n// We don\u0027t update tp-\u003ercv_wnd and tp-\u003ercv_wup accordingly, which means\n// we unconditionally shrink the window.\n\n[5201\u003c-\u003e39222]: tcp_recvmsg_locked(-\u003e)\n[5201\u003c-\u003e39222]: __tcp_cleanup_rbuf(-\u003e) tp-\u003ercv_wup: 265469200, tp-\u003ercv_wnd: 262144, tp-\u003ercv_nxt 265600160\n[5201\u003c-\u003e39222]: [new_win = 0, win_now = 131184, 2 * win_now = 262368]\n[5201\u003c-\u003e39222]: [new_win \u003e= (2 * win_now) ? --\u003e time_to_ack = 0]\n[5201\u003c-\u003e39222]: NOT calling tcp_send_ack()\n [tp-\u003ercv_wup: 265469200, tp-\u003ercv_wnd: 262144, tp-\u003ercv_nxt 265600160]\n[5201\u003c-\u003e39222]: __tcp_cleanup_rbuf(\u003c-)\n [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]\n [copied_seq 260040464-\u003e260040464 (0), unread 5559696, qlen 85, ofoq 0]\n returning 6104 bytes\n[5201\u003c-\u003e39222]: tcp_recvmsg_locked(\u003c-)\n\n// After each read, the algorithm for calculating the new receive\n// window in __tcp_cleanup_rbuf() finds it is too small to advertise\n// or to update tp-\u003ercv_wnd.\n// Meanwhile, the peer thinks the window is zero, and will not send\n// any more data to trigger an update from the interrupt mode side.\n\n[5201\u003c-\u003e39222]: tcp_recvmsg_locked(-\u003e)\n[5201\u003c-\u003e39222]: __tcp_cleanup_rbuf(-\u003e) tp-\u003ercv_wup: 265469200, tp-\u003ercv_wnd: 262144, tp-\u003ercv_nxt 265600160\n[5201\u003c-\u003e39222]: [new_win = 262144, win_now = 131184, 2 * win_n\n---truncated---",
"id": "GHSA-q383-xwj3-rcf5",
"modified": "2025-12-16T18:31:27Z",
"published": "2025-02-27T03:34:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21710"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1dd823a46e25ffde1492c391934f69a9e5eb574f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8c670bdfa58e48abad1d5b6ca1ee843ca91f7303"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b01e7ceb35dcb7ffad413da657b78c3340a09039"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b4055e2fe96f4ef101d8af0feb056d78d77514ff"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-Q3V6-CHW5-G495
Vulnerability from github – Published: 2025-05-01 15:31 – Updated: 2025-11-05 18:14In the Linux kernel, the following vulnerability has been resolved:
PCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t type
The access to the PCI config space via pci_ops::read and pci_ops::write is a low-level hardware access. The functions can be accessed with disabled interrupts even on PREEMPT_RT. The pci_lock is a raw_spinlock_t for this purpose.
A spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot be acquired with disabled interrupts. The vmd_dev::cfg_lock is accessed in the same context as the pci_lock.
Make vmd_dev::cfg_lock a raw_spinlock_t type so it can be used with interrupts disabled.
This was reported as:
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 Call Trace: rt_spin_lock+0x4e/0x130 vmd_pci_read+0x8d/0x100 [vmd] pci_user_read_config_byte+0x6f/0xe0 pci_read_config+0xfe/0x290 sysfs_kf_bin_read+0x68/0x90
[bigeasy: reword commit message] Tested-off-by: Luis Claudio R. Goncalves lgoncalv@redhat.com [kwilczynski: commit log] [bhelgaas: add back report info from https://lore.kernel.org/lkml/20241218115951.83062-1-ryotkkr98@gmail.com/]
{
"affected": [],
"aliases": [
"CVE-2025-23161"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-01T13:15:52Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t type\n\nThe access to the PCI config space via pci_ops::read and pci_ops::write is\na low-level hardware access. The functions can be accessed with disabled\ninterrupts even on PREEMPT_RT. The pci_lock is a raw_spinlock_t for this\npurpose.\n\nA spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot be\nacquired with disabled interrupts. The vmd_dev::cfg_lock is accessed in\nthe same context as the pci_lock.\n\nMake vmd_dev::cfg_lock a raw_spinlock_t type so it can be used with\ninterrupts disabled.\n\nThis was reported as:\n\n BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n Call Trace:\n rt_spin_lock+0x4e/0x130\n vmd_pci_read+0x8d/0x100 [vmd]\n pci_user_read_config_byte+0x6f/0xe0\n pci_read_config+0xfe/0x290\n sysfs_kf_bin_read+0x68/0x90\n\n[bigeasy: reword commit message]\nTested-off-by: Luis Claudio R. Goncalves \u003clgoncalv@redhat.com\u003e\n[kwilczynski: commit log]\n[bhelgaas: add back report info from\nhttps://lore.kernel.org/lkml/20241218115951.83062-1-ryotkkr98@gmail.com/]",
"id": "GHSA-q3v6-chw5-g495",
"modified": "2025-11-05T18:14:26Z",
"published": "2025-05-01T15:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23161"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/13e5148f70e81991acbe0bab5b1b50ba699116e7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/18056a48669a040bef491e63b25896561ee14d90"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/20d0a9062c031068fa39f725a32f182b709b5525"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2358046ead696ca5c7c628d6c0e2c6792619a3e5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5c3cfcf0b4bf43530788b08a8eaf7896ec567484"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c250262d6485ca333e9821f85b07eb383ec546b1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c2968c812339593ac6e2bdd5cc3adabe3f05fa53"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-Q4HG-RMQ2-52Q9
Vulnerability from github – Published: 2019-06-26 01:09 – Updated: 2024-03-11 15:39The fix for CVE-2019-0199 was incomplete and did not address HTTP/2 connection window exhaustion on write in Apache Tomcat versions 9.0.0.M1 to 9.0.19 and 8.5.0 to 8.5.40 . By not sending WINDOW_UPDATE messages for the connection window (stream 0) clients were able to cause server-side threads to block eventually leading to thread exhaustion and a DoS.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0.M1"
},
{
"fixed": "9.0.20"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "8.5.0"
},
{
"fixed": "8.5.41"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-10072"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": true,
"github_reviewed_at": "2019-06-26T00:56:45Z",
"nvd_published_at": "2019-06-21T18:15:00Z",
"severity": "HIGH"
},
"details": "The fix for CVE-2019-0199 was incomplete and did not address HTTP/2 connection window exhaustion on write in Apache Tomcat versions 9.0.0.M1 to 9.0.19 and 8.5.0 to 8.5.40 . By not sending WINDOW_UPDATE messages for the connection window (stream 0) clients were able to cause server-side threads to block eventually leading to thread exhaustion and a DoS.",
"id": "GHSA-q4hg-rmq2-52q9",
"modified": "2024-03-11T15:39:14Z",
"published": "2019-06-26T01:09:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10072"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/0bcd69c9dd8ae0ff424f2cd46de51583510b7f35"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/7f748eb6bfaba5207c89dbd7d5adf50fae847145"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/8d14c6f21d29768a39be4b6b9517060dc6606758"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/ada725a50a60867af3422c8e612aecaeea856a9a"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20190625-0002"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K17321505"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-8.html"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-9.html"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4128-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4128-2"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20200227033743/http://www.securityfocus.com/bid/108874"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2020/dsa-4680"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2020.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2020.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2020.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/technetwork/security-advisory/cpuoct2019-5072832.html"
},
{
"type": "WEB",
"url": "https://www.synology.com/security/advisory/Synology_SA_19_29"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/raba0fabaf4d56d4325ab2aca8814f0b30a237ab83d8106b115ee279a@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/raba0fabaf4d56d4325ab2aca8814f0b30a237ab83d8106b115ee279a%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r6ccee4e849bc77df0840c7f853f6bd09d426f6741247da2b7429d5d9@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r6ccee4e849bc77df0840c7f853f6bd09d426f6741247da2b7429d5d9%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r48c1444845fe15a823e1374674bfc297d5008a5453788099ea14caf0@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r48c1444845fe15a823e1374674bfc297d5008a5453788099ea14caf0%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3bbb800a816d0a51eccc5a228c58736960a9fffafa581a225834d97d@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3bbb800a816d0a51eccc5a228c58736960a9fffafa581a225834d97d%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/df1a2c1b87c8a6c500ecdbbaf134c7f1491c8d79d98b48c6b9f0fa6a@%3Cannounce.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/df1a2c1b87c8a6c500ecdbbaf134c7f1491c8d79d98b48c6b9f0fa6a%40%3Cannounce.tomcat.apache.org%3E"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/tomcat"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3931"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3929"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-01/msg00013.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Improper Locking in Apache Tomcat"
}
GHSA-Q4JH-G383-RJCG
Vulnerability from github – Published: 2024-04-03 18:30 – Updated: 2025-02-03 18:30In the Linux kernel, the following vulnerability has been resolved:
net: implement lockless setsockopt(SO_PEEK_OFF)
syzbot reported a lockdep violation [1] involving af_unix support of SO_PEEK_OFF.
Since SO_PEEK_OFF is inherently not thread safe (it uses a per-socket sk_peek_off field), there is really no point to enforce a pointless thread safety in the kernel.
After this patch :
-
setsockopt(SO_PEEK_OFF) no longer acquires the socket lock.
-
skb_consume_udp() no longer has to acquire the socket lock.
-
af_unix no longer needs a special version of sk_set_peek_off(), because it does not lock u->iolock anymore.
As a followup, we could replace prot->set_peek_off to be a boolean and avoid an indirect call, since we always use sk_set_peek_off().
[1]
WARNING: possible circular locking dependency detected 6.8.0-rc4-syzkaller-00267-g0f1dd5e91e2b #0 Not tainted
syz-executor.2/30025 is trying to acquire lock: ffff8880765e7d80 (&u->iolock){+.+.}-{3:3}, at: unix_set_peek_off+0x26/0xa0 net/unix/af_unix.c:789
but task is already holding lock: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1691 [inline] ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sockopt_lock_sock net/core/sock.c:1060 [inline] ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sk_setsockopt+0xe52/0x3360 net/core/sock.c:1193
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (sk_lock-AF_UNIX){+.+.}-{0:0}: lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 lock_sock_nested+0x48/0x100 net/core/sock.c:3524 lock_sock include/net/sock.h:1691 [inline] __unix_dgram_recvmsg+0x1275/0x12c0 net/unix/af_unix.c:2415 sock_recvmsg_nosec+0x18e/0x1d0 net/socket.c:1046 _sysrecvmsg+0x3c0/0x470 net/socket.c:2801 _sys_recvmsg net/socket.c:2845 [inline] do_recvmmsg+0x474/0xae0 net/socket.c:2939 __sys_recvmmsg net/socket.c:3018 [inline] __do_sys_recvmmsg net/socket.c:3041 [inline] __se_sys_recvmmsg net/socket.c:3034 [inline] __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77
-> #0 (&u->iolock){+.+.}-{3:3}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 unix_set_peek_off+0x26/0xa0 net/unix/af_unix.c:789 sk_setsockopt+0x207e/0x3360 do_sock_setsockopt+0x2fb/0x720 net/socket.c:2307 __sys_setsockopt+0x1ad/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(sk_lock-AF_UNIX); lock(&u->iolock); lock(sk_lock-AF_UNIX); lock(&u->iolock);
*** DEADLOCK ***
1 lock held by syz-executor.2/30025: #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1691 [inline] #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sockopt_lock_sock net/core/sock.c:1060 [inline] #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sk_setsockopt+0xe52/0x3360 net/core/sock.c:1193
stack backtrace: CPU: 0 PID: 30025 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00267-g0f1dd5e91e2b #0 Hardware name: Google Google C ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-26732"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-03T17:15:50Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: implement lockless setsockopt(SO_PEEK_OFF)\n\nsyzbot reported a lockdep violation [1] involving af_unix\nsupport of SO_PEEK_OFF.\n\nSince SO_PEEK_OFF is inherently not thread safe (it uses a per-socket\nsk_peek_off field), there is really no point to enforce a pointless\nthread safety in the kernel.\n\nAfter this patch :\n\n- setsockopt(SO_PEEK_OFF) no longer acquires the socket lock.\n\n- skb_consume_udp() no longer has to acquire the socket lock.\n\n- af_unix no longer needs a special version of sk_set_peek_off(),\n because it does not lock u-\u003eiolock anymore.\n\nAs a followup, we could replace prot-\u003eset_peek_off to be a boolean\nand avoid an indirect call, since we always use sk_set_peek_off().\n\n[1]\n\nWARNING: possible circular locking dependency detected\n6.8.0-rc4-syzkaller-00267-g0f1dd5e91e2b #0 Not tainted\n\nsyz-executor.2/30025 is trying to acquire lock:\n ffff8880765e7d80 (\u0026u-\u003eiolock){+.+.}-{3:3}, at: unix_set_peek_off+0x26/0xa0 net/unix/af_unix.c:789\n\nbut task is already holding lock:\n ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1691 [inline]\n ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sockopt_lock_sock net/core/sock.c:1060 [inline]\n ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sk_setsockopt+0xe52/0x3360 net/core/sock.c:1193\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u003e #1 (sk_lock-AF_UNIX){+.+.}-{0:0}:\n lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754\n lock_sock_nested+0x48/0x100 net/core/sock.c:3524\n lock_sock include/net/sock.h:1691 [inline]\n __unix_dgram_recvmsg+0x1275/0x12c0 net/unix/af_unix.c:2415\n sock_recvmsg_nosec+0x18e/0x1d0 net/socket.c:1046\n ____sys_recvmsg+0x3c0/0x470 net/socket.c:2801\n ___sys_recvmsg net/socket.c:2845 [inline]\n do_recvmmsg+0x474/0xae0 net/socket.c:2939\n __sys_recvmmsg net/socket.c:3018 [inline]\n __do_sys_recvmmsg net/socket.c:3041 [inline]\n __se_sys_recvmmsg net/socket.c:3034 [inline]\n __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034\n do_syscall_64+0xf9/0x240\n entry_SYSCALL_64_after_hwframe+0x6f/0x77\n\n-\u003e #0 (\u0026u-\u003eiolock){+.+.}-{3:3}:\n check_prev_add kernel/locking/lockdep.c:3134 [inline]\n check_prevs_add kernel/locking/lockdep.c:3253 [inline]\n validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869\n __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137\n lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754\n __mutex_lock_common kernel/locking/mutex.c:608 [inline]\n __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752\n unix_set_peek_off+0x26/0xa0 net/unix/af_unix.c:789\n sk_setsockopt+0x207e/0x3360\n do_sock_setsockopt+0x2fb/0x720 net/socket.c:2307\n __sys_setsockopt+0x1ad/0x250 net/socket.c:2334\n __do_sys_setsockopt net/socket.c:2343 [inline]\n __se_sys_setsockopt net/socket.c:2340 [inline]\n __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xf9/0x240\n entry_SYSCALL_64_after_hwframe+0x6f/0x77\n\nother info that might help us debug this:\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(sk_lock-AF_UNIX);\n lock(\u0026u-\u003eiolock);\n lock(sk_lock-AF_UNIX);\n lock(\u0026u-\u003eiolock);\n\n *** DEADLOCK ***\n\n1 lock held by syz-executor.2/30025:\n #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1691 [inline]\n #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sockopt_lock_sock net/core/sock.c:1060 [inline]\n #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sk_setsockopt+0xe52/0x3360 net/core/sock.c:1193\n\nstack backtrace:\nCPU: 0 PID: 30025 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00267-g0f1dd5e91e2b #0\nHardware name: Google Google C\n---truncated---",
"id": "GHSA-q4jh-g383-rjcg",
"modified": "2025-02-03T18:30:35Z",
"published": "2024-04-03T18:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26732"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/56667da7399eb19af857e30f41bea89aa6fa812c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/897f75e2cde8a5f9f7529b55249af1fa4248c83b"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-Q63X-GG9G-Q34F
Vulnerability from github – Published: 2026-01-13 18:31 – Updated: 2026-07-14 15:31In the Linux kernel, the following vulnerability has been resolved:
net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write
A deadlock can occur between nfc_unregister_device() and rfkill_fop_write() due to lock ordering inversion between device_lock and rfkill_global_mutex.
The problematic lock order is:
Thread A (rfkill_fop_write): rfkill_fop_write() mutex_lock(&rfkill_global_mutex) rfkill_set_block() nfc_rfkill_set_block() nfc_dev_down() device_lock(&dev->dev) <- waits for device_lock
Thread B (nfc_unregister_device): nfc_unregister_device() device_lock(&dev->dev) rfkill_unregister() mutex_lock(&rfkill_global_mutex) <- waits for rfkill_global_mutex
This creates a classic ABBA deadlock scenario.
Fix this by moving rfkill_unregister() and rfkill_destroy() outside the device_lock critical section. Store the rfkill pointer in a local variable before releasing the lock, then call rfkill_unregister() after releasing device_lock.
This change is safe because rfkill_fop_write() holds rfkill_global_mutex while calling the rfkill callbacks, and rfkill_unregister() also acquires rfkill_global_mutex before cleanup. Therefore, rfkill_unregister() will wait for any ongoing callback to complete before proceeding, and device_del() is only called after rfkill_unregister() returns, preventing any use-after-free.
The similar lock ordering in nfc_register_device() (device_lock -> rfkill_global_mutex via rfkill_register) is safe because during registration the device is not yet in rfkill_list, so no concurrent rfkill operations can occur on this device.
{
"affected": [],
"aliases": [
"CVE-2025-71079"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-13T16:16:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write\n\nA deadlock can occur between nfc_unregister_device() and rfkill_fop_write()\ndue to lock ordering inversion between device_lock and rfkill_global_mutex.\n\nThe problematic lock order is:\n\nThread A (rfkill_fop_write):\n rfkill_fop_write()\n mutex_lock(\u0026rfkill_global_mutex)\n rfkill_set_block()\n nfc_rfkill_set_block()\n nfc_dev_down()\n device_lock(\u0026dev-\u003edev) \u003c- waits for device_lock\n\nThread B (nfc_unregister_device):\n nfc_unregister_device()\n device_lock(\u0026dev-\u003edev)\n rfkill_unregister()\n mutex_lock(\u0026rfkill_global_mutex) \u003c- waits for rfkill_global_mutex\n\nThis creates a classic ABBA deadlock scenario.\n\nFix this by moving rfkill_unregister() and rfkill_destroy() outside the\ndevice_lock critical section. Store the rfkill pointer in a local variable\nbefore releasing the lock, then call rfkill_unregister() after releasing\ndevice_lock.\n\nThis change is safe because rfkill_fop_write() holds rfkill_global_mutex\nwhile calling the rfkill callbacks, and rfkill_unregister() also acquires\nrfkill_global_mutex before cleanup. Therefore, rfkill_unregister() will\nwait for any ongoing callback to complete before proceeding, and\ndevice_del() is only called after rfkill_unregister() returns, preventing\nany use-after-free.\n\nThe similar lock ordering in nfc_register_device() (device_lock -\u003e\nrfkill_global_mutex via rfkill_register) is safe because during\nregistration the device is not yet in rfkill_list, so no concurrent\nrfkill operations can occur on this device.",
"id": "GHSA-q63x-gg9g-q34f",
"modified": "2026-07-14T15:31:31Z",
"published": "2026-01-13T18:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71079"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1ab526d97a57e44d26fadcc0e9adeb9c0c0182f5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2e0831e9fc46a06daa6d4d8d57a2738e343130c3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6b93c8ab6f6cda8818983a4ae3fcf84b023037b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8fc4632fb508432895430cd02b38086bdd649083"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e02a1c33f10a0ed3aba855ab8ae2b6c4c5be8012"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ee41f4f3ccf8cd6ba3732e867abbec7e6d8d12e5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f3a8a7c1aa278f2378b2f3a10500c6674dffdfda"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-Q6X6-WRP8-56VH
Vulnerability from github – Published: 2023-02-28 18:30 – Updated: 2023-03-06 21:30In multiple functions of looper_backed_event_loop.cpp, there is a possible way to corrupt memory due to improper locking. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-12 Android-12L Android-13Android ID: A-243362981
{
"affected": [],
"aliases": [
"CVE-2023-20939"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-28T17:15:00Z",
"severity": "HIGH"
},
"details": "In multiple functions of looper_backed_event_loop.cpp, there is a possible way to corrupt memory due to improper locking. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-12 Android-12L Android-13Android ID: A-243362981",
"id": "GHSA-q6x6-wrp8-56vh",
"modified": "2023-03-06T21:30:19Z",
"published": "2023-02-28T18:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20939"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2023-02-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
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"
}
]
}
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.