CVE-2026-78250

bytebot-ai bytebot Agent Execution Workflow infinite loop

A vulnerability was identified in bytebot-ai bytebot 0.0.1. The affected element is an unknown function of the component Agent Execution Workflow. Such manipulation leads to infinite loop. The attack may be performed from remote. The exploit is publicly available and might be used. This vulnerability only affects products that are no longer supported by the maintainer.

CVSS 4.0 · 5.3 Medium EPSS < 1% KEV · Not listed

Vendors

Bytebot-ai

Products

Bytebot

CVE-2026-55588

ORAS CLI: Cyclic Referrer Graph Can Cause Unbounded Recursion and Resource Consumption

ORAS (OCI Registry As Storage) is a CLI and library for managing artifacts in OCI registries. In ORAS CLI versions up to and including 1.3.2, the recursive referrer traversal does not track visited descriptors, so a malicious OCI registry that returns a cyclic referrer graph causes unbounded recursion and memory growth. This affects oras discover, whose recursive traversal is enabled by default because the --depth option defaults to 0 (unlimited), as well as the recursive referrer counting used by the oras backup and oras restore workflows. A cyclic graph can be as simple as A referring to B and B referring back to A. A malicious registry can use this to cause a client-side denial of service, exhausting CPU and memory and hanging automation or CI/CD pipelines that run ORAS against untrusted registry metadata. The vulnerability does not extend to code execution, artifact substitution, or integrity bypass. This issue has been fixed in version 1.3.3.

CVSS 3.1 · 6.5 Medium EPSS < 1% KEV · Not listed

Vendors

—

Products

—

CVE-2026-46385

iskorotkov/avro: CPU Exhaustion in Avro Decoder

iskorotkov/avro is a fast Go Avro codec. Prior to 2.33.0, the Avro array and map decoders looped over an attacker-controlled block-count value without checking the underlying reader's error state inside the loop body. Reader.ReadBlockHeader returns the count as a Go int, which is 64-bit on amd64 / arm64 targets — so a producer can declare a block of up to math.MaxInt64 (~9.2 × 10¹⁸) elements followed by EOF (or any truncated payload), and the decoder will attempt that many no-op iterations before propagating the error. The realistic ceiling is "indefinite until the worker is killed externally" — a single hostile payload pins a CPU core until the process is OOM-killed, deadline-cancelled, or terminated. Remote, unauthenticated denial-of-service. This vulnerability is fixed in 2.33.0.

CVSS 4.0 · 8.7 High EPSS < 1% KEV · Not listed

Vendors

Iskorotkov

Products

Avro

CVE-2026-74655

serial: qcom-geni: fix TX DMA buffer flush

In the Linux kernel, the following vulnerability has been resolved: serial: qcom-geni: fix TX DMA buffer flush When transmit flushing a qcom-geni UART during an ongoing TX DMA, the UART gets stuck infinitely repeating corrupted TX DMA frames. The DMA-mode uart_ops does not provide a flush_buffer callback, so an in-flight transfer can complete after serial core has reset the transmit kfifo, underflowing its length and resubmitting page-sized transfers indefinitely. Add one that stops the transfer and clears tx_remaining and tx_queued. The stop path was also broken: it unmapped the buffer while the serial engine could still read it, and never reset the TX DMA state machine. Cancel the main sequencer command first, then reset the state machine and wait for it before unmapping. Drop the early return so a pending mapping is also cleaned up when the main command is inactive. The bug can be triggered from userspace with a large write immediately followed by TCOFLUSH. A following tcdrain will hang forever. The bug was reproduced and this fix was validated on Arduino Uno Q (QRB2210) using /dev/ttyHS1.

CVSS 3.1 · 8.8 High EPSS < 1% KEV · Not listed

Vendors

Linux

Products

Linux Kernel

CVE-2026-80532

xfs: fix another iunlink infinite loop bug in online fsck

In the Linux kernel, the following vulnerability has been resolved: xfs: fix another iunlink infinite loop bug in online fsck xrep_iunlink_resolve_bucket is supposed to reconstruct as much of the incore prev and next unlinked list pointers based on what it finds on disk and in memory before we move on to relinking the truly lost inodes back into the unlinked list. However, it's still vulnerable to infinite loops that come in via the next_unlinked pointers. Fix this problem by remembering which inodes we've already seen and checking new agino pointers against that. If a bit is already set, either this is a loop or the inode has nonzero link count. We'll deal with the second case in a subsequent patch.

CVSS 3.1 · 5.5 Medium EPSS < 1% KEV · Not listed

Vendors

Linux

Products

Linux Kernel

CVE-2026-77357

Mesop: DoS in /hot-reload endpoint allows unauthenticated attacker to exhaust worker threads and crash the server

