Denial of Service

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd)

In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Account for NULL and handle pages in ttm_pool_backup Pages in ttm_pool_backup can be NULL or backup handles (ttm_backup_page_ptr_is_handle()), neither of which can be passed to set_pages_array_wb() or freed. Add a dedicated WB pass before the dma/purge loop that walks allocations using the same i += num_pages stride, skipping NULL and handle entries, and calls set_pages_array_wb() once per contiguous run of real pages. Apply the same NULL/handle guard to the dma/purge loop. Fixes the following oops: Oops: general protection fault, kernel NULL pointer dereference 0x0: 0000 [#1] SMP NOPTI RIP: 0010:__cpa_process_fault+0xf8/0x770 RSP: 0018:ffffc90000a87718 EFLAGS: 00010287 RAX: 0000000000000000 RBX: ffffc90000a87868 RCX: 0000000000000000 RDX: 0000000000001000 RSI: 0005088000000000 RDI: ffffffff827c5f34 RBP: 0005088000000000 R08: ffffc90000a877cb R09: ffffc90000a877d0 R10: 0000000000000000 R11: 000000000000001b R12: 000ffffffffff000 R13: ffffc90000a87868 R14: ffffc90000a87868 R15: ffff88815b882ae0 FS: 0000000000000000(0000) GS:ffff8884ec840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f930b844000 CR3: 000000000262e003 CR4: 0000000008f70ef0 PKRU: 55555554 Call Trace: <TASK> __change_page_attr_set_clr+0x989/0xe90 ? __purge_vmap_area_lazy+0x6c/0x3a0 ? _vm_unmap_aliases+0x250/0x2a0 set_pages_array_wb+0x7f/0x120 ttm_pool_backup+0x4c9/0x5b0 [ttm] ? dma_resv_wait_timeout+0x3b/0xf0 ttm_tt_backup+0x32/0x60 [ttm] ttm_bo_shrink+0x66/0x110 [ttm] xe_bo_shrink_purge+0x12b/0x1b0 [xe] xe_bo_shrink+0xbb/0x270 [xe] __xe_shrinker_walk+0xf7/0x160 [xe] xe_shrinker_walk+0x9d/0xc0 [xe] xe_shrinker_scan+0x11f/0x210 [xe] do_shrink_slab+0x13b/0x270 shrink_slab+0xf1/0x400 shrink_node+0x352/0x8a0 balance_pgdat+0x32c/0x700 kswapd+0x205/0x2f0 ? __pfx_autoremove_wake_function+0x10/0x10 ? __pfx_kswapd+0x10/0x10 kthread+0xd1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x1b1/0x200 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: dce100: skip non-DP stream encoders for DP MST On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST fallback path instead of checking only the link connector signal. Tested on: - GPU: AMD Radeon R7 260X (Bonaire / DCE8) - Board: Supermicro C9X299-PG300 - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot - Kernel: 7.1.3 (issue observed since 6.19) - Result: kernel oops without patch; dual monitors stable with patch (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)

In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.

In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: Fix the error code of devm_kzalloc() in vip_probe_slice() In vip_probe_slice(), the error check for devm_kzalloc() incorrectly uses PTR_ERR_OR_ZERO() which returns 0 for NULL pointer. Return -ENOMEM for devm_kzalloc() failure.

In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: if (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && bss_desc->bcn_ht_cap && ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 ("wifi: mt76: connac: do not check WED status for non-mmio devices").

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7921_rx_check() and mt7921_queue_rx_skb() dispatch it to mt7921_mac_tx_free() on every bus. mt7921_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB and SDIO it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7921_mac_tx_free+0x64/0x310 [mt7921_common] mt7921_rx_check+0x5f/0xf0 [mt7921_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 ("wifi: mt76: connac: do not check WED status for non-mmio devices").

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7925_rx_check() and mt7925_queue_rx_skb() dispatch it to mt7925_mac_tx_free() on every bus. mt7925_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7925_mac_tx_free+0x58/0x350 [mt7925_common] mt7925_rx_check+0xe2/0x130 [mt7925_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 ("wifi: mt76: connac: do not check WED status for non-mmio devices").

In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix NULL pointer dereference in rhash table destroy When unbinding the ath12k driver, kernel NULL pointer dereferences occur in irq_work_sync() called from rhashtable_destroy(). Two hash tables are affected: 1. ath12k_link_sta hash table in ath12k_base 2. ath12k_dp_link_peer hash table in ath12k_dp The issue happens because the destroy functions are called unconditionally in cleanup paths, but the hash tables are only initialized late in their respective init functions. If the device was never fully started or if the init functions failed before initializing the hash tables, the pointers will be NULL. The issues are always reproducible from a VM because the MSI addressing initialization is failing. Call trace for ath12k_link_sta_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_link_sta_rhash_tbl_destroy+0x19/0x40 [ath12k] ath12k_core_stop+0xe/0x80 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Call trace for ath12k_dp_link_peer_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_dp_link_peer_rhash_tbl_destroy+0x29/0x50 [ath12k] ath12k_dp_cmn_device_deinit+0x21/0x140 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Fix this by adding NULL checks before calling rhashtable_destroy() in both destroy functions. The NULL check approach was chosen because the rhashtable pointer serves as the initialization state indicator. The init can fail at various points, leaving some components uninitialized. Checking the pointer directly is simpler than adding separate state flags that would need synchronization.

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Use sender devcom for MPV master-up After PCIe DPC recovery, mlx5 reloads the affected functions and replays multiport affiliation events. In the reported failure, the first relevant device error was: pcieport 0000:10:01.1: DPC: containment event pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal) pcieport 0000:10:01.1: [ 5] SDES (First) mlx5 recovered the PCI functions and resumed 0000:11:00.1. During that resume, RDMA multiport binding replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent MPV_DEVCOM_MASTER_UP. The host then panicked with: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] RDI: 0000000000000000 Call trace included: mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume MPV devcom registration publishes mlx5e private data to the component peer list before mlx5e_devcom_init_mpv() stores the returned component device in priv->devcom. A concurrent master-up event can therefore reach a peer whose private data is visible but whose priv->devcom backpointer is still NULL. MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private data as event_data. The ready bit is stored on the shared devcom component, not on an individual peer. Use the sender devcom when marking the MPV component ready. This preserves the readiness transition while avoiding a NULL dereference of the peer devcom pointer during affiliation replay after PCI error recovery.

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit e4d99e04b2e9b13b97d3b17804c735f62689db23)

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit f952076f76d62f783e8ba4995a7c400d39354ccf)

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c)

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit fa4f86a148271e325e95287630a3a15a9cd35fdc)

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c4f230b51cf2d3e7e8b1c800331f3dbed2a9e3f5)

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix kernel panic during driver load failure Avoid kernel panic if MES init fails during driver load. The KIQ ring is falsely marked as ready as ASICs that use MES, KIQ is owned by MES. BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:gfx_v12_1_wait_reg_mem+0x5a/0x1f0 [amdgpu] Call Trace: gfx_v12_1_ring_emit_reg_write_reg_wait+0x1f/0x30 [amdgpu] amdgpu_gmc_fw_reg_write_reg_wait+0xb2/0x190 [amdgpu] amdgpu_gmc_flush_gpu_tlb+0x1cc/0x230 [amdgpu] amdgpu_gart_invalidate_tlb+0x81/0xa0 [amdgpu] amdgpu_gart_unbind+0x72/0x90 [amdgpu] amdgpu_ttm_backend_unbind+0xa4/0xb0 [amdgpu] amdgpu_ttm_tt_unpopulate+0x13/0xd0 [amdgpu] amdttm_tt_unpopulate+0x29/0x70 [amdttm] ttm_bo_put+0x1eb/0x360 [amdttm] amdgpu_bo_free_kernel+0xf9/0x1f0 [amdgpu] amdgpu_ih_ring_fini+0x5a/0x90 [amdgpu] amdgpu_irq_fini_hw+0x58/0x80 [amdgpu] amdgpu_device_fini_hw+0x4e0/0x5b0 [amdgpu] amdgpu_driver_load_kms+0x60/0xa0 [amdgpu] amdgpu_pci_probe+0x28e/0x6d0 [amdgpu] pci_device_probe+0x19f/0x220 really_probe+0x1ed/0x340 driver_probe_device+0x1e/0x80 __driver_attach+0xd3/0x1a0 bus_for_each_dev+0x68/0xa0 bus_add_driver+0x19f/0x270 driver_register+0x5d/0xf0 do_one_initcall+0xac/0x200 do_init_module+0x1ec/0x280 __se_sys_finit_module+0x2de/0x310 do_syscall_64+0x6a/0x250 entry_SYSCALL_64_after_hwframe+0x4b/0x53 (cherry picked from commit 4623b958dd6da0f4c3026afdf330626a09ecb0f0)

