| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An issue was discovered in the file-type package before 16.5.4 and 17.x before 17.1.3 for Node.js. A malformed MKV file could cause the file type detector to get caught in an infinite loop. This would make the application become unresponsive and could be used to cause a DoS attack. |
| ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to 7.1.2-32 and 6.9.13-57, a missing end-of-file check while reading bzip2-compressed image data can cause an infinite loop and exhaust processing resources. This issue is fixed in versions 7.1.2-32 and 6.9.13-57. |
| In Lib/tarfile.py in Python through 3.8.3, an attacker is able to craft a TAR archive leading to an infinite loop when opened by tarfile.open, because _proc_pax lacks header validation. |
| MultipartStream.java in Apache Commons FileUpload before 1.3.1, as used in Apache Tomcat, JBoss Web, and other products, allows remote attackers to cause a denial of service (infinite loop and CPU consumption) via a crafted Content-Type header that bypasses a loop's intended exit conditions. |
| In Progress® Telerik® Document Processing SpreadProcessing library, versions prior to 2026.3.1006, an infinite loop vulnerability exists when importing an XLS file with a specifically-targted corruption, the import timeout is ignored resulting in an unresponsive CPU thread and denial of service. |
| ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to 7.1.2-32 and 6.9.13-57, a crafted PSD file can trigger an integer-conversion error in the PSD decoder on 32-bit builds, causing an infinite loop and denial of service. This issue is fixed in versions 7.1.2-32 and 6.9.13-57. |
| ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to 7.1.2-32 and 6.9.13-57, a crafted XMP profile embedded in an image can cause the profile parser to enter an infinite loop, preventing image processing from completing. This issue is fixed in versions 7.1.2-32 and 6.9.13-57. |
| When migrating a repository from another Gitea instance, Gitea used the page size reported in the source server's API settings to end its paginated downloads. A source that reported `max_response_items` as `0` made these loops run indefinitely and grow server memory until it was exhausted. Any user who can migrate repositories could point a migration at a server they control and cause a denial of service. |
| A flaw was found in m17n-lib. By providing crafted input containing an invalid UTF-8 character sequence, an attacker can cause the text parsing function to enter an infinite loop. This issue leads to sustained high CPU utilization, resulting in a Denial of Service (DoS) for the affected application. |
| In the Linux kernel, the following vulnerability has been resolved:
sched/rt,dl: Skip migrate-disabled tasks when picking a push candidate
A migrate_disable()'d RT task cannot be moved to another CPU, but the
scheduler still keeps such a task on that CPU's pushable list
(rq->rt.pushable_tasks) and still marks the runqueue RT-overloaded
(rq->rt.overloaded = 1). So the RT balancer keeps treating this CPU as
having a task to move away, and keeps trying to move the task, but the
push can never succeed. When the head is pinned, push_rt_task() does not
give up either. It falls back to pushing rq->curr instead, using the
per-CPU stopper, as added by commit a7c81556ec4d ("sched: Fix
migrate_disable() vs rt/dl balancing").
The CPU spends tens of milliseconds in this retry loop. The core is
isolated for real-time work, but during the loop nearly half of its time
is consumed by pushes that cannot succeed.
An ftrace capture of the affected CPU, with sched_switch enabled and
commit 94894c9c477e ("sched/rt: Skip currently executing CPU in
rto_next_cpu()") applied, shows where the CPU time went. Two SCHED_FIFO
tasks at equal priority shared the CPU, taskA migrate_disable()'d and
queued, taskB as rq->curr. In one 89 ms window, taskB got only 52 ms of
CPU. The other 37 ms went to the stopper thread.
The scheduler kept trying to push taskA, the pinned head of the pushable
list, fell back to pushing taskB instead, and woke the stopper 5204
times. Every one of those pushes failed and no task was moved. taskA
stayed runnable and queued the whole time, and never ran.
Pushing taskB fails on a re-check. find_lock_lowest_rq() drops the rq
lock to take the target rq lock, then checks again with
"task != pick_next_pushable_task(rq)".
The task being pushed is taskB, but the pick returns taskA, the head of
the pushable list. taskB is rq->curr, and set_next_task_rt() removes the
running task from that list, so taskB can never be the head. The check
expects a candidate taken from the pushable list, but the fallback
pushes rq->curr, which is never on that list. So the check fails every
time.
.--> push-IPI arrives
| |
| v
| pushable head = taskA -> pinned, cannot be pushed
| |
| v
| so push taskB instead -> wake migration/N, a stop-class
| | thread, so it preempts taskB
| v
| re-check compares taskB against the pushable head,
| which is still taskA -> give up
| |
| v
| nothing moved, taskA still queued, rq still overloaded
| |
'----------'
repeats every ~17 us, 5204 times, for 89 ms
The loop cannot stop itself. Every round leaves the runqueue
exactly as it was, so the next push-IPI does the same thing. In
the capture it ended only when taskB went to sleep on its own.
taskA was then picked locally and left the pushable list.
CPU time per task in the window, from sched_switch:
taskB 51.95 ms real work
migration/N 37.18 ms nothing moved
taskA 0.00 ms queued the whole time, never picked
idle 0.01 ms
Counts over the same window:
7667 push-IPIs handled on this CPU
17481 pick_next_pushable_task() returned taskA, still pinned
5204 find_lock_lowest_rq() gave up on the re-check
1 push that actually completed
0 migrations of taskA
The CPU times and the window length come from the standard
sched_switch tracepoint. The counts needed tracepoints added inside
the RT balancer for this investigation.
The self-IPI path is closed by the rto_next_cpu() fix above, and that
part works. But the runqueue is still marked overloaded, because the
pinned task is still advertised as pushable. Other CPUs now send the
push-IPIs during their own RT balancing, and the same loop runs again.
Closing the self-IPI path did not stop a pinn
---truncated--- |
| ImageSharp is a 2D graphics library. From 2.0.0 until 4.1.2, ExifReader.ReadValues64 trusts the 64-bit BigTIFF IFD entry count and iterates once per declared entry. When fewer than 20 bytes remain, ExifReader.ReadValue64 returns without advancing the stream or terminating the outer loop, so a small malformed BigTIFF can keep one decoder thread executing for an attacker-controlled duration. This report does not claim worker-pool exhaustion. This issue is fixed in version 4.1.2. |
| A flaw was found in sssd. A local user can cause a Denial of Service (DoS) by exhausting the responder service's available file descriptors (system handles used for open connections). By opening and maintaining many concurrent connections to a responder socket while continuing to queue new connection attempts, an attacker can trigger an unthrottled retry loop. This condition leads to high CPU utilization and stalls the service, preventing legitimate identity and authentication requests from being processed. |
| The RabbitMQ Java client library allows Java and JVM-based applications to connect to and interact with RabbitMQ nodes. Prior to 5.37.0, com.rabbitmq.tools.json.JSONReader.read() fails to terminate when input ends inside a quoted string or a line comment because its string and whitespace scanners do not stop at CharacterIterator.DONE. The default DefaultJsonRpcMapper passes JSON-RPC message bodies to this parser for JsonRpcServer and client replies. A truncated string causes the parser to append replacement end markers until heap exhaustion, while a line comment without a terminating newline can keep a thread consuming CPU indefinitely, resulting in denial of service. This issue is fixed in version 5.37.0. |
| USB HID protocol dissector infinite loop and memory leak in 4.6.0 to 4.6.8 and 4.4.0 to 4.4.18 allows denial of service |
| pypdf is a free and open-source pure-python PDF library. Prior to 6.16.0, an attacker can craft a PDF whose cyclic tree structure causes pypdf/generic/_data_structures.py TreeObject.insert_child to follow /Next links indefinitely when a writing code path inserts a child, producing an infinite loop. This issue is fixed in version 6.16.0. |
| pypdf is a free and open-source pure-python PDF library. Prior to 6.18.1, a crafted PDF containing a partially malformed /FlateDecode stream with padded data can force pypdf/filters.py to use inefficient byte-by-byte decompression while the earlier recovery counter fails to advance for bytes that successfully decode, causing long runtimes and application unavailability. This is a residual issue after the malformed FlateDecode recovery fix. This issue is fixed in version 6.18.1. |
| Loop with unreachable exit condition in Pkcs12Store.GetCertificateChain in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows an attacker who can supply a crafted PKCS#12 file to an application that loads it and requests a key entry's certificate chain to cause a denial of service, in which the call never returns and consumes CPU and memory until an OutOfMemoryException, via certificates whose issuer links form a cycle, for example two certificates whose AuthorityKeyIdentifier extensions each identify the other's public key. This happens because the chain-building loop stops only when no issuer is found or a certificate links to itself, and keeps no record of certificates already visited. The key-identifier links are followed without checking signatures. |
| Loop with unreachable exit condition in the PKCS#12 key derivation (Pkcs12ParametersGenerator) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows an attacker who can supply a PKCS#12 (PFX) file, or a PKCS#8 encrypted private key that uses a PKCS#12 password-based encryption algorithm, to cause a denial of service through CPU exhaustion via an iteration count of zero or below, because the derivation loop ran until its counter equalled the count, so for such a count it wrapped through about 2^32 iterations before the MAC or the password could be checked. A 75-byte PFX file with a negative MacData iteration count kept Pkcs12Store.Load busy for many minutes. |
| Loop with unreachable exit condition ('infinite loop') vulnerability in Apache Thrift python bindings.
This issue affects Apache Thrift: before 0.25.0.
Users are recommended to upgrade to version 0.25.0, which fixes the issue. |
| Loop with unreachable exit condition ('infinite loop') vulnerability in Apache Thrift c_glib bindings.
This issue affects Apache Thrift: before 0.25.0.
Users are recommended to upgrade to version 0.25.0, which fixes the issue. |