Mesop is a Python-based UI framework that allows users to build web applications. Prior to 1.3.3, applications running in debug mode expose a GET /hot-reload endpoint whose unbounded loop depends on the user-supplied counter parameter, allowing an unauthenticated attacker to hold worker threads with high counter values until the worker pool is exhausted and the server becomes unavailable. A single unauthenticated attacker can crash the Mesop server with minimal effort. Because the attack leverages worker exhaustion, the server remains unresponsive until it is manually restarted. This issue is fixed in version 1.3.3.

CVSS 4.0 · 8.7 High EPSS < 1% KEV · Not listed

Vendors

Mesop-dev

Products

Mesop

CVE-2023-4010

kernel: usb: hcd: malformed USB descriptor leads to infinite loop in usb_giveback_urb()

Rejected because the CVE description attributes a vulnerability to a non-existent Linux kernel function (usb_giveback_urb()) and the reported issue cannot be mapped to any valid codebase.

CVSS 3.1 · 4.6 Medium EPSS n/a KEV · Not listed

Vendors

—

Products

—

CVE-2026-16599

Denial of Service in GNU wget

GNU wget is vulnerable to denial of service in its FTP OPIE/S-KEY authentication functionality. The server-supplied sequence number from the FTP challenge line is used as an iteration count for an MD5 key-derivation loop without any upper bound validation. A malicious FTP server or a network attacker positioned to intercept FTP traffic can send a crafted OPIE challenge with a sequence number near INT_MAX, causing wget to perform up to approximately 2.1 billion MD5 computations and suspend for some time. The --timeout option does not mitigate this because it applies only to network I/O, not CPU computation. This issue was fixed in commit e9697d98e7249b0f68a6be040a4f3dcc5bc101fa

CVSS 4.0 · 5.1 Medium EPSS < 1% KEV · Not listed

Vendors

Gnu

Products

Wget

CVE-2026-74593

sched_ext: Take cgroup_lock() first in scx_cgroup_lock()

In the Linux kernel, the following vulnerability has been resolved: sched_ext: Take cgroup_lock() first in scx_cgroup_lock() scx_cgroup_lock() write-locks scx_cgroup_ops_rwsem and then takes cgroup_lock(), which can deadlock through kernfs: scx enable/disable cgroup rmdir cpu.weight write ------------------ ------------ ---------------- cgroup_lock() percpu_down_write(rwsem) cgroup_lock() kernfs_get_active() percpu_down_read(rwsem) kernfs_drain() The enable path waits for the rmdir to release cgroup_mutex. The rmdir, deactivating the cpu controller's files, waits in kernfs_drain() for the write's active reference. The write, in scx_group_set_weight(), waits for the rwsem behind the pending writer. Take cgroup_lock() first. The set_* paths take no cgroup locks inside the read side, so a pending write-lock then only waits for read sections that always run to completion, and no dependency from the rwsem back to cgroup_mutex remains.

CVSS 3.1 · 5.5 Medium EPSS < 1% KEV · Not listed

Vendors

Linux

Products

Linux Kernel

CVE-2026-61556

LiquidJS: An infinite loop vulnerability in `strip_html` filter

LiquidJS is a Shopify / GitHub Pages compatible template engine in pure JavaScript. From 10.26.0 until 10.27.1, the strip_html filter in src/filters/html.ts can enter an infinite loop when an input string contains <, includes at least one preceding character, and has no later >. In strip_html, the search for the next opener advances lt while the loop index remains unchanged when the closer search returns -1, and the equality-only stall guard does not exit because the loop index is less than lt. Reprocessing the same state indefinitely blocks template rendering and can cause denial of service with an input as short as a<. This issue is fixed in version 10.27.1.

CVSS 4.0 · 8.7 High EPSS < 1% KEV · Not listed

Vendors

Harttle

Products

Liquidjs

CVE-2026-45271

picotls has infinite recursion in the minicrypto ASN.1 decoder

Picotls is a TLS protocol library that allows users select different crypto backends based on their use case. Picotls implements its own ASN.1 validation helper, which is used by the minicrypto backend while parsing local PKCS#8 private keys. Prior to commit c14231d801407640bc42c2dcf92783409ea6a7c7, the validator recursively descends into constructed ASN.1 elements without enforcing a maximum nesting depth. If an application loads an attacker-supplied private-key file through ptls_minicrypto_load_private_key(), or otherwise calls the public ASN.1 validation API on untrusted DER, a crafted deeply nested ASN.1 structure can exhaust the process stack and crash the application. Note that the libcrypto (OpenSSL) backend does not use the ASN.1 validation helper of picotls, and therefore is immune to this vulnerability. The vulnerability has been addressed in commit c14231d801407640bc42c2dcf92783409ea6a7c7.