In the Linux kernel, the following vulnerability has been resolved: sched_ext: Preserve rq tracking across local DSQ dispatch dispatch_to_local_dsq() can run from scx_bpf_dsq_move_to_local() while ops.dispatch() has recorded the current rq. Moving a task to a local DSQ may switch to the source or destination rq before synchronously invoking ops.dequeue() through the following path: SCX_CALL_OP(dispatch, rq) ops.dispatch() scx_bpf_dsq_move_to_local() scx_flush_dispatch_buf() finish_dispatch() dispatch_to_local_dsq() scx_dispatch_enqueue() local_dsq_post_enq() call_task_dequeue() SCX_CALL_OP_TASK(dequeue, locked_rq, ...) The nested callback saves the recorded rq and restores it on return. If the rq tracking does not follow the lock switch, update_locked_rq() can trigger the following lockdep assertion while restoring an rq which is no longer held: WARNING: kernel/sched/sched.h:1641 at call_task_dequeue+0x160/0x170 Call Trace: scx_dispatch_enqueue+0x2b0/0x460 dispatch_to_local_dsq+0x138/0x230 scx_flush_dispatch_buf+0x1af/0x220 scx_bpf_dsq_move_to_local___v2+0xe2/0x1c0 bpf__sched_ext_ops_dispatch+0x4b/0xa7 do_pick_task_scx+0x3b6/0x910 __pick_next_task+0x105/0x1f0 __schedule+0x3e7/0x1980 Introduce switch_rq_lock() to update the tracking state together with each rq lock handoff. Use it in dispatch_to_local_dsq(), move_remote_task_to_local_dsq() and the in-balance paths of scx_dsq_move(), ensuring that scx_locked_rq() consistently refers to the rq whose lock is actually held throughout the lock dance.

In the Linux kernel, the following vulnerability has been resolved: debugobjects: Plug race against a concurrent OOM disable syzbot reported a puzzling splat: WARNING: kernel/time/hrtimer.c:443 at stub_timer+0xa/0x20 stub_timer() is installed as timer callback function in hrtimer_fixup_assert_init(), which is invoked when debug_object_assert_init() can't find a shadow object. In that case debug objects emits a warning about it before invoking the fixup. Though the provided console log lacks this warning and instead has the following a few seconds before the splat: ODEBUG: Out of memory. ODEBUG disabled So the object was looked up in debug_object_assert_init() and the lookup failed due a concurrent out of memory situation which disabled debug objects and freed the shadow objects: debug_object_assert_init() if (!debug_objects_enabled) return; obj = alloc(); if (!obj) { // Out of memory debug_objects_enabled = false; free_objects(); obj = lookup_or_alloc(); // The lookup failed because the other side // removed the objects, so this returns // an error code as the object in question // is not statically initialized if (!IS_ERR_OR_NULL(obj)) return; if (!obj) { debug_oom(); return; } print(...) if (!debug_objects_enabled) return; fixup(...) The debug object splat is skipped because debug_objects_enabled is false, but the fixup callback is invoked unconditionally, which makes the timer disfunctional. This is only a problem in debug_object_assert_init() and debug_object_activate() as both have to handle statically initialized objects and therefore must handle the error pointer return case gracefully. All other places only handle the found/not found case and the NULL pointer return is a signal for OOM. Otherwise they get a valid shadow object. Plug the hole by checking whether debug objects are still enabled before invoking the print and fixup function in those two places.

Signed integer overflow in GIMP's file-fli plugin causes application crashes when processing maliciously crafted FLI animation files, resulting in denial of service. The flaw affects GIMP as packaged on Red Hat Enterprise Linux 6 through 9, where incorrect multiplication of image width and height during buffer size calculation can overflow a signed integer, producing an invalid allocation. No public exploit code or active exploitation has been identified; impact is strictly limited to availability, with no confidentiality or integrity consequences.

Stack overflow in GNU cpio's make_path function (src/makepath.c) causes a denial of service when a victim extracts a crafted archive. The function uses alloca() to allocate stack memory sized by an attacker-controlled pathname embedded in the archive, allowing unbounded stack growth and a process crash with no confidentiality or integrity impact. No active exploitation or public proof-of-concept has been identified at time of analysis; the upstream fix is available as a single commit.

