WaratekVRT Sign in
Reset
More filters (1)
Columns
Including CVEs outside Waratek scope✕CWE CWE-835✕
Overview 14 matches · 1 in Waratek scope · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
14matches 1in Waratek scope7.1% 0protected0.0% 0exploited0.0% 0CISA KEV0.0% 0public PoC0.0% 0EPSS ≥ 0.50.0%
Protected by Waratek 0 0.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 1 7.1% Outside Waratek scope 0 0.0% Not applicable 13 92.9% Withdrawn CVE 0 0.0%
Critical 14 100.0% High 0 0.0% Medium 0 0.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 0 0.0% partly blocked 0 0.0% not blocked 14 100.0% not established 0 0.0% unrecorded 0 0.0%
Exploited 0 0.0% Working exploit published 0 0.0% Proof of concept only 1 7.1% Forecast only 0 0.0% No public exploit 13 92.9%
split by peak 5 / year
Not applicable: 13No exploit published: 1 Critical: 14 not blocked: 14 No public exploit: 13Proof of concept only: 1
20173 Not applicable3 Critical3 not blocked3 No public exploit3 20180 20192 Not applicable2 Critical2 not blocked2 No public exploit2 20200 20210 20220 20230 20243 Not applicable3 Critical3 not blocked3 Proof of concept only1 No public exploit2 20251 Not applicable1 Critical1 not blocked1 No public exploit1 20265 No exploit published1 Not applicable4 Critical5 not blocked5 No public exploit5
2017201820192020202120222023202420252026
14 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.
CVE Severity Published▾ Status Exploitation Description
CVE-2026-111496 Critical 2026-10-28 No exploit published No public exploit Kafka Streams derives its stream-time clock from record timestamps. PunctuationSchedule.next() computed the next punctuation time as timestamp + (intervalsMissed + 1) * interval with no overflow check. A record with a timestamp at or near Long.MAX_VALUE advances stream time to that value, so the next stream-time punctuation overflows to a negative time. PunctuationQueue then re-queues that time and loops on it indefinitely while holding a lock, stalling the StreamThread. Impact: A single record is enough. The affected StreamThread stops processing, and because the record stays in the topic the hang returns on restart; an application whose partitions are all affected becomes unresponsive. Only the Streams application is affected, not the brokers or the cluster. Triggering it needs write access to a source topic whose topology uses stream-time punctuation, and a broker that stores the record: brokers from Apache Kafka 4.0.0 reject such a timestamp by default (log.message.timestamp.after.max.ms, one hour), so it is reachable only on older brokers or where that bound has been relaxed. Mitigation: Upgrade Kafka Streams to 4.2.2, 4.3.2, or 4.4.0. As defense in depth, keep log.message.timestamp.after.max.ms bounded on source topics and restrict write access to them. Resolution: From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: the next punctuation time is computed with overflow-checked arithmetic (clamped to Long.MAX_VALUE), and a rescheduled punctuation is re-queued only when its time moves forward.
CVE-2026-31448 Critical 2026-04-22 Not applicable No public exploit In the Linux kernel, the following vulnerability has been resolved: ext4: avoid infinite loops caused by residual data On the mkdir/mknod path, when mapping logical blocks to physical blocks, if inserting a new extent into the extent tree fails (in this example, because the file system disabled the huge file feature when marking the inode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to reclaim the physical block without deleting the corresponding data in the extent tree. This causes subsequent mkdir operations to reference the previously reclaimed physical block number again, even though this physical block is already being used by the xattr block. Therefore, a situation arises where both the directory and xattr are using the same buffer head block in memory simultaneously. The above causes ext4_xattr_block_set() to enter an infinite loop about "inserted" and cannot release the inode lock, ultimately leading to the 143s blocking problem mentioned in [1]. If the metadata is corrupted, then trying to remove some extent space can do even more harm. Also in case EXT4_GET_BLOCKS_DELALLOC_RESERVE was passed, remove space wrongly update quota information. Jan Kara suggests distinguishing between two cases: 1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully consistent and we must maintain its consistency including all the accounting. However these errors can happen only early before we've inserted the extent into the extent tree. So current code works correctly for this case. 2) Some other error - this means metadata is corrupted. We should strive to do as few modifications as possible to limit damage. So I'd just skip freeing of allocated blocks. [1] INFO: task syz.0.17:5995 blocked for more than 143 seconds. Call Trace: inode_lock_nested include/linux/fs.h:1073 [inline] __start_dirop fs/namei.c:2923 [inline] start_dirop fs/namei.c:2934 [inline]
CVE-2026-24816 Critical 2026-01-27 Not applicable No public exploit Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in datavane tis (tis-console/src/main/java/com/qlangtech/tis/runtime/module/action modules). This vulnerability is associated with program files ChangeDomainAction.Java. This issue affects tis: before v4.3.0.
CVE-2026-24804 Critical 2026-01-27 Not applicable No public exploit Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in coolsnowwolf lede (package/lean/mt/drivers/mt7603e/src/mt7603_wifi/common modules). This vulnerability is associated with program files bn_lib.C. This issue affects lede: through r25.10.1.
CVE-2026-24803 Critical 2026-01-27 Not applicable No public exploit Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in coolsnowwolf lede (package/lean/mt/drivers/mt7615d/src/mt_wifi/embedded/security modules). This vulnerability is associated with program files bn_lib.C. This issue affects lede: through r25.10.1.
CVE-2025-21850 Critical 2025-03-12 Not applicable No public exploit In the Linux kernel, the following vulnerability has been resolved: nvmet: Fix crash when a namespace is disabled The namespace percpu counter protects pending I/O, and we can only safely diable the namespace once the counter drop to zero. Otherwise we end up with a crash when running blktests/nvme/058 (eg for loop transport): [ 2352.930426] [ T53909] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI [ 2352.930431] [ T53909] KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] [ 2352.930434] [ T53909] CPU: 3 UID: 0 PID: 53909 Comm: kworker/u16:5 Tainted: G W 6.13.0-rc6 #232 [ 2352.930438] [ T53909] Tainted: [W]=WARN [ 2352.930440] [ T53909] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 [ 2352.930443] [ T53909] Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop] [ 2352.930449] [ T53909] RIP: 0010:blkcg_set_ioprio+0x44/0x180 as the queue is already torn down when calling submit_bio(); So we need to init the percpu counter in nvmet_ns_enable(), and wait for it to drop to zero in nvmet_ns_disable() to avoid having I/O pending after the namespace has been disabled.
CVE-2024-43366 Critical 2024-08-15 Not applicable Proof of concept only zkvyper is a Vyper compiler. Starting in version 1.3.12 and prior to version 1.5.3, since LLL IR has no Turing-incompletness restrictions, it is compiled to a loop with a much more late exit condition. It leads to a loss of funds or other unwanted behavior if the loop body contains it. However, more real-life use cases like iterating over an array are not affected. No contracts were affected by this issue, which was fixed in version 1.5.3. Upgrading and redeploying affected contracts is the only way to avoid the vulnerability.
CVE-2024-36288 Critical 2024-06-21 Not applicable No public exploit In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix loop termination condition in gss_free_in_token_pages() The in_token->pages[] array is not NULL terminated. This results in the following KASAN splat: KASAN: maybe wild-memory-access in range [0x04a2013400000008-0x04a201340000000f]
CVE-2021-42143 Critical 2024-01-24 Not applicable No public exploit An issue was discovered in Contiki-NG tinyDTLS through master branch 53a0d97. An infinite loop bug exists during the handling of a ClientHello handshake message. This bug allows remote attackers to cause a denial of service by sending a malformed ClientHello handshake message with an odd length of cipher suites, which triggers an infinite loop (consuming all resources) and a buffer over-read that can disclose sensitive information.
CVE-2019-19307 Critical 2019-11-26 Not applicable No public exploit An integer overflow in parse_mqtt in mongoose.c in Cesanta Mongoose 6.16 allows an attacker to achieve remote DoS (infinite loop), or possibly cause an out-of-bounds write, by sending a crafted MQTT protocol packet.
CVE-2018-20784 Critical 2019-02-22 Not applicable No public exploit In the Linux kernel before 4.20.2, kernel/sched/fair.c mishandles leaf cfs_rq's, which allows attackers to cause a denial of service (infinite loop in update_blocked_averages) or possibly have unspecified other impact by inducing a high load.
CVE-2017-12997 Critical 2017-09-14 Not applicable No public exploit The LLDP parser in tcpdump before 4.9.2 could enter an infinite loop due to a bug in print-lldp.c:lldp_private_8021_print().
CVE-2017-12995 Critical 2017-09-14 Not applicable No public exploit The DNS parser in tcpdump before 4.9.2 could enter an infinite loop due to a bug in print-domain.c:ns_print().
CVE-2017-12990 Critical 2017-09-14 Not applicable No public exploit The ISAKMP parser in tcpdump before 4.9.2 could enter an infinite loop due to bugs in print-isakmp.c, several functions.