CVSS 3.1 · 5.5 Medium EPSS < 1% KEV · Not listed

Vendors

H20

Products

Picotis

CVE-2026-68280

drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS()

In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS() The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep. This causes the DSI clocks to be disabled twice: once during runtime suspend and again during system suspend, resulting in a WARN message from the clock framework when attempting to disable already-disabled clocks. [ 84.384540] clk:231:5 already disabled [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac ... [ 84.579183] Call trace: [ 84.581624] clk_core_disable+0xa4/0xac [ 84.585457] clk_disable+0x30/0x4c [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi] [ 84.593651] pm_generic_suspend+0x2c/0x44 [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c [ 84.601670] dpm_run_callback+0x8c/0x14c [ 84.605588] __device_suspend+0x1a0/0x56c [ 84.609594] dpm_suspend+0x17c/0x21c [ 84.613165] dpm_suspend_start+0xa0/0xa8 [ 84.617083] suspend_devices_and_enter+0x12c/0x634 [ 84.621872] pm_suspend+0x1fc/0x368 To address this issue, replace UNIVERSAL_DEV_PM_OPS() with RUNTIME_PM_OPS(). Bridge and panel drivers should only deal with runtime PM, as the DRM framework manages system-wide power transitions through the bridge enable() and disable() hooks.

CVSS n/a EPSS < 1% KEV · Not listed

Vendors

Linux

Products

Linux Kernel

CVE-2026-72368

cachefiles: Fix double unlock in nomem_d_alloc error path

In the Linux kernel, the following vulnerability has been resolved: cachefiles: Fix double unlock in nomem_d_alloc error path When start_creating() fails and returns -ENOMEM, it has already released the parent directory lock in __start_dirop(): static struct dentry *__start_dirop(...) { ... inode_lock_nested(dir, I_MUTEX_PARENT); dentry = lookup_one_qstr_excl(name, parent, lookup_flags); if (IS_ERR(dentry)) inode_unlock(dir); <-- Lock released on error return dentry; } However, the nomem_d_alloc error path in cachefiles_get_directory() unconditionally calls inode_unlock(d_inode(dir)) again, causing a double unlock that corrupts the rwsem state. This is a leftover from commit 7ab96df840e60 which replaced manual locking with start_creating() but failed to update the nomem_d_alloc path (while correctly updating mkdir_error and lookup_error paths).

CVSS 3.1 · 7.8 High EPSS < 1% KEV · Not listed

Vendors

Linux

Products

Linux Kernel

CVE-2026-74463

i2c: jz4780: Cache host clock rate at probe to prevent CCF prepare_lock deadlock

In the Linux kernel, the following vulnerability has been resolved: i2c: jz4780: Cache host clock rate at probe to prevent CCF prepare_lock deadlock Fix a severe AB/BA deadlock between the Common Clock Framework (CCF) and the I2C adapter lock, which triggers when an I2C-controlled clock generator client (like the Si5351) is registered or modified under the CCF. During an i2c client clock (generator) frequency change, the CCF acquires its global 'prepare_lock' mutex and the driver calls i2c_transfer() to update the client's chip registers, stalling for the adapter's I2C bus lock. Concurrently, an independent, parallel transfer on the same bus (e.g., a GPIO expander handling LEDs) can hold the I2C adapter lock. Inside this parallel transfer path, jz4780_i2c_set_speed() calls clk_get_rate() on the host controller's input clock to calculate bus timings. This call attempts to acquire the blocked CCF 'prepare_lock', creating a circular dependency that freezes the system. The jz4780 host controller clock itself is static and never changes at runtime. However, calling clk_get_rate() inside the active transfer path introduces an unnecessary dependency on the CCF internal locks. Eliminate this synchronous clk_get_rate() call from the active transfer path by caching the static host peripheral clock rate once - inside the private jz4780_i2c structure during jz4780_i2c_probe(). Update jz4780_i2c_set_speed() to use this cached value, safely decoupling active I2C transactions from the CCF internal locks without any risk of stale timings. Assisted-by web based Google AI (pinpointing the bug and writing the message).

CVSS 3.1 · 5.5 Medium EPSS < 1% KEV · Not listed

Vendors

Linux

Products

Linux Kernel

CVE-2026-74276

spi: xilinx: use FIFO occupancy register to determine buffer size

In the Linux kernel, the following vulnerability has been resolved: spi: xilinx: use FIFO occupancy register to determine buffer size The method the driver uses to determine the size of the FIFO has a problem. What it currently does is this: It stops the SPI hardware and writes to the TX FIFO register until TX FIFO FULL asserts in the status register. But the hardware does not only have the FIFO, it also has a shift register which can hold a byte. This can be seen, when writing a byte to the FIFO (while the SPI hardware is stopped,) the TX FIFO EMPTY is still empty. So, if we have a FIFO size of 16 for example, the current method returns a 17. This is a problem, at least when using the driver in irq mode. The same size determined for the TX FIFO is also assumed for the RX FIFO. When a SPI transaction wants to write the amount of the FIFO size or more bytes, the following happens, for example with 16 bytes FIFO size: The driver stops the SPI hardware and writes 17 bytes to the TX FIFO and starts the SPI hardware and goes sleep. The hardware then shifts out 17 bytes (FIFO + shift register) and simultaneously reads bytes into the RX FIFO, but it only has 16 places, so it looses one byte. Then TX FIFO empty asserts, wakes the driver again, which has a fast path and reads 16 bytes from the RX FIFO, but before reading the last 17th byte (which is lost) it does this: sr = xspi->read_fn(xspi->regs + XSPI_SR_OFFSET); if (!(sr & XSPI_SR_RX_EMPTY_MASK)) { xilinx_spi_rx(xspi); rx_words--; } It reads the status register and checks if the RX FIFO is not empty. But it is empty in our case. So this check spins in a while loop forever locking the driver. This patch fixes the logic to determine the FIFO size.

CVSS 3.1 · 5.5 Medium EPSS < 1% KEV · Not listed

Vendors

Linux

Products

Linux Kernel

CVE-2026-74319

btrfs: zoned: fix deadlock waiting for ticket during data relocation

In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix deadlock waiting for ticket during data relocation When performing data relocation on a zoned filesystem, BTRFS can deadlock in handle_reserve_tickets(). The relocation process is waiting on a space reservation ticket that can never be fulfilled, because the relocation itself is the operation responsible for freeing up that space. Fix this by introducing a new flush state, BTRFS_RESERVE_FLUSH_ZONED_RELOCATION, specifically for data chunk allocation during zoned relocation. Like BTRFS_RESERVE_FLUSH_FREE_SPACE_INODE, this state uses priority_reclaim_data_space() instead of the normal flushing path, which avoids re-entering the relocation code and breaking the deadlock cycle. In btrfs_alloc_data_chunk_ondemand(), select this new flush state when the inode belongs to a data relocation root on a zoned filesystem.

CVSS 3.1 · 5.5 Medium EPSS < 1% KEV · Not listed

Vendors

Linux

Products

Linux Kernel

CVE-2026-74428

rxrpc: Fix double unlock in rxrpc_recvmsg()

In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix double unlock in rxrpc_recvmsg() Fix a double unlock in rxrpc_recvmsg() when dealing with OOB messages.

CVSS 3.1 · 9.8 Critical EPSS < 1% KEV · Not listed

Vendors

Linux

Products

Linux Kernel

CVE-2026-74431

rxrpc: Fix potential infinite loop in rxrpc_recvmsg()

In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix potential infinite loop in rxrpc_recvmsg() Fix the wait in rxrpc_recvmsg() also take check the oob queue.

CVSS 3.1 · 7.5 High EPSS < 1% KEV · Not listed

Vendors

Linux

Products

Linux Kernel

CVE-2026-74437

media: uvcvideo: Fix deadlock if uvc_status_stop is called from async_ctrl.work

In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix deadlock if uvc_status_stop is called from async_ctrl.work If a UVC camera has an asynchronous control, uvc_status_stop may be called from async_ctrl.work: uvc_ctrl_status_event_work() uvc_ctrl_status_event() uvc_ctrl_clear_handle() uvc_pm_put() uvc_status_put() uvc_status_stop() cancel_work_sync() This will cause a deadlock, since cancel_work_sync will wait for uvc_ctrl_status_event_work to complete before returning. Fix this by returning early from uvc_status_stop if we are currently in the work function. flush_status now remains false until uvc_status_start is called again, ensuring that uvc_ctrl_status_event_work won't resubmit the URB.

CVSS 3.1 · 5.5 Medium EPSS < 1% KEV · Not listed

Vendors

Linux

Products

Linux Kernel

CVE-2026-74526

scsi: mpi3mr: Fix potential deadlock in mpi3mr_fault_uevent_emit

In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix potential deadlock in mpi3mr_fault_uevent_emit mpi3mr_fault_uevent_emit() runs from the fault watchdog and reset paths where host I/O may already be blocked. GFP_KERNEL allocations here, both the local kzalloc_obj() and the ones inside kobject_uevent_env() itself, can trigger reclaim that waits on that blocked I/O and deadlock. Use memalloc_noio_save()/restore() to cover the whole call instead of just the local allocation.

CVSS 3.1 · 5.5 Medium EPSS < 1% KEV · Not listed

Vendors

Linux

Products

Linux Kernel