Unbounded memory allocation in Keras (keras-team/keras) versions ≤ 3.15.0 allows an attacker who can supply a crafted .keras or HDF5 weights file to crash the loading process via an out-of-memory condition. The H5IOStore.__getitem__ method in keras/src/saving/saving_lib.py performs no validation of HDF5 dataset shapes against actual on-disk storage, enabling 'shape bomb' files that declare enormous in-memory sizes (e.g., ~8 PiB) while occupying negligible disk space. ML pipelines that consume models from public repositories, third-party registries, or untrusted collaborators are directly at risk; this flaw bypasses the earlier fix for CVE-2026-0897, which only addressed the same class of issue in KerasFileEditor. No public exploit has been identified at time of analysis and the vulnerability is not listed in the CISA KEV catalog.

Infinite-loop denial-of-service in libexpat before 2.8.3 allows attackers supplying crafted UTF-16 XML to hang the parsing process indefinitely via a low Unicode surrogate handled as a high surrogate in the *_toUtf16 functions. The flaw is gated by a compile-time prerequisite - only builds configured with XML_UNICODE and XML_UNICODE_WCHAR_T are vulnerable - which specifically includes Firefox and Windows-native builds of applications embedding libexpat. A concrete attack payload is publicly available in the upstream patch PR test suite; no active exploitation has been confirmed via CISA KEV at time of analysis.

Heap out-of-bounds reads and writes in Perl's regular expression engine through version 5.45.1 arise from a signed 32-bit integer overflow when computing the superlinear cache size in S_regmatch. When a subject string of approximately 286,331,153 bytes is matched against a pattern containing 15 or more WHILEM-participating nodes, the bit-count product overflows to 14, producing a two-byte cache allocation that is then indexed far beyond its bounds. A caller passing attacker-controlled input of this size to such a pattern can crash the Perl process or corrupt heap memory; no public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV.

Denial of service in lmammino oidc-authorizer 0.4.0 can be triggered remotely by submitting a crafted value for the authorization_token argument processed by the parse_token_from_header function in the Authorization Header Parsing component. Any service using this Rust library to validate OIDC tokens via the HTTP Authorization header is exposed to availability disruption without requiring authentication. A public proof-of-concept exploit has been disclosed, though the vulnerability is not confirmed as actively exploited in CISA KEV.

Use-after-free in Zephyr RTOS kernel queue peek operations (z_impl_k_queue_peek_head and z_impl_k_queue_peek_tail in kernel/queue.c) allows a local low-privileged thread to obtain a dangling pointer to freed heap memory by winning a race against a concurrent k_queue_get call on a shared queue. Successful exploitation - requiring SMP or preemptive concurrency - can leak a stale heap pointer or crash the system when the returned dangling pointer is subsequently consumed as a live buffer in the net_buf, Bluetooth, USB, or networking subsystems. No public exploit exists and no active exploitation is confirmed; CVSS scores this at 3.6 (Low), accurately reflecting the narrow race window and local-only attack surface.

Log flooding via unbounded username input in JupyterHub's form-based login handler allows unauthenticated remote attackers to exhaust logging and disk storage resources on multi-user Jupyter notebook servers running versions prior to 5.5.0. The root cause (CWE-400) is that failed login attempts wrote the full attacker-supplied username - with no length cap - directly into application logs across three distinct code paths: the base login handler, the login POST handler, and the PAM authenticator. No public exploit code has been identified at the time of analysis, and this vulnerability is not listed in the CISA KEV catalog.

Denial-of-service in the TP-Link Archer A6 V4 router's embedded web server allows an authenticated, adjacent-network attacker to crash the httpd process or the device by sending a malformed request to the HTTP-WRITEOEM handler, which fails to validate input before passing it to flash-write logic. All Archer A6 V4 firmware versions prior to V4_1.15.10 Build 260625 Rel.25447 are affected, per EUVD-2026-54656 and TP-Link's own advisory. No public exploit code or active exploitation has been identified at time of analysis.

Denial-of-service in the TP-Link Archer A6 v4 httpd service allows an adjacent, authenticated attacker to crash the web management process or force a device reboot by exploiting a race condition in the asynchronous systool instruction handling path. All firmware builds prior to V4_1.15.10 Build 260625 Rel.25447 are affected; a vendor-released patch has been issued. No public exploit code exists and the vulnerability is not listed in the CISA KEV catalog - real-world risk is constrained by the adjacent network and high-privilege prerequisites.

Uncontrolled memory consumption in pypdf's /ToUnicode CMap parser allows a remote attacker to cause denial of service by supplying a crafted PDF containing font entries with abnormally large bfrange code or string tokens. All pypdf versions prior to 6.15.0 are affected when performing text extraction operations. No public exploit or active exploitation is identified, but the fix is straightforward and the attack requires only the ability to supply a PDF to an application using the library.

Uncontrolled memory consumption in HashiCorp Consul's agent HTTP API endpoints allows unauthenticated remote callers to force the agent to allocate substantial memory before a request is finally rejected. Both Community Edition and Enterprise versions 1.3.0 through 2.0.2 are affected, covering a multi-year release window. No public exploit has been identified and the vulnerability is absent from CISA KEV, but the zero-authentication, low-complexity network attack path makes it straightforward to trigger for any attacker with network access to the Consul agent API port.

Uncontrolled cache growth in HashiCorp Consul's Connect CA roots endpoint allows unauthenticated remote callers to expand the agent's Connect CA roots cache indefinitely, overriding any operator-applied cache-disable configuration. Both Consul Community Edition and Consul Enterprise are affected from version 1.2.0 through 2.0.2. No public exploit code or active exploitation (CISA KEV) has been identified; the CVSS 5.3 Medium rating reflects limited availability impact with no confidentiality or integrity exposure.

Uncontrolled resource consumption in HashiCorp Consul and Consul Enterprise 1.17.0 through 2.0.2 allows authenticated network callers to unboundedly inflate the Consul agent's intention-match cache via the Connect authorization endpoint, defeating explicitly configured cache-disable operator settings. This CWE-770 flaw degrades service mesh authorization availability and undermines a deliberate operational control. No public exploit code or active exploitation has been identified; HashiCorp has released patches across all affected release lines.

Authenticated denial of service in HashiCorp Consul Community Edition and Consul Enterprise 1.18.0-2.0.2 allows a network attacker holding config-entry write permission to crash the Consul server agent by submitting a crafted service-router configuration entry. The flaw is rooted in a null pointer dereference (CWE-476) triggered along the Enterprise-to-Community Edition downgrade code path, meaning only deployments undergoing or having undergone that transition are exploitable. No public exploit code or active exploitation confirmed by CISA KEV has been identified; vendor-released patches are available and confirmed in Consul 2.0.3 and Consul Enterprise 1.21.17, 1.22.11, and 2.0.3.

Denial-of-service via spoofed broadcast control frames over radio frequency can simultaneously disconnect multiple aircraft from air traffic control datalink communications, causing controller overload and delayed clearances. The vulnerability is classified ICS-critical and reported through CISA ICS-CERT (ICSA-26-219-01), indicating a fielded aviation infrastructure component is affected. No public exploit code has been identified at time of analysis, though the attack is described as remotely executable over RF with low privilege requirements, making it a meaningful operational risk at any airport deploying the affected system.

