Search Results (1906 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2026-98924 1 Linux 2 Linux, Linux Kernel 2026-10-29 4.4 Medium
In the Linux kernel, the following vulnerability has been resolved: fs: avoid repeated scans in evict_inodes() We observed hung tasks when users attempted to unmount a filesystem after its disk had been removed while still in use. During device removal, fs_bdev_mark_dead() calls evict_inodes() while holding s_umount. Each time evict_inodes() drops s_inode_list_lock to reschedule, it restarts the walk from the head of s_inodes. With many referenced inodes at the head of the list, these restarts repeatedly scan the same inodes without reclaiming them. This can keep s_umount held for a long time, blocking concurrent umount attempts and triggering hung-task reports. Keep the current inode, already marked I_FREEING, out of the disposal batch until s_inode_list_lock is reacquired. Resume the walk from this inode and dispose of it in a later batch or at the end of the walk. The zero-refcount and state checks under i_lock allow this walker to claim the inode by setting I_FREEING and removing it from the LRU. Other reclaimers skip the inode, leaving this walker responsible for eviction. Only evict() removes it from s_inodes, so keeping it out of the disposal batch ensures that it remains on the list while the lock is dropped. After reacquiring the lock, reading its current next pointer accounts for concurrent removal of following inodes. The existing inode lifetime rules prohibit acquiring a reference to an inode marked I_FREEING or I_WILL_FREE. __iget() requires its caller to hold i_lock and establish that taking a reference is valid. Inode lookup and igrab() check these flags under i_lock when acquiring a reference from zero. ihold() requires an existing reference, which would keep i_count nonzero and prevent this walker from claiming the inode. These rules already allow iput_final() and the inode shrinker to release i_lock after setting I_FREEING and before eviction completes. A temporary __iget() reference would also keep the inode on the list, but its release must preserve last-reference handling. Another user can acquire a reference, update lazy timestamps and drop its reference while the pin is held. If the pin becomes the last reference, dropping it with atomic_dec_and_test() and evicting directly bypasses iput()'s lazytime handling and can lose those timestamp updates. Releasing the pin with iput() preserves that handling, but does not guarantee eviction. fs_bdev_mark_dead() runs with SB_ACTIVE set, so iput() may retain the inode in cache, whereas evict_inodes() must evict eligible zero-reference inodes. The inode may also have been freed when iput() returns, so the walker cannot then use it to force eviction. Using I_FREEING preserves the existing eviction behavior without introducing an additional last-reference transition. The xfstests auto group passed on ext4 and XFS with known unrelated failures excluded. No new issues were observed, and the previously reproducible hung task no longer occurs with this patch.
CVE-2026-66281 2 Silabs, Silicon Labs 2 Emberznet, Emberznet 2026-10-29 7.5 High
In EmberZNet 9.1.1 and earlier, a malformed Discover Attributes command can result in a loop with unreachable exit condition (infinite loop). These messages must come from a device that has already joined the network. Only devices supporting manufacturer-specific clusters are impacted.
CVE-2026-61791 1 Schorschii 1 Oco-server 2026-10-29 7.4 High
OCO-Server is a self-hosted endpoint management application for computer inventory, software deployment, and mobile device management. Prior to 1.2.1, `Html::commandButton()` in `lib/Html.class.php` embeds an action URL containing a stored computer hostname into a JavaScript string in an inline `onclick` handler, using `htmlspecialchars(ENT_QUOTES)` only for HTML escaping. Browsers decode the HTML entities before interpreting the handler as JavaScript, allowing a crafted hostname to escape the string and execute script in an administrator's authenticated session when an affected command button is activated. `frontend/views/computer-details.php` passes `$computer->hostname` to this helper using `Computer::DEFAULT_COMPUTER_COMMANDS` in `lib/Models/Computer.class.php`, whose VNC, RDP, SSH, and Ping entries use `new_tab=false` and the vulnerable `window.location` branch. A remote attacker who possesses the shared `agent-registration-key` can use the `oco.agent.hello` handler in `frontend/api-agent.php` to store an unchecked hostname when `agent-self-registration-enabled` is enabled; self-registration is disabled by default. The vulnerable default command buttons require no custom command configuration. The injected script can abuse the administrator's privileges, including permission to deploy software jobs to managed computers. This issue is fixed in version 1.2.1.
CVE-2026-103410 1 Juniper 1 Session Smart Router 2026-10-29 7.5 High
An Integer Overflow vulnerability in the DPI certificate scanner in Juniper Networks Session Smart Router allows an unauthenticated remote attacker to cause a denial of service via a specially crafted TLS server certificate.
CVE-2026-111496 1 Apache 1 Kafka 2026-10-28 N/A
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-118384 1 Gnu 1 Mtools 2026-10-28 6.1 Medium
GNU mtools through 4.0.49 has an out-of-bounds write in parse_vses in vfat.c.
CVE-2026-112356 1 Gfi 1 Kerio Connect 2026-10-28 6.1 Medium
GFI KerioConnect (Kerio Connect) before 10.0.9 Patch 2 contains a cross-site scripting vulnerability in the Webmail component that allows a remote attacker to spoof link targets or inject HTML into a message as rendered in a victim's authenticated Webmail session by sending a crafted email whose text is already inside a link. Attackers can exploit the link auto-formatter's re-processing of already-linked text, using quote characters to break out of the href attribute and inject attacker-controlled markup to execute script in the victim's session.
CVE-2026-57186 1 Asterisk 2 Asterisk, Certified Asterisk 2026-10-28 7.5 High
Asterisk is an open source private branch exchange and telephony toolkit. From 21.0.0-pre1 until Asterisk 21.12.3, 22.10.1, 23.4.1 and Certified Asterisk 22.8-cert3, the `chan_ooh323` `Q.931 party-number parser` lacks the `CVE-2022-37325` fix because that fix was never forward-ported from Asterisk 20 to later versions. Malformed Q.931 elements in an `OOH323 request` can therefore crash Asterisk. This issue affects Asterisk versions greater than 20. The `chan_ooh323` addon channel driver must be explicitly compiled and installed, which is not the default, and its port must be publicly reachable. This issue is fixed in Asterisk 21.12.3, 22.10.1, 23.4.1 and Certified Asterisk 22.8-cert3.
CVE-2026-116774 1 Eugeny 1 Russh 2026-10-28 4.3 Medium
russh is a Rust SSH client and server library that includes an SSH agent protocol implementation. From 0.60.0 until 0.65.0, channel-open parsing accepts a peer-declared maximum_packet_size of zero and passes it into ChannelTx::poll_writable in russh/src/channels/io/tx.rs. The Channel::data, Channel::make_writer, and Channel::into_stream asynchronous write paths then calculate a writable size of zero and remain pending forever because window adjustments cannot satisfy a static zero packet maximum. An authenticated client can strand server writes, and a malicious server can strand client writes, allowing affected tasks, channels, and connections to accumulate without surfacing an error. This issue is fixed in version 0.65.0.
CVE-2026-113793 1 Py-pdf 1 Pypdf 2026-10-28 5.5 Medium
pypdf is a free and open-source pure-python PDF library. Prior to 6.20.1, removing an object from a crafted cyclic PDF tree, such as an outline item, can enter an infinite loop and block the current process. This issue is fixed in version 6.20.1.
CVE-2026-112353 2026-10-28 8.2 High
GFI KerioConnect (Kerio Connect) before 10.0.8 Patch 2 contains a stored cross-site scripting vulnerability in the Webmail component that allows a remote attacker to run JavaScript in a victim's authenticated Webmail session by uploading a crafted SVG email attachment that bypasses sanitization of event-handler attributes. Attackers can exploit the temporary-download endpoint's insufficient Content-Security-Policy sandbox to execute scripts when the attachment is opened, enabling theft of the victim's credentials and mailbox contents. Proofpoint Threat Research has observed exploitation in the wild as a credential and mailbox stealer.
CVE-2026-99188 1 Linux 2 Linux, Linux Kernel 2026-10-28 4.1 Medium
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: dwmac1000: clear the RGMII status interrupt Since commit 2e2c878a3141 ("net: stmmac: remove SGMII/RGMII/SMII interrupt handling") nothing on the RGMII path reads GMAC_RGSMIIIS, so RGSMIIIS stays pending behind GMAC_INT_MASK from the first link change on. stmmac_resume() resets the MAC in stmmac_hw_setup(); the reset sets GMAC_INT_MASK to 0 until dwmac1000_core_init() writes the mask again, and the pending status storms the line: dwmac_dma_interrupt: unexpected status 04000000 A register dump at the first message on ODROID-HC4 showed it: core int_status 00000001 int_mask 00000000 pmt 00000000 rgsmiiis 0000000d When the resume thread runs on the CPU that takes the MAC interrupt, the storm starves it: a soft lockup, then a watchdog reset or a hang. Read GMAC_RGSMIIIS in dwmac1000_irq_status() when the status is not masked, as the driver did before 2e2c878a3141; the read clears it. Wake-on-LAN resume from s2idle with the resume thread and the MAC interrupt on one CPU: Helios64 (dwmac-rk), 7.3-rc6, soft-locked in 3 of 3 resumes without a fix and in 0 of 10 with this patch; it ran with an out-of-tree dwmac-rk change that keeps the GMAC powered across suspend. ODROID-HC4 (dwmac-meson8b): 0 of 10 with this patch, 2 of 2 without a fix on a 7.3-rc5 build. irq_rgmii_n went up by one per resume.
CVE-2026-99207 1 Linux 2 Linux, Linux Kernel 2026-10-28 5.6 Medium
In the Linux kernel, the following vulnerability has been resolved: scsi: target: Disable interrupts while holding delayed_cmd_lock target_do_delayed_work() takes dev->delayed_cmd_lock with a plain spin_lock(). It runs from system_percpu_wq, so interrupts stay enabled while the lock is held. Every other acquisition of that lock uses spin_lock_irqsave(): target_handle_task_attr() and transport_complete_ordered_sync() in target_core_transport.c, and target_non_ordered_release() in target_core_device.c. That was safe while every caller of transport_complete_task_attr() ran in process context: target_complete_ok_work() from target_completion_wq, transport_complete_qf() from dev->qf_work_queue, and transport_generic_request_failure() from the submit and execute paths. Since commit 06933066d88a ("scsi: target: Add support for completing commands from backend context") that is no longer true. With complete_type=1 on a fabric that sets direct_compl_supp, target_complete() runs target_complete_ok_work() inline in the backend's completion context, which target_complete_cmd_with_sense() documents as "May be called from interrupt context". For iblock that is the bio end_io. target_complete_ok_work() starts with transport_complete_task_attr(), which takes delayed_cmd_lock in two ways: - Every ORDERED command is put on dev->delayed_cmd_list by target_handle_task_attr() and dispatched from there by target_do_delayed_work(), which marks it SCF_TASK_ORDERED_SYNC. Its completion therefore goes through transport_complete_ordered_sync(). - A SIMPLE command that completes while an ORDERED command is pending drops the last reference to the killed dev->non_ordered, and percpu_ref_put() then runs target_non_ordered_release() in the completing context. Both take the lock and, if commands are waiting, call schedule_work(&dev->delayed_cmd_work), which queues on system_percpu_wq, i.e. on the CPU that took the completion. Further completions for the same queue are typically delivered there too, so one arriving while the work holds the lock spins on it forever. Reaching this needs complete_type=1, which is not the default (vhost-scsi, the only fabric with direct_compl_supp, defaults to TARGET_QUEUE_COMPL), a backend whose I/O completes from interrupt context, and ORDERED commands from the initiator. Linux virtio_scsi guests send only VIRTIO_SCSI_S_SIMPLE and never take the ordered path; any guest that uses the ORDERED task attribute, which vhost-scsi accepts, does. target_do_delayed_work() is a work item and always runs in process context, so spin_lock_irq() is sufficient. Found by inspection; no runtime report. A single ORDERED command goes through both acquisitions, so with CONFIG_PROVE_LOCKING the first one completed through direct completion should produce an inconsistent lock state report on delayed_cmd_lock (hardirq or softirq, depending on where the backend completes).
CVE-2026-118035 1 Progress 1 Telerik Document Processing Libraries 2026-10-28 7.5 High
In Progress® Telerik® Document Processing Libraries prior to version 2026.3.1027, uncontrolled recursion, inefficient algorithmic complexity and infinite loop vulnerabilities in RadWordsProcessing allow an unauthenticated attacker to terminate or hang the host process via a crafted DOCX, DOC, RTF or HTML document.
CVE-2026-118036 1 Progress 1 Telerik Document Processing Libraries 2026-10-28 7.5 High
In Progress® Telerik® Document Processing Libraries prior to version 2026.3.1027, uncontrolled recursion, infinite loop, inefficient algorithmic complexity and resource allocation vulnerabilities in RadPdfProcessing and AI document summarization and question answering allow an unauthenticated attacker to terminate or hang the host process via a crafted PDF document or document text submitted for summarization or question answering.
CVE-2026-118037 1 Progress 1 Telerik Document Processing Libraries 2026-10-28 7.5 High
In Progress® Telerik® Document Processing Libraries prior to version 2026.3.1027, uncontrolled recursion, infinite loop, unchecked loop condition and inefficient regular expression vulnerabilities in RadSpreadProcessing and RadSpreadStreamProcessing allow an unauthenticated attacker to terminate or hang the host process via a crafted XLSX or XLS workbook or formula.
CVE-2026-115911 2 Vllm, Vllm-project 2 Vllm, Vllm 2026-10-28 6.5 Medium
vLLM is an inference and serving engine for large language models. From 0.19.0 until 0.32.0, authenticated callers can supply a request chat template when no server-side --chat-template is configured, or a malicious model repository can provide a template that is compiled and rendered by tokenizer.apply_chat_template() without a wall-clock timeout, output-size limit, or iteration bound. Rendering runs in a ThreadPoolExecutor with one worker by default, so a nonterminating render can block /v1/responses and other chat-template users after the request ends, while an output-expanding render can exhaust server memory. Harmony models are not affected because they do not use this Jinja path. This issue is fixed in version 0.32.0.
CVE-2026-63575 2 Bouncycastle, Legion Of The Bouncy Castle Inc. 2 Bc-csharp, Bc-csharp 2026-10-28 7.5 High
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.
CVE-2026-113650 1 Apostrophecms 2 Apostrophecms, Sanitize-html 2026-10-28 5.3 Medium
ApostropheCMS is an open-source Node.js content management system. In sanitize-html 2.18.0, when an <iframe> is not allowed and disallowedTagsMode is 'discard' (the defaults), its raw-text content is re-sanitized by a recursive call to sanitizeHtml(text, options). The recursion has no bound and starts each nested call with a fresh state. This vulnerability is fixed in 2.18.1.
CVE-2026-63570 2 Bouncycastle, Legion Of The Bouncy Castle Inc. 2 Bc-csharp, Bc-csharp 2026-10-28 7.5 High
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.