| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| NamelessMC is a free, easy to use & powerful website software for Minecraft servers. In version 2.1.4 and prior, the forum allows users to post iframe elements inside forum topics/comments/feed with no restriction on the iframe's width and height attributes. This allows an authenticated attacker to perform a UI-based denial of service (DoS) by injecting oversized iframes that block the forum UI and disrupt normal user interactions. This issue has been patched in version 2.2.0. |
| NamelessMC is a free, easy to use & powerful website software for Minecraft servers. In version 2.1.4 and prior, forum quick reply feature (view_topic.php) does not implement any spam prevention mechanism. This allows authenticated users to continuously post replies without any time restriction, resulting in an uncontrolled surge of posts that can disrupt normal operations. This issue has been patched in version 2.2.0. |
| Windows Remote Desktop Services Denial of Service Vulnerability |
| Windows Remote Desktop Gateway (RD Gateway) Denial of Service Vulnerability |
| Microsoft Message Queuing (MSMQ) Denial of Service Vulnerability |
| supybot-fedora implements the command 'refresh', that refreshes the cache of all users from FAS. This takes quite a while to run, and zodbot stops responding to requests during this time. |
| A vulnerability was found in the minimatch package. This flaw allows a Regular Expression Denial of Service (ReDoS) when calling the braceExpand function with specific arguments, resulting in a Denial of Service. |
| An issue was discovered in Ollama before 0.1.34. The CreateModelHandler function uses os.Open to read a file until completion. The req.Path parameter is user-controlled and can be set to /dev/random, which is blocking, causing the goroutine to run infinitely (even after the HTTP request is aborted by the client). |
| A vulnerability has been identified in APOGEE MBC (PPC) (BACnet) (All versions), APOGEE MBC (PPC) (P2 Ethernet) (All versions), APOGEE MEC (PPC) (BACnet) (All versions), APOGEE MEC (PPC) (P2 Ethernet) (All versions), APOGEE PXC Compact (BACnet) (All versions < V3.5.7), APOGEE PXC Compact (P2 Ethernet) (All versions < V2.8.21), APOGEE PXC Modular (BACnet) (All versions < V3.5.7), APOGEE PXC Modular (P2 Ethernet) (All versions < V2.8.21), Desigo PXC00-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC00-U (All versions >= V2.3 < V6.30.37), Desigo PXC001-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC100-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC12-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC128-U (All versions >= V2.3 < V6.30.37), Desigo PXC200-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC22-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC22.1-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC36.1-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC50-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC64-U (All versions >= V2.3 < V6.30.37), Desigo PXM20-E (All versions >= V2.3 < V6.30.37), Nucleus NET for Nucleus PLUS V1 (All versions < V5.2a), Nucleus NET for Nucleus PLUS V2 (All versions < V5.4), Nucleus ReadyStart V3 V2012 (All versions < V2012.08.1), Nucleus ReadyStart V3 V2017 (All versions < V2017.02.4), Nucleus Source Code (All versions including affected FTP server), TALON TC Compact (BACnet) (All versions < V3.5.7), TALON TC Modular (BACnet) (All versions < V3.5.7). The FTP server does not properly release memory resources that were reserved for incomplete connection attempts by FTP clients. This could allow a remote attacker to generate a denial of service condition on devices that incorporate a vulnerable version of the FTP server. |
| In the Linux kernel, the following vulnerability has been resolved:
tcp: fix tcp_init_transfer() to not reset icsk_ca_initialized
This commit fixes a bug (found by syzkaller) that could cause spurious
double-initializations for congestion control modules, which could cause
memory leaks or other problems for congestion control modules (like CDG)
that allocate memory in their init functions.
The buggy scenario constructed by syzkaller was something like:
(1) create a TCP socket
(2) initiate a TFO connect via sendto()
(3) while socket is in TCP_SYN_SENT, call setsockopt(TCP_CONGESTION),
which calls:
tcp_set_congestion_control() ->
tcp_reinit_congestion_control() ->
tcp_init_congestion_control()
(4) receive ACK, connection is established, call tcp_init_transfer(),
set icsk_ca_initialized=0 (without first calling cc->release()),
call tcp_init_congestion_control() again.
Note that in this sequence tcp_init_congestion_control() is called
twice without a cc->release() call in between. Thus, for CC modules
that allocate memory in their init() function, e.g, CDG, a memory leak
may occur. The syzkaller tool managed to find a reproducer that
triggered such a leak in CDG.
The bug was introduced when that commit 8919a9b31eb4 ("tcp: Only init
congestion control if not initialized already")
introduced icsk_ca_initialized and set icsk_ca_initialized to 0 in
tcp_init_transfer(), missing the possibility for a sequence like the
one above, where a process could call setsockopt(TCP_CONGESTION) in
state TCP_SYN_SENT (i.e. after the connect() or TFO open sendmsg()),
which would call tcp_init_congestion_control(). It did not intend to
reset any initialization that the user had already explicitly made;
it just missed the possibility of that particular sequence (which
syzkaller managed to find). |
| In the Linux kernel, the following vulnerability has been resolved:
dma-buf/sync_file: Don't leak fences on merge failure
Each add_fence() call does a dma_fence_get() on the relevant fence. In
the error path, we weren't calling dma_fence_put() so all those fences
got leaked. Also, in the krealloc_array failure case, we weren't
freeing the fences array. Instead, ensure that i and fences are always
zero-initialized and dma_fence_put() all the fences and kfree(fences) on
every error path. |
| In the Linux kernel, the following vulnerability has been resolved:
memory: fsl_ifc: fix leak of IO mapping on probe failure
On probe error the driver should unmap the IO memory. Smatch reports:
drivers/memory/fsl_ifc.c:298 fsl_ifc_ctrl_probe() warn: 'fsl_ifc_ctrl_dev->gregs' not released on lines: 298. |
| In the Linux kernel, the following vulnerability has been resolved:
afs: Fix page leak
There's a loop in afs_extend_writeback() that adds extra pages to a write
we want to make to improve the efficiency of the writeback by making it
larger. This loop stops, however, if we hit a page we can't write back
from immediately, but it doesn't get rid of the page ref we speculatively
acquired.
This was caused by the removal of the cleanup loop when the code switched
from using find_get_pages_contig() to xarray scanning as the latter only
gets a single page at a time, not a batch.
Fix this by putting the page on a ref on an early break from the loop.
Unfortunately, we can't just add that page to the pagevec we're employing
as we'll go through that and add those pages to the RPC call.
This was found by the generic/074 test. It leaks ~4GiB of RAM each time it
is run - which can be observed with "top". |
| In the Linux kernel, the following vulnerability has been resolved:
mptcp: ensure tx skbs always have the MPTCP ext
Due to signed/unsigned comparison, the expression:
info->size_goal - skb->len > 0
evaluates to true when the size goal is smaller than the
skb size. That results in lack of tx cache refill, so that
the skb allocated by the core TCP code lacks the required
MPTCP skb extensions.
Due to the above, syzbot is able to trigger the following WARN_ON():
WARNING: CPU: 1 PID: 810 at net/mptcp/protocol.c:1366 mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366
Modules linked in:
CPU: 1 PID: 810 Comm: syz-executor.4 Not tainted 5.14.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366
Code: ff 4c 8b 74 24 50 48 8b 5c 24 58 e9 0f fb ff ff e8 13 44 8b f8 4c 89 e7 45 31 ed e8 98 57 2e fe e9 81 f4 ff ff e8 fe 43 8b f8 <0f> 0b 41 bd ea ff ff ff e9 6f f4 ff ff 4c 89 e7 e8 b9 8e d2 f8 e9
RSP: 0018:ffffc9000531f6a0 EFLAGS: 00010216
RAX: 000000000000697f RBX: 0000000000000000 RCX: ffffc90012107000
RDX: 0000000000040000 RSI: ffffffff88eac9e2 RDI: 0000000000000003
RBP: ffff888078b15780 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff88eac017 R11: 0000000000000000 R12: ffff88801de0a280
R13: 0000000000006b58 R14: ffff888066278280 R15: ffff88803c2fe9c0
FS: 00007fd9f866e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007faebcb2f718 CR3: 00000000267cb000 CR4: 00000000001506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__mptcp_push_pending+0x1fb/0x6b0 net/mptcp/protocol.c:1547
mptcp_release_cb+0xfe/0x210 net/mptcp/protocol.c:3003
release_sock+0xb4/0x1b0 net/core/sock.c:3206
sk_stream_wait_memory+0x604/0xed0 net/core/stream.c:145
mptcp_sendmsg+0xc39/0x1bc0 net/mptcp/protocol.c:1749
inet6_sendmsg+0x99/0xe0 net/ipv6/af_inet6.c:643
sock_sendmsg_nosec net/socket.c:704 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:724
sock_write_iter+0x2a0/0x3e0 net/socket.c:1057
call_write_iter include/linux/fs.h:2163 [inline]
new_sync_write+0x40b/0x640 fs/read_write.c:507
vfs_write+0x7cf/0xae0 fs/read_write.c:594
ksys_write+0x1ee/0x250 fs/read_write.c:647
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
RIP: 0033:0x4665f9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fd9f866e188 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 000000000056c038 RCX: 00000000004665f9
RDX: 00000000000e7b78 RSI: 0000000020000000 RDI: 0000000000000003
RBP: 00000000004bfcc4 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056c038
R13: 0000000000a9fb1f R14: 00007fd9f866e300 R15: 0000000000022000
Fix the issue rewriting the relevant expression to avoid
sign-related problems - note: size_goal is always >= 0.
Additionally, ensure that the skb in the tx cache always carries
the relevant extension. |
| Net::IMAP implements Internet Message Access Protocol (IMAP) client functionality in Ruby. Prior to versions 0.5.7, 0.4.20, 0.3.9, and 0.2.5, there is a possibility for denial of service by memory exhaustion when net-imap reads server responses. At any time while the client is connected, a malicious server can send can send a "literal" byte count, which is automatically read by the client's receiver thread. The response reader immediately allocates memory for the number of bytes indicated by the server response. This should not be an issue when securely connecting to trusted IMAP servers that are well-behaved. It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname). This issue has been patched in versions 0.5.7, 0.4.20, 0.3.9, and 0.2.5. |
| There is a code-related vulnerability in the GoldenDB database product. Attackers can access system tables to disrupt the normal operation of business SQL. |
| nimiq/core-rs-albatross is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. The `nimiq-network-libp2p` subcrate of nimiq/core-rs-albatross is vulnerable to a Denial of Service (DoS) attack due to uncontrolled memory allocation. Specifically, the implementation of the `Discovery` network message handling allocates a buffer based on a length value provided by the peer, without enforcing an upper bound. Since this length is a `u32`, a peer can trigger allocations of up to 4 GB, potentially leading to memory exhaustion and node crashes. As Discovery messages are regularly exchanged for peer discovery, this vulnerability can be exploited repeatedly. The patch for this vulnerability is formally released as part of v1.1.0. The patch implements a limit to the discovery message size of 1 MB and also resizes the message buffer size incrementally as the data is read. No known workarounds are available. |
| A vulnerability classified as problematic was found in JeecgBoot up to 3.8.0. This vulnerability affects the function unzipFile of the file /jeecg-boot/airag/knowledge/doc/import/zip of the component Document Library Upload. The manipulation of the argument File leads to resource consumption. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. |
| This High severity DoS (Denial of Service) vulnerability was introduced in version 5.6.0 of Confluence Data Center and Server. With a CVSS Score of 7.5, this vulnerability allows an unauthenticated attacker to cause a resource to be unavailable for its intended users by temporarily or indefinitely disrupting services of a vulnerable host (Confluence instance) connected to a network, which has no impact to confidentiality, no impact to integrity, high impact to availability, and requires no user interaction. Atlassian recommends that Confluence Data Center and Server customers upgrade to latest version, if you are unable to do so, upgrade your instance to one of the specified supported fixed versions: Confluence Data Center and Server 7.19: Upgrade to a release greater than or equal to 7.19.14 Confluence Data Center and Server 8.5: Upgrade to a release greater than or equal to 8.5.1 Confluence Data Center and Server 8.6 or above: No need to upgrade, you're already on a patched version See the release notes (https://confluence.atlassian.com/doc/confluence-release-notes-327.html ). You can download the latest version of Confluence Data Center and Server from the download center (https://www.atlassian.com/software/confluence/download-archives ]). This vulnerability was reported via our Bug Bounty program. |
| The Closest Encloser Proof aspect of the DNS protocol (in RFC 5155 when RFC 9276 guidance is skipped) allows remote attackers to cause a denial of service (CPU consumption for SHA-1 computations) via DNSSEC responses in a random subdomain attack, aka the "NSEC3" issue. The RFC 5155 specification implies that an algorithm must perform thousands of iterations of a hash function in certain situations. |