Session termination via injected radio frames threatens Controller-Pilot Data Link Communications (CPDLC), a safety-critical aviation channel used globally between aircraft and air traffic control for ATC clearances, weather, and route updates. Remotely transmitted Unnumbered Disconnect (U DISC) frames or malformed Aviation VHF Link Control (AVLC) frames over VHF radio can forcibly collapse active CPDLC sessions, forcing reversion to voice communication and degrading controller throughput in high-traffic airspace. No public exploit code has been identified at time of analysis; however, the ICS-CERT advisory ICSA-26-219-01 confirms the vulnerability and the aviation safety context elevates operational priority well beyond what the numeric CVSS score alone suggests.

Quadratic-complexity denial of service in Hono's `languageDetector` middleware (versions 4.12.0-4.12.33) allows unauthenticated remote attackers to exhaust CPU resources by sending HTTP requests with crafted language tags containing large numbers of hyphen-separated subtags. The default middleware configuration accepts language values from query parameters, cookies, and the Accept-Language header without authentication, meaning the vulnerable code path is reachable from the network in any default Hono deployment using this middleware. No public exploit code has been identified and this CVE is not in the CISA KEV catalog, but the attack is trivially constructible from the advisory description; the fix was released in version 4.12.34.

Remote denial-of-service in @sveltejs/kit (versions ≤ 2.70.1) is achievable by any unauthenticated attacker who sends a specially crafted Accept header, triggering quadratic backtracking in the framework's content negotiation regex and causing excessive CPU consumption. The CVSS vector (AV:N/AC:L/PR:N/UI:N) confirms zero-barrier remote exploitation against default SvelteKit deployments, though real-world impact is partly mitigated where platform-level header length limits are in place. No public exploit code has been identified at time of analysis, and this vulnerability is not listed in CISA KEV.

Integer overflow in p11-kit's RPC message parser on 32-bit systems allows a local attacker, or any principal with access to a reachable RPC channel, to crash the p11-kit process via a heap out-of-bounds write, resulting in Denial of Service. Affected deployments span Red Hat Enterprise Linux 6 through 10, Red Hat Hardened Images, and OpenShift Container Platform 4. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.

Denial of Service in the WP Maps WordPress plugin before 4.9.7 allows any authenticated subscriber to exhaust server resources by exploiting a missing capability check in an AJAX action handler. The flaw, discovered and reported by WPScan, permits a low-privileged user to invoke an unrestricted operation that triggers uncontrolled recursion, potentially rendering the affected WordPress site unavailable. A publicly available proof-of-concept exists, though EPSS remains low (0.14%) and CISA has not listed this in KEV, suggesting exploitation is currently opportunistic rather than widespread.

Kernel null pointer dereference in Imagination Technologies Graphics DDK allows a local non-privileged user to crash the host system via crafted GPU system calls. Multiple release branches are affected, including DDK 26.1 RTM1, 25.1-25.3 RTM, 24.2 RTM2, 23.2 RTM2, and 1.18 RTM2. An attacker with a local shell account on a device running the affected kernel driver can trigger platform instability or a full denial of service - no exploit has been publicly identified at time of analysis, and EPSS probability is extremely low at 0.15% (5th percentile).

Resource exhaustion in the sol MQTT broker (commit 373d848, 2024-12-12) allows unauthenticated remote attackers to cause a denial of service by flooding the service with malformed or duplicate CONNECT packets. The broker's session teardown logic is incomplete: failed or repeated CONNECT attempts silently drop the connection without releasing internal state, leaving memory and file descriptors allocated indefinitely. With no authentication required and the attack confirmed automatable per SSVC, a sustained flood of crafted CONNECT packets can exhaust system resources and trigger the Linux OOM killer. No public exploit code was formally released as a tool, but a POC is referenced in the linked GitHub advisory; the vulnerability has not been added to the CISA KEV catalog.

Out-of-Bounds Read in Autodesk's image handling library crashes Revit and AutoCAD when a user opens a maliciously crafted TIF file during image import. Affected products span Revit 2024, 2026, and 2027 as well as AutoCAD and AutoCAD LT 2027, all below vendor-specified fix versions. The attack is local and requires user interaction, limiting automated mass exploitation, but remains a viable denial-of-service vector in targeted scenarios against AEC professionals who routinely handle externally sourced CAD assets. No public exploit identified at time of analysis.

Null pointer dereference in the llama.cpp LLaMA-Android JNI wrapper's bench_1model() function allows denial of service via a crafted model file. Builds b1886 through b7445 (packaged releases 0.9.0-0.17.1) are affected; the function skips null validation on the model context pointer before dereferencing it, so supplying a malformed or truncated GGUF model file triggers a SIGSEGV that terminates the Android application process. No public exploit has been identified at time of analysis and this is not listed in CISA KEV, but the attack path is mechanically simple for anyone able to deliver a crafted model to the device.

Rate-limiting in OpenReception's appointment booking software prior to version 1.0.6 is defeated by two compounding weaknesses: a SHA-256 proof-of-work configured at only 16 bits of difficulty (solvable in under 200ms on modern hardware) and a per-binding throttle service whose key is derived entirely from attacker-controlled parameters. Remote unauthenticated attackers can automate high-volume requests to the `/api/tenants/{id}/appointments/bootstrap-challenge` endpoint - rotating fresh `tunnelId` and `clientPublicKey` values each attempt to generate a new throttle namespace - bypassing both controls and flooding the patient appointment booking flow. No public exploit code has been identified at time of analysis, and this vulnerability does not appear in the CISA KEV catalog.

Cross-tenant PIN challenge throttle isolation failure in OpenReception appointment booking software (prior to 1.0.4) allows unauthenticated remote attackers to lock out a patient on any tenant by submitting failed PIN responses against a different tenant on the same platform instance. The root cause is that the `challenge_throttle` table is keyed solely by `emailHash` with no tenant dimension, so throttle state bleeds across tenant boundaries. Lockout escalates from 60 seconds to 60 minutes after repeated failure bursts. No public exploit has been identified at time of analysis, and a vendor patch is available in version 1.0.4.

Use-after-free in MZ Automation libiec61850 up to version 1.6.1 allows a local low-privileged attacker to corrupt memory through the URCB (Unbuffered Report Control Block) dataset shadow buffer deletion path. The vulnerability exists in `deleteDataSetValuesShadowBuffer` within `reporting.c`, where the function dereferenced `self->dataSet` to compute its size after that pointer could already have been freed or set to NULL during connection teardown. A publicly available proof-of-concept exists, though no active exploitation has been confirmed via CISA KEV. The fix, released in v1.6.2 (commit 486fd57f), stores buffer size independently and adds semaphore locking to prevent the race.

Process-terminating denial of service in node-re2 (npm package `re2`) up to and including v1.25.0 allows an attacker to kill the entire Node.js process or worker thread with a single crafted request. The native add-on's `WrappedRE2::Replace` calls `.ToLocalChecked()` on a V8 `MaybeLocal` without first verifying it is non-empty; when a global replace uses the `$'` (post-match) or `` $` `` (pre-match) template on ~40,000+ matching characters, the O(input²) output exceeds V8's 536,870,888-character limit, the `MaybeLocal` is empty, and the unchecked call triggers `v8::Utils::ReportApiFailure` → native `abort()` (SIGABRT, exit 134). Unlike the built-in regex engine, which raises a catchable `RangeError`, this crash cannot be intercepted by JavaScript `try/catch`, domains, or `uncaughtException` handlers, making a single malformed request capable of taking down the entire service. A public proof-of-concept is included in the GitHub Security Advisory; no CISA KEV listing was present at time of analysis.

Prototype pollution in Mermaid's architecture-beta diagram renderer (mermaid@11.5.0 through 11.16.0) allows an untrusted diagram author to write the string 'horizontal' or 'vertical' directly onto Object.prototype by supplying '__proto__' as a valid group parent identifier. All JavaScript code sharing the same runtime realm that reads or enumerates the injected property name may observe corrupted option defaults, bypassed truthiness checks, or denial-of-service conditions in the embedding application. A public proof-of-concept is included in the advisory; direct remote code execution is not achievable because the injectable value is constrained to those two strings, ruling out function or object injection.

Infinite-loop denial of service in Mermaid's XY chart renderer allows any party that can supply diagram input to crash the JavaScript process or browser tab. The `setXAxisRangeData()` function in npm/mermaid enters an unbounded loop when an x-axis range is defined with identical start and end values, growing an array until memory is exhausted or a `RangeError: Invalid array length` is thrown. A proof-of-concept is publicly embedded in the GitHub security advisory (GHSA-2v8p-3f2j-5mp7), making exploitation trivial; no CISA KEV listing has been issued.

In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest mode When updating CR8 intercepts, get vmcs12 if and only if the vCPU is in guest mode so that a future change can have update CR8 intercepts during vCPU creation, without running afoul of get_vmcs12()'s lockdep assertion. ------------[ cut here ]------------ debug_locks && !(lock_is_held(&(&vcpu->mutex)->dep_map) || !refcount_read(&vcpu->kvm->users_count)) WARNING: arch/x86/kvm/vmx/nested.h:61 at get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline], CPU#0: syz.2.19/5879 WARNING: arch/x86/kvm/vmx/nested.h:61 at vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879, CPU#0: syz.2.19/5879 Modules linked in: CPU: 0 UID: 0 PID: 5879 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline] RIP: 0010:vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879 Call Trace: <TASK> apic_update_ppr arch/x86/kvm/lapic.c:984 [inline] kvm_lapic_reset+0x1c24/0x2980 arch/x86/kvm/lapic.c:3023 kvm_vcpu_reset+0x44c/0x1bf0 arch/x86/kvm/x86.c:12986 kvm_arch_vcpu_create+0x746/0x8b0 arch/x86/kvm/x86.c:12847 kvm_vm_ioctl_create_vcpu+0x428/0x930 virt/kvm/kvm_main.c:4201 kvm_vm_ioctl+0x893/0xd50 virt/kvm/kvm_main.c:5159 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> No functional change intended.

In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel-hid: Protect ACPI notify handler against recursion Since commit e2ffcda16290 ("ACPI: OSL: Allow Notify () handlers to run on all CPUs") ACPI notify handlers like the intel-hid notify_handler() may run on multiple CPU cores racing with themselves. On convertibles and detachables (matched by DMI chassis-type 31 and 32 in dmi_auto_add_switch[]) the SW_TABLET_MODE input device is registered lazily from notify_handler() on the first tablet-mode event, via intel_hid_switches_setup(). When two such events race on different CPUs both can pass the !priv->switches check and register the priv->switches input device twice, resulting in a duplicate sysfs entry and a subsequent NULL pointer dereference. This is the same class of bug fixed by commit e075c3b13a0a ("platform/x86: intel-vbtn: Protect ACPI notify handler against recursion") for the sibling intel-vbtn driver. Protect intel-hid notify_handler() from racing with itself with a mutex to fix this.

In the Linux kernel, the following vulnerability has been resolved: libfs: set SB_I_NOEXEC and SB_I_NODEV by default in init_pseudo() Since commit 1e7ab6f67824 ("anon_inode: rework assertions"), path_noexec() warns when an anonymous-inode file is mmap'd from a superblock that has not set SB_I_NOEXEC. dma-buf backs its files this way and never set the flag, so mmap of any exported buffer trips the warning on a CONFIG_DEBUG_VFS=y kernel: WARNING: CPU: 11 PID: 121813 at fs/exec.c:118 path_noexec+0x47/0x50 do_mmap+0x2b5/0x680 vm_mmap_pgoff+0x129/0x210 ksys_mmap_pgoff+0x177/0x240 __x64_sys_mmap+0x33/0x70 init_pseudo() sets up internal SB_NOUSER mounts that are never path-reachable. Set both flags here so every pseudo filesystem gets them by default instead of each caller setting them. SB_I_NODEV is inert for unreachable mounts. SB_I_NOEXEC has one visible effect: an executable mapping of a pseudo-fs fd, such as a dma-buf, now fails with -EPERM, which is the invariant the assertion enforces. No in-tree caller maps these executable. Reproduce on CONFIG_DEBUG_VFS=y: make -C tools/testing/selftests/dmabuf-heaps sudo ./tools/testing/selftests/dmabuf-heaps/dmabuf-heap -t system

In the Linux kernel, the following vulnerability has been resolved: btrfs: do not trim a device which is not writeable [BUG] There is a bug report that btrfs/242 can randomly fail with the following NULL pointer dereference: run fstests btrfs/242 at 2026-06-01 10:25:08 BTRFS: device fsid d4d7f234-487c-4787-88e4-47a8b68c9874 devid 1 transid 9 /dev/sdc (8:32) scanned by mount (122609) BTRFS info (device sdc): first mount of filesystem d4d7f234-487c-4787-88e4-47a8b68c9874 BTRFS info (device sdc): using crc32c checksum algorithm BTRFS warning (device sdc): devid 2 uuid fbe72d72-3272-482d-80fb-ab88ed398192 is missing BTRFS warning (device sdc): devid 2 uuid fbe72d72-3272-482d-80fb-ab88ed398192 is missing BTRFS info (device sdc): allowing degraded mounts BTRFS info (device sdc): turning on async discard BTRFS info (device sdc): enabling free space tree Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 user pgtable: 4k pages, 48-bit VAs, pgdp=000000013fd6b000 CPU: 4 UID: 0 PID: 122625 Comm: fstrim Not tainted 7.0.10-2-default #1 PREEMPT(full) openSUSE Tumbleweed e9a5f6b24978fba3bf015a992f865837fdfff3dd Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250812-19.fc42 08/12/2025 pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : btrfs_trim_fs+0x34c/0xa00 [btrfs] lr : btrfs_trim_fs+0x1f0/0xa00 [btrfs] Call trace: btrfs_trim_fs+0x34c/0xa00 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] (P) btrfs_ioctl_fitrim+0xe8/0x178 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] btrfs_ioctl+0xdd4/0x2bd8 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] __arm64_sys_ioctl+0xac/0x108 invoke_syscall.constprop.0+0x5c/0xd0 el0_svc_common.constprop.0+0x40/0xf0 do_el0_svc+0x24/0x40 el0_svc+0x40/0x1d0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1b0/0x1b8 Code: 17ffff83 f94017e0 f9002be0 f9402ea0 (f9400c00) ---[ end trace 0000000000000000 ]--- Also the reporter is very kind to test the following ASSERT() added to btrfs_trim_free_extents_throttle(): ASSERT(device->bdev, "devid=%llu path=%s dev_state=0x%lx\n", device->devid, btrfs_dev_name(device), device->dev_state); And it shows the following output: assertion failed: device->bdev, in extent-tree.c:6630 (devid=2 path=/dev/sdd dev_state=0x82) Which means the device->bdev is NULL, and the dev_state is BTRFS_DEV_STATE_IN_FS_METADATA | BTRFS_DEV_STATE_ITEM_FOUND, without BTRFS_DEV_STATE_WRITEABLE flag set. [CAUSE] The pc points to the following call chain: btrfs_trim_fs() |- btrfs_trim_free_extents() |- btrfs_trim_free_extents_throttle() |- bdev_max_discard_sectors(device->bdev) So the NULL pointer dereference is caused by device->bdev being NULL. This looks impossible by a quick glance, as just before calling btrfs_trim_free_extents_throttle(), we have skipped any device that has BTRFS_DEV_STATE_MISSING flag set. However in this particular case, there is a window where the missing device is later re-scanned, causing btrfs to remove the BTRFS_DEV_STATE_MISSING flag: btrfs_control_ioctl() |- btrfs_scan_one_device() |- device_list_add() |- rcu_assign_pointer(device->name, name); | This updates the missing device's path to the new good path. | |- clear_bit(BTRFS_DEV_STATE_MISSING, &device->dev_state) This removes the BTRFS_DEV_STATE_MISSING flag. This allows the missing device to re-appear and clear the BTRFS_DEV_STATE_MISSING flag. However the device still does not have the BTRFS_DEV_STATE_WRITEABLE flag set, nor is its bdev pointer updated. The bdev pointer remains NULL, triggering the crash later. [FIX] This is a big de-synchronization between BTRFS_DEV_STATE_MISSING and device->bdev pointer, and shows a gap in btrfs's re-appearing-device handling. The proper handling of re-appearing device will need quite some extra work, which is out of the context of this small ---truncated---

In the Linux kernel, the following vulnerability has been resolved: riscv: mm: Unconditionally sfence.vma for spurious fault Svvptc does not guarantee that it's safe to just return here. Since we have already cleared our bit, if, theoretically, the bounded timeframe for the accessed page to become valid still hasn't happened after sret, we could fault again and actually crash. Hopefully, these spurious faults should be rare enough that this is an acceptable slowdown.

Stack-based buffer overflow in ELAN Smart-Pad Windows kernel drivers ETD.sys and ETDSMBus.sys allows a local standard-privilege user to crash the entire Windows system via a kernel bugcheck (BSOD 0xF7 DRIVER_OVERRAN_STACK_BUFFER). The vulnerability is rooted in the Intel SMBus recovery code path: ETDSMBus.sys accepts a hardware-derived report count without enforcing an upper bound and forwards it to ETD.sys, where it drives an unbounded stack buffer copy. A proof-of-concept exists (CVSS 4.0 E:P) and no confirmed patch version has been identified from available data; no active exploitation is listed in CISA KEV at time of analysis.

Integer underflow in HDF5 through 2.3.0 allows denial of service when processing Fletcher32-filtered datasets with chunk sizes smaller than 4 bytes. The `H5Z__filter_fletcher32` function in `H5Zfletcher32.c` subtracts the 4-byte checksum length from the input buffer size using an unsigned `size_t` without first verifying the buffer meets the minimum size, causing the result to wrap near `SIZE_MAX` and triggering a massively out-of-bounds read inside `H5_checksum_fletcher32`. Any application or pipeline calling `H5Dread` on a crafted HDF5 file - including the standard `h5ls` and `h5dump` utilities - can be crashed; no public exploit code has been identified and this vulnerability is not in CISA KEV.

Null pointer dereference in HDF5 through 2.3.0 allows denial of service when a user opens a crafted file containing a malformed N-Bit filter pipeline message with zero client-data values. The function H5Z__filter_nbit unconditionally reads cd_values[0] through cd_values[4] before checking whether the array is non-NULL or contains at least 5 elements, crashing any application - including the bundled h5ls and h5repack tools - that calls H5Dread on such a dataset. No active exploitation has been confirmed (not listed in CISA KEV) and no EPSS score was available, but the fix diff publicly exposes the exact crash path, lowering the barrier for proof-of-concept development.

HDF5 library through version 2.3.0 crashes with a divide-by-zero when a process opens a crafted file containing mismatched chunk-layout and dataspace dimensionality. The missing rank validation in H5O__layout_decode allows the corrupt metadata to propagate unchecked to H5S__hyper_iter_get_seq_list, where the invalid value causes integer division by zero and application termination. Tools that automatically consume externally-supplied HDF5 files - such as the bundled h5repack utility - are the primary exposure surface; no public exploit code or confirmed active exploitation has been identified at time of analysis.

Untrusted pointer dereference in HDF5's h5dump utility (before version 2.1.1) causes a denial of service when processing specially crafted HDF5 files containing variable-length string datasets with more than one element rendered in binary mode. The stride calculation for per-element offsets becomes corrupted, causing subsequent elements to be read from misaligned memory addresses and dereferenced as pointers, crashing the tool. No public exploit code exists at time of analysis, and no active exploitation has been confirmed - the local attack vector and DoS-only impact make this a low operational priority for most environments.

Integer underflow in the popt command-line option parsing library can crash any application that links against it when help text is rendered under specific terminal-width conditions. Affects local, low-privileged users on systems running popt-linked applications - a broad attack surface given popt's presence across Red Hat-derived Linux distributions. Impact is strictly denial of service against the affected application; no confidentiality or integrity loss is possible. No public exploit code or active exploitation has been identified at time of analysis.

Memory exhaustion in rclone's shared HTTP CONNECT proxy helper (`lib/proxy/http.go`) allows a malicious or compromised proxy to crash the rclone process by returning arbitrarily large CONNECT response headers. Versions up to and including 1.74.0 are affected; the fix is confirmed in v1.75.0. No active exploitation has been identified (not in CISA KEV), but the advisory includes a detailed proof-of-concept demonstrating that a 2 MiB header is accepted without error across repeated test runs, and the impact is process-wide OOM affecting all FTP, SFTP, and other rclone mounts concurrently.

Denial of service in GitHub Enterprise Server allows unauthenticated remote attackers to render an instance fully unresponsive by submitting a crafted form-encoded HTTP POST request containing deeply nested parameters, triggering uncontrolled recursive parsing that exhausts both CPU and the pool of request-handling worker processes. Because parameter parsing occurs before routing and authentication checks, every POST endpoint on the instance serves as a viable attack surface, requiring no foothold or prior knowledge of application structure. No public exploit code has been identified and the vulnerability is not listed in CISA KEV; the CVSS 4.0 E:U modifier confirms no known active exploitation at the time of scoring. GitHub has released patches across four supported release trains.

Denial of service in HPE Integrated Lights-Out 6 (iLO 6) firmware prior to v1.78 allows an unauthenticated attacker on an adjacent network segment to render the management interface unavailable. The impact is limited to availability (A:H) with no confidentiality or integrity compromise, but disrupting iLO can blind administrators to server state and block out-of-band recovery operations during incidents. No public exploit or active exploitation has been identified at time of analysis; HPE has released v1.78 as the fix.

Denial of service in Cisco IOS XE Software's web-based management interface allows an authenticated remote attacker with low privileges to reload an affected device by presenting a malformed certificate during authentication. The root cause is insufficient error handling (CWE-126, buffer over-read) in the certificate parsing path of the HTTPS management interface, affecting a broad swath of IOS XE releases from 17.3.x through 26.x. No public exploit code exists and the vulnerability is not listed in CISA KEV, but the wide deployment footprint of IOS XE in enterprise and service provider networks makes even a low-probability DoS meaningful at scale.

Denial-of-service in Cisco IOS XE Software's web-based management interface (WebUI) allows an authenticated remote attacker holding only low-privilege credentials to render the management interface unresponsive by sending crafted input that bypasses input validation. The vulnerability spans an exceptionally broad version footprint - from 16.9.x through the 26.x release train - making patching scope significant for organizations running Cisco enterprise routing and switching infrastructure. No public exploit has been identified at time of analysis and this CVE is not listed in the CISA Known Exploited Vulnerabilities catalog, placing real-world urgency below its broad scope might suggest.

Prometheus metric label cardinality exhaustion in Red Hat Build of Keycloak allows any authenticated user to crash the service by flooding its metric store with unique entries. When the Keycloak metrics subsystem is active, failed account operations (such as login attempts referencing nonexistent client IDs) cause raw, unsanitized error strings to be registered as Prometheus label values; because Prometheus stores each unique label combination as a distinct time series, a low-privileged attacker can generate an unbounded number of distinct metric entries, consuming JVM heap until the process crashes or becomes unresponsive. No public exploit code and no CISA KEV listing exist at time of analysis, but the low attack complexity and broad authenticated-user surface make this a realistic denial-of-service risk in any deployment where metrics are enabled.

Persistent denial of service in libkcapi's AIO interface allows a local attacker to permanently hang an affected application thread by exploiting improper error-state handling in _kcapi_aio_read_all(). Affected deployments span Red Hat Enterprise Linux 8, 9, and 10, Red Hat Hardened Images, and Red Hat OpenShift Container Platform 4 - all environments where applications leverage libkcapi's asynchronous cryptographic operations. No public exploit code or active exploitation has been identified at time of analysis; the high attack complexity (AC:H) and local-only attack vector substantially limit real-world risk beyond targeted or insider-threat scenarios.

M-Files Server before version 26.5.16015.3 can be crashed and permanently halted by an authenticated administrator, requiring manual intervention to restore document management services. The vulnerability stems from improper validation of syntactic input correctness (CWE-1286), allowing a privileged user to trigger a process crash from which the server cannot automatically recover. No public exploit code exists and this vulnerability is not listed in CISA KEV, positioning it primarily as an insider-threat or compromised-admin-account risk.

In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt

Denial of service in Rancher's dynamiclistener TLS library allows network-accessible attackers to exhaust certificate Subject Alternative Name capacity on both the Rancher server and cattle-cluster-agent components. By sending a large volume of TLS requests each presenting a distinct Server Name Indication (SNI) hostname, an attacker causes the dynamiclistener library to continuously append new SANs to the serving certificate until its size exceeds TLS handshake limits, breaking all TLS communication on the affected listener. No public exploit has been identified at time of analysis, and CISA KEV status is not confirmed; however, exploitation is straightforward given the low technical barrier.

Resource exhaustion in Apache Qpid Proton-J through 0.34.1 allows authenticated AMQP clients to trigger unbounded server-side resource consumption by sending a delivery composed of an arbitrarily large number of transfer frames - a limit the library fails to enforce. The root cause (CWE-770) is an absent cap on per-delivery transfer frame counts during message ingestion, not a memory corruption or code execution class flaw. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV; the primary risk is targeted denial of service against messaging infrastructure by any authenticated AMQP peer.

Denial of service in Apache Qpid Proton-J through 0.34.1 allows authenticated AMQP clients to exhaust server CPU by sending a crafted disposition frame carrying large or illegal delivery ranges. The library's naive range handling iterates without bounds validation, causing unbounded CPU consumption that can starve legitimate connections. No public exploit identified at time of analysis; vendor-released fix is available in version 0.35.0.

Denial of service in Apache Qpid Broker-J through 10.0.1 allows authenticated session participants to exhaust broker resources by deliberately exceeding the AMQP session flow control incoming window. The broker fails to enforce adequate limits on resource allocation when a session window is overflowed, enabling a malicious but authenticated client to destabilize or crash the broker. No public exploit code exists at time of analysis, and no confirmed active exploitation has been reported.

Denial of service in Apache Qpid Proton-J through 0.34.1 allows authenticated remote attackers to render the messaging endpoint unresponsive by deliberately exceeding the AMQP session flow control incoming window, triggering unbounded resource consumption. The root cause is CWE-770 - insufficient throttling of resource allocation - a well-understood class of flaw in protocol session management. No active exploitation has been confirmed and no public exploit code is known at time of analysis; the vendor has released a fix in version 0.35.0.

Persistent denial of service in dhcp-server (dhcpd) on Red Hat Enterprise Linux 6 through 9 is triggered via a crafted OMAPI lease creation request containing an overly long InfiniBand MAC address, overflowing a buffer in `print_hw_addr()` and crashing the dhcpd daemon in a way that prevents automatic recovery. The official CVSS score of 4.9 with PR:H reflects the assumption that TSIG authentication guards the OMAPI port; however, the description explicitly highlights that TSIG is optional and often absent, reducing the realistic exploitation barrier to unauthenticated network access. No confirmed active exploitation (KEV) or public proof-of-concept exists at time of analysis.

Catastrophic regex backtracking in Open WebUI 0.9.6-0.10.x allows any authenticated user to permanently stall a Uvicorn event-loop worker by supplying a crafted pattern to the built-in knowledge-search tool. The vulnerable `grep_knowledge_files` tool compiles attacker-supplied patterns with Python's unbounded `re` engine against attacker-uploaded file content, with no timeout anywhere on the execution path; a 30-character subject string measured at 74 seconds of CPU and a 40-character string extrapolates to roughly one day. No CISA KEV listing exists, but a complete proof-of-concept procedure is published in the GitHub security advisory GHSA-2f54-p244-32q6, making exploitation straightforward for any credential holder.

Open WebUI versions 0.9.0 through 0.10.x expose an instance-wide availability collapse through unbounded iCalendar recurrence rule parsing in the automation scheduler. The `_parse_rule` function in `backend/open_webui/utils/automations.py` anchors MINUTELY and HOURLY rules to a hardcoded 2000-01-01 epoch and iterates forward one interval at a time on the synchronous ASGI event loop - a single RRULE:FREQ=MINUTELY rule consumes approximately 18.9 seconds of blocking CPU, denying service to every concurrent user. Critically, the stall is not transient: once the automation is stored, the scheduler recomputes the next-run value on every 10-second poll, permanently wedging the instance until it is restarted or the automation is surgically removed. No public exploit identified at time of analysis, though the vendor advisory includes precise proof-of-concept timing measurements that make the attack trivially reproducible.

Session flow control enforcement in Apache Qpid ProtonJ2 (versions through 1.1.0) can be bypassed by an authenticated attacker who sends data exceeding the negotiated incoming flow control window, potentially causing denial of service on the receiving side. The AMQP session-level window is a back-pressure mechanism; failure to enforce it can lead to unbounded memory consumption or processing overload in the message broker or client. No public exploit code and no CISA KEV listing have been identified at time of analysis. The vendor-released fix is version 1.2.0.

Uncontrolled resource consumption in Apache Qpid Proton-Dotnet through 1.0.0 allows an authenticated AMQP client to trigger denial of service by sending a single delivery split across an unbounded number of transfer frames. The .NET implementation of the AMQP 1.0 toolkit lacked any enforced ceiling on incoming transfer frames per delivery, meaning a malicious but authenticated peer can exhaust receiver memory or CPU without restriction. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis; the fix is available in version 1.1.0.

Denial of service in Apache Qpid Proton-Dotnet through 1.0.0 allows an authenticated AMQP peer to exhaust CPU resources on the target host by sending a crafted disposition frame containing large or illegal delivery ranges. The library's naive range-iteration logic processes these unbounded ranges without safeguards, causing the consuming thread to spin and starve legitimate message processing. Vendor-released patch version 1.1.0 is available; no public exploit or CISA KEV listing has been identified at time of analysis.

Session flow control enforcement failure in Apache Qpid Proton-Dotnet through version 1.0.0 allows an authenticated attacker to deliberately exceed the AMQP incoming session flow control window, potentially causing denial of service on affected messaging endpoints. The vulnerability is rated 'important' by Apache and affects the .NET client library for AMQP-based messaging infrastructure. No public exploit code or active exploitation has been identified; vendor-confirmed fix is available in version 1.1.0.

Unbounded echo flow responses in Apache Qpid Broker-J (all versions through 10.0.1) allow an authenticated AMQP 1.0 client to exhaust broker resources and cause denial of service by flooding the broker with unanswered echo flow frames. The root cause is absent rate-limiting on echo flow response logic in the qpid-broker-plugins-amqp-1-0-protocol plugin. No public exploit code or CISA KEV listing has been identified; the vendor has released a fix in version 10.1.0.

Resource exhaustion in Apache Qpid Broker-J through version 10.0.1 enables authenticated remote attackers to cause denial of service by submitting an unbounded number of AMQP 1.0 transfer frames within a single incoming delivery, with no broker-side enforcement of a per-delivery frame ceiling. The broker's AMQP 1.0 protocol plugin lacks the necessary throttling logic, meaning sustained abuse can exhaust memory and CPU resources and deny service to legitimate messaging clients. No public exploit code has been identified and this vulnerability is not listed in CISA KEV; a vendor-released patch is available in version 10.1.0.

Denial of service in Apache Qpid Broker-J through version 10.0.1 allows authenticated AMQP 1.0 clients to exhaust broker CPU resources by sending crafted disposition frames containing large or illegal delivery-ID ranges. The broker's naive range iteration logic processes these ranges without bounds enforcement, causing excessive CPU consumption that degrades or halts message brokering for all connected clients. No public exploit code and no confirmed active exploitation are known at time of analysis; vendor-released fix 10.1.0 is available.

Race condition during LoRA manager singleton initialization in NVIDIA Dynamo for Linux (all versions through v1.1.0) allows unauthenticated remote attackers to cause denial of service or corrupt inference data by exploiting a TOCTOU flaw in concurrent initialization paths. The CVSS vector assigns high availability impact alongside low integrity impact, reflecting that service crashes are the primary outcome while data tampering represents a secondary, harder-to-achieve consequence. No public exploit code has been identified at time of analysis, and CISA has not added this to the Known Exploited Vulnerabilities catalog.

Race condition in NVIDIA Dynamo's LoRA manager singleton initialization exposes Linux-based AI inference deployments running versions up to v1.2.0 to data tampering and denial of service. The flaw, classified under CWE-362, arises during concurrent initialization of the singleton responsible for managing Low-Rank Adaptation (LoRA) adapters, allowing competing threads or network-triggered requests to corrupt shared state before synchronization is established. No public exploit code or CISA KEV listing has been identified at time of analysis; however, the network-accessible attack vector paired with no privilege requirement makes this relevant for any internet-facing or multi-tenant Dynamo deployment.