Denial Of Service

In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: use priv->vidi_dev for ctx lookup in vidi_connection_ioctl() vidi_connection_ioctl() retrieves the driver_data from drm_dev->dev to obtain a struct vidi_context pointer. However, drm_dev->dev is the exynos-drm master device, and the driver_data contained therein is not the vidi component device, but a completely different device. This can lead to various bugs, ranging from null pointer dereferences and garbage value accesses to, in unlucky cases, out-of-bounds errors, use-after-free errors, and more. To resolve this issue, we need to store/delete the vidi device pointer in exynos_drm_private->vidi_dev during bind/unbind, and then read this exynos_drm_private->vidi_dev within ioctl() to obtain the correct struct vidi_context pointer.

In the Linux kernel, the following vulnerability has been resolved: power: supply: ab8500: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Commit 1c1f13a006ed ("power: supply: ab8500: Move to componentized binding") introduced this issue during a refactorization. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.

In the Linux kernel, the following vulnerability has been resolved: erofs: fix inline data read failure for ztailpacking pclusters Compressed folios for ztailpacking pclusters must be valid before adding these pclusters to I/O chains. Otherwise, z_erofs_decompress_pcluster() may assume they are already valid and then trigger a NULL pointer dereference. It is somewhat hard to reproduce because the inline data is in the same block as the tail of the compressed indexes, which are usually read just before. However, it may still happen if a fatal signal arrives while read_mapping_folio() is running, as shown below: erofs: (device dm-1): z_erofs_pcluster_begin: failed to get inline data -4 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 ... pc : z_erofs_decompress_queue+0x4c8/0xa14 lr : z_erofs_decompress_queue+0x160/0xa14 sp : ffffffc08b3eb3a0 x29: ffffffc08b3eb570 x28: ffffffc08b3eb418 x27: 0000000000001000 x26: ffffff8086ebdbb8 x25: ffffff8086ebdbb8 x24: 0000000000000001 x23: 0000000000000008 x22: 00000000fffffffb x21: dead000000000700 x20: 00000000000015e7 x19: ffffff808babb400 x18: ffffffc089edc098 x17: 00000000c006287d x16: 00000000c006287d x15: 0000000000000004 x14: ffffff80ba8f8000 x13: 0000000000000004 x12: 00000006589a77c9 x11: 0000000000000015 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : ffffffffffffffe0 x3 : 0000000000000020 x2 : 0000000000000008 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: z_erofs_decompress_queue+0x4c8/0xa14 z_erofs_runqueue+0x908/0x97c z_erofs_read_folio+0x128/0x228 filemap_read_folio+0x68/0x128 filemap_get_pages+0x44c/0x8b4 filemap_read+0x12c/0x5b8 generic_file_read_iter+0x4c/0x15c do_iter_readv_writev+0x188/0x1e0 vfs_iter_read+0xac/0x1a4 backing_file_read_iter+0x170/0x34c ovl_read_iter+0xf0/0x140 vfs_read+0x28c/0x344 ksys_read+0x80/0xf0 __arm64_sys_read+0x24/0x34 invoke_syscall+0x60/0x114 el0_svc_common+0x88/0xe4 do_el0_svc+0x24/0x30 el0_svc+0x40/0xa8 el0t_64_sync_handler+0x70/0xbc el0t_64_sync+0x1bc/0x1c0 Fix this by reading the inline data before allocating and adding the pclusters to the I/O chains.

In the Linux kernel, the following vulnerability has been resolved: power: supply: pm8916_lbc: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.

In the Linux kernel, the following vulnerability has been resolved: power: supply: goldfish: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.

In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Hold mm structure across iommu_sva_unbind_device() Some tests trigger a crash in iommu_sva_unbind_device() due to accessing iommu_mm after the associated mm structure has been freed. Fix this by taking an explicit reference to the mm structure after successfully binding the device, and releasing it only after the device is unbound. This ensures the mm remains valid for the entire SVA bind/unbind lifetime.

In the Linux kernel, the following vulnerability has been resolved: ovpn: tcp - don't deref NULL sk_socket member after tcp_close() When deleting a peer in case of keepalive expiration, the peer is removed from the OpenVPN hashtable and is temporary inserted in a "release list" for further processing. This happens in: ovpn_peer_keepalive_work() unlock_ovpn(release_list) This processing includes detaching from the socket being used to talk to this peer, by restoring its original proto and socket ops/callbacks. In case of TCP it may happen that, while the peer is sitting in the release list, userspace decides to close the socket. This will result in a concurrent execution of: tcp_close(sk) __tcp_close(sk) sock_orphan(sk) sk_set_socket(sk, NULL) The last function call will set sk->sk_socket to NULL. When the releasing routine is resumed, ovpn_tcp_socket_detach() will attempt to dereference sk->sk_socket to restore its original ops member. This operation will crash due to sk->sk_socket being NULL. Fix this race condition by testing-and-accessing sk->sk_socket atomically under sk->sk_callback_lock.

In the Linux kernel, the following vulnerability has been resolved: power: supply: sbs-battery: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Keep the old behavior of just printing a warning in case of any failures during the IRQ request and finishing the probe successfully.

In the Linux kernel, the following vulnerability has been resolved: Revert "hwmon: (ibmpex) fix use-after-free in high/low store" This reverts commit 6946c726c3f4c36f0f049e6f97e88c510b15f65d. Jean Delvare points out that the patch does not completely fix the reported problem, that it in fact introduces a (new) race condition, and that it may actually not be needed in the first place. Various AI reviews agree. Specific and relevant AI feedback: " This reordering sets the driver data to NULL before removing the sensor attributes in the loop below. ibmpex_show_sensor() retrieves this driver data via dev_get_drvdata() but does not check if it is NULL before dereferencing it to access data->sensors[]. If a userspace process reads a sensor file (like temp1_input) while this delete function is running, could it race with the dev_set_drvdata(..., NULL) call here and crash in ibmpex_show_sensor()? Would it be safer to keep the original order where device_remove_file() is called before clearing the driver data? device_remove_file() should wait for any active sysfs callbacks to complete, which might already prevent the use-after-free this patch intends to fix. " Revert the offending patch. If it can be shown that the originally reported alleged race condition does indeed exist, it can always be re-introduced with a complete fix.

In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fix role switching during resume If the role change while we are suspended, the cdns3 driver switches to the new mode during resume. However, switching to host mode in this context causes a NULL pointer dereference. The host role's start() operation registers a xhci-hcd device, but its probe is deferred while we are in the resume path. The host role's resume() operation assumes the xhci-hcd device is already probed, which is not the case, leading to the dereference. Since the start() operation of the new role is already called, the resume operation can be skipped. So skip the resume operation for the new role if a role switch occurs during resume. Once the resume sequence is complete, the xhci-hcd device can be probed in case of host mode. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000208 Mem abort info: ... Data abort info: ... [0000000000000208] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 146 Comm: sh Not tainted 6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT Hardware name: Texas Instruments J7200 EVM (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usb_hcd_is_primary_hcd+0x0/0x1c lr : cdns_host_resume+0x24/0x5c ... Call trace: usb_hcd_is_primary_hcd+0x0/0x1c (P) cdns_resume+0x6c/0xbc cdns3_controller_resume.isra.0+0xe8/0x17c cdns3_plat_resume+0x18/0x24 platform_pm_resume+0x2c/0x68 dpm_run_callback+0x90/0x248 device_resume+0x100/0x24c dpm_resume+0x190/0x2ec dpm_resume_end+0x18/0x34 suspend_devices_and_enter+0x2b0/0xa44 pm_suspend+0x16c/0x5fc state_store+0x80/0xec kobj_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x130/0x1dc vfs_write+0x240/0x370 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0x108 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401) ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved: power: supply: pf1550: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.

In the Linux kernel, the following vulnerability has been resolved: power: supply: bq256xx: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.

In the Linux kernel, the following vulnerability has been resolved: power: supply: cpcap-battery: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.

In the Linux kernel, the following vulnerability has been resolved: power: supply: pm8916_bms_vm: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.

In the Linux kernel, the following vulnerability has been resolved: power: supply: bq25980: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.

In the Linux kernel, the following vulnerability has been resolved: phy: freescale: imx8qm-hsio: fix NULL pointer dereference During the probe the refclk_pad pointer is set to NULL if the 'fsl,refclk-pad-mode' property is not defined in the devicetree node. But in imx_hsio_configure_clk_pad() this pointer is unconditionally used which could result in a NULL pointer dereference. So check the pointer before to use it.

In the Linux kernel, the following vulnerability has been resolved: power: supply: wm97xx: Fix NULL pointer dereference in power_supply_changed() In `probe()`, `request_irq()` is called before allocating/registering a `power_supply` handle. If an interrupt is fired between the call to `request_irq()` and `power_supply_register()`, the `power_supply` handle will be used uninitialized in `power_supply_changed()` in `wm97xx_bat_update()` (triggered from the interrupt handler). This will lead to a `NULL` pointer dereference since Fix this racy `NULL` pointer dereference by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Since the IRQ is the last thing requests in the `probe()` now, remove the error path for freeing it. Instead add one for unregistering the `power_supply` handle when IRQ request fails.

In the Linux kernel, the following vulnerability has been resolved: power: supply: act8945a: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: prevent infinite loops caused by the next valid being the same When processing valid within the range [valid : pos), if valid cannot be retrieved correctly, for example, if the retrieved valid value is always the same, this can trigger a potential infinite loop, similar to the hung problem reported by syzbot [1]. Adding a check for the valid value within the loop body, and terminating the loop and returning -EINVAL if the value is the same as the current value, can prevent this. [1] INFO: task syz.4.21:6056 blocked for more than 143 seconds. Call Trace: rwbase_write_lock+0x14f/0x750 kernel/locking/rwbase_rt.c:244 inode_lock include/linux/fs.h:1027 [inline] ntfs_file_write_iter+0xe6/0x870 fs/ntfs3/file.c:1284

In the Linux kernel, the following vulnerability has been resolved: scsi: csiostor: Fix dereference of null pointer rn The error exit path when rn is NULL ends up deferencing the null pointer rn via the use of the macro CSIO_INC_STATS. Fix this by adding a new error return path label after the use of the macro to avoid the deference.

Authenticated denial-of-service in IBM Db2 for Linux, UNIX, and Windows allows a low-privileged network user to crash database availability by submitting specially crafted data queries against the Fenced environment. The vulnerability affects IBM Cloud APM Base Private 8.1.4 and Advanced Private 8.1.4, which bundle Db2 as a backend component. No public exploit has been identified at time of analysis, and the CVSS score of 6.5 reflects meaningful but bounded risk due to the authentication prerequisite.

NULL pointer dereference in libusb's USB descriptor parser allows any attacker who can supply a crafted configuration descriptor to crash any application that uses libusb for USB device enumeration. Affected versions are all libusb releases before 1.0.30; the flaw resides in parse_interface() within descriptor.c and is reachable through the public APIs libusb_get_active_config_descriptor and libusb_get_config_descriptor. No public exploit code is identified at time of analysis and this CVE does not appear in the CISA KEV catalog, but the availability impact is confirmed high (CVSS 4.0 VA:H) and regression corpus files in the fix commit demonstrate reliable crash reproduction.

Denial of service in IBM Db2 11.5.0-11.5.9 and 12.1.0-12.1.4 allows an authenticated database user to crash or exhaust the database engine by submitting a specially crafted query when the autonomous transactions feature is enabled. The flaw (CWE-770, uncontrolled resource allocation) carries a CVSS 7.1 with high availability impact but no confidentiality or integrity loss. There is no public exploit identified at time of analysis, and CISA SSVC rates exploitation as 'none', indicating no observed activity to date.

In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Fix potential NULL pointer dereference in context cleanup aie_destroy_context() is invoked during error handling in aie2_create_context(). However, aie_destroy_context() assumes that the context's mailbox channel pointer is non-NULL. If mailbox channel creation fails, the pointer remains NULL and calling aie_destroy_context() can lead to a NULL pointer dereference. In aie2_create_context(), replace aie_destroy_context() with a function which request firmware to remove the context created previously.

In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix NULL pointer dereference on panthor_fw_unplug This patch removes the MCU halt and wait for halt procedures during panthor_fw_unplug() as the MCU can be in a variety of states or the FW may not even be loaded/initialized at all, the latter of which can lead to a NULL pointer dereference. It should be safe on unplug to just disable the MCU without waiting for it to halt as it may not be able to.

In the Linux kernel, the following vulnerability has been resolved: bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst() bareudp_fill_metadata_dst() passes bareudp->sock to udp_tunnel6_dst_lookup() in the IPv6 path without a NULL check. The socket is only created in bareudp_open() and NULLed in bareudp_stop(), so calling this function while the device is down triggers a NULL dereference via sock->sk. BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:udp_tunnel6_dst_lookup (net/ipv6/ip6_udp_tunnel.c:160) Call Trace: <TASK> bareudp_fill_metadata_dst (drivers/net/bareudp.c:532) do_execute_actions (net/openvswitch/actions.c:901) ovs_execute_actions (net/openvswitch/actions.c:1589) ovs_packet_cmd_execute (net/openvswitch/datapath.c:700) genl_family_rcv_msg_doit (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1209) netlink_rcv_skb (net/netlink/af_netlink.c:2550) </TASK> Add a NULL check returning -ESHUTDOWN, consistent with the xmit paths in the same driver.

In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: fix NULL pointer dereference in class dump When a TAPRIO child qdisc is deleted via RTM_DELQDISC, taprio_graft() is called with new == NULL and stores NULL into q->qdiscs[cl - 1]. Subsequent RTM_GETTCLASS dump operations walk all classes via taprio_walk() and call taprio_dump_class(), which calls taprio_leaf() returning the NULL pointer, then dereferences it to read child->handle, causing a kernel NULL pointer dereference. The bug is reachable with namespace-scoped CAP_NET_ADMIN on any kernel with CONFIG_NET_SCH_TAPRIO enabled. On systems with unprivileged user namespaces enabled, an unprivileged local user can trigger a kernel panic by creating a taprio qdisc inside a new network namespace, grafting an explicit child qdisc, deleting it, and requesting a class dump. The RTM_GETTCLASS dump itself requires no capability. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000007: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:taprio_dump_class (net/sched/sch_taprio.c:2478) Call Trace: <TASK> tc_fill_tclass (net/sched/sch_api.c:1966) qdisc_class_dump (net/sched/sch_api.c:2326) taprio_walk (net/sched/sch_taprio.c:2514) tc_dump_tclass_qdisc (net/sched/sch_api.c:2352) tc_dump_tclass_root (net/sched/sch_api.c:2370) tc_dump_tclass (net/sched/sch_api.c:2431) rtnl_dumpit (net/core/rtnetlink.c:6864) netlink_dump (net/netlink/af_netlink.c:2325) rtnetlink_rcv_msg (net/core/rtnetlink.c:6959) netlink_rcv_skb (net/netlink/af_netlink.c:2550) </TASK> Fix this by substituting &noop_qdisc when new is NULL in taprio_graft(), a common pattern used by other qdiscs (e.g., multiq_graft()) to ensure the q->qdiscs[] slots are never NULL. This makes control-plane dump paths safe without requiring individual NULL checks. Since the data-plane paths (taprio_enqueue and taprio_dequeue_from_txq) previously had explicit NULL guards that would drop/skip the packet cleanly, update those checks to test for &noop_qdisc instead. Without this, packets would reach taprio_enqueue_one() which increments the root qdisc's qlen and backlog before calling the child's enqueue; noop_qdisc drops the packet but those counters are never rolled back, permanently inflating the root qdisc's statistics. After this change *old can be a valid qdisc, NULL, or &noop_qdisc. Only call qdisc_put(*old) in the first case to avoid decreasing noop_qdisc's refcount, which was never increased.

In the Linux kernel, the following vulnerability has been resolved: slip: reject VJ receive packets on instances with no rstate array slhc_init() accepts rslots == 0 as a valid configuration, with the documented meaning of 'no receive compression'. In that case the allocation loop in slhc_init() is skipped, so comp->rstate stays NULL and comp->rslot_limit stays 0 (from the kzalloc of struct slcompress). The receive helpers do not defend against that configuration. slhc_uncompress() dereferences comp->rstate[x] when the VJ header carries an explicit connection ID, and slhc_remember() later assigns cs = &comp->rstate[...] after only comparing the packet's slot number to comp->rslot_limit. Because rslot_limit is 0, slot 0 passes the range check, and the code dereferences a NULL rstate. The configuration is reachable in-tree through PPP. PPPIOCSMAXCID stores its argument in a signed int, and (val >> 16) uses arithmetic shift. Passing 0xffff0000 therefore sign-extends to -1, so val2 + 1 is 0 and ppp_generic.c ends up calling slhc_init(0, 1). Because /dev/ppp open is gated by ns_capable(CAP_NET_ADMIN), the whole path is reachable from an unprivileged user namespace. Once the malformed VJ state is installed, any inbound VJ-compressed or VJ-uncompressed frame that selects slot 0 crashes the kernel in softirq context: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:slhc_uncompress (drivers/net/slip/slhc.c:519) Call Trace: <TASK> ppp_receive_nonmp_frame (drivers/net/ppp/ppp_generic.c:2466) ppp_input (drivers/net/ppp/ppp_generic.c:2359) ppp_async_process (drivers/net/ppp/ppp_async.c:492) tasklet_action_common (kernel/softirq.c:926) handle_softirqs (kernel/softirq.c:623) run_ksoftirqd (kernel/softirq.c:1055) smpboot_thread_fn (kernel/smpboot.c:160) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) </TASK> Reject the receive side on such instances instead of touching rstate. slhc_uncompress() falls through to its existing 'bad' label, which bumps sls_i_error and enters the toss state. slhc_remember() mirrors that with an explicit sls_i_error increment followed by slhc_toss(); the sls_i_runt counter is not used here because a missing rstate is an internal configuration state, not a runt packet. The transmit path is unaffected: the only in-tree caller that picks rslots from userspace (ppp_generic.c) still supplies tslots >= 1, and slip.c always calls slhc_init(16, 16), so comp->tstate remains valid and slhc_compress() continues to work.

In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULO nf_osf_match_one() computes ctx->window % f->wss.val in the OSF_WSS_MODULO branch with no guard for f->wss.val == 0. A CAP_NET_ADMIN user can add such a fingerprint via nfnetlink; a subsequent matching TCP SYN divides by zero and panics the kernel. Reject the bogus fingerprint in nfnl_osf_add_callback() above the per-option for-loop. f->wss is per-fingerprint, not per-option, so the check must run regardless of f->opt_num (including 0). Also reject wss.wc >= OSF_WSS_MAX; nf_osf_match_one() already treats that as "should not happen". Crash: Oops: divide error: 0000 [#1] SMP KASAN NOPTI RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: <IRQ> nf_osf_match (net/netfilter/nfnetlink_osf.c:220) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:348) nf_hook_slow (net/netfilter/core.c:622) ip_local_deliver (net/ipv4/ip_input.c:265) ip_rcv (include/linux/skbuff.h:1162) __netif_receive_skb_one_core (net/core/dev.c:6181) process_backlog (net/core/dev.c:6642) __napi_poll (net/core/dev.c:7710) net_rx_action (net/core/dev.c:7945) handle_softirqs (kernel/softirq.c:622)

IO::Compress versions from 2.207 before 2.220 for Perl ship a zipdetails CLI tool that crashes with undefined subroutine on Info-ZIP Unix Extra Field with 8-byte UID or GID. When decode_ux() in bin/zipdetails handles an Info-ZIP Unix Extra Field (tag 0x7875) with UID Size or GID Size set to 8, causing zipdetails to decode an 8-byte UID or GID value, it dispatches through decodeLitteEndian(), which calls a misnamed helper unpackValueQ. The actual function defined in the same file is unpackValue_Q (with underscore); the call raises 'Undefined subroutine &main::unpackValueQ' and the script exits with status 255. Library callers of IO::Compress and IO::Uncompress are not affected; the defect is in the bundled CLI tool.

Authenticated network-accessible denial of service in Tanium Server affects three active release branches, patched in versions 7.6.4.2190, 7.7.3.8274, and 7.8.2.1176. The vulnerability stems from a CWE-772 resource leak - allocated resources are not released after their effective lifetime, enabling a low-privileged authenticated attacker to exhaust server resources. A notable conflict exists in the available data: the CVSS vector reports C:H/I:N/A:N (high confidentiality impact, no availability impact) while the CVE description, ENISA EUVD tags, and vendor advisory title all characterize this as a denial of service; defenders should treat both confidentiality and availability as potentially affected until Tanium clarifies. No public exploit is identified and EPSS is low at 0.03%.

Uncontrolled resource consumption in the Simply Schedule Appointments WordPress plugin (all versions ≤ 1.6.11.5) enables unauthenticated remote attackers to exhaust PHP-FPM or mod_php worker processes, effectively rendering the WordPress site unavailable to legitimate users. The attack surface is a publicly accessible REST endpoint (/wp-json/ssa/v1/async) that directly passes a caller-controlled delay parameter into PHP's native sleep() function with no rate limiting or input sanitization. No public exploit code has been identified at time of analysis and EPSS is very low (0.05%, 15th percentile), suggesting limited opportunistic interest so far, though the trivially low attack complexity means any actor can attempt this with no tooling.

Denial of service in OpenStack Swift's s3api middleware allows an authenticated S3 API user to permanently hang proxy-server workers by sending a truncated aws-chunked PUT request body. Versions 2.36.0 through 2.36.1 and 2.37.0 through 2.37.1 are affected; the defect was introduced in 2.36.0 and fixed in 2.36.2 and 2.37.2. There is no public exploit identified at time of analysis, and EPSS is very low (0.04%, 12th percentile), but the high availability impact and low attack complexity make this a credible operational threat to S3-compatible Swift deployments.

{% for %}` or `{% tablerow %}` tags with empty bodies, enabling any low-privileged template author to stall a Node.js event-loop thread for an attacker-controlled duration. Because Node.js is single-threaded, a stall of 2-10+ seconds on one worker blocks all concurrent in-flight HTTP requests on that process, making this a practical denial-of-service vector in SaaS and multi-tenant platforms. A public proof-of-concept is included in the GitHub Security Advisory (GHSA-8xx9-69p8-7jp3) and was reproduced against liquidjs@10.25.7; no patch has been released as of this analysis.

Memory corruption via an off-by-one error in GnuTLS PKCS#12 bag element handling exposes any application using GnuTLS to remote unauthenticated denial of service - and potentially unspecified further impact - when a crafted PKCS#12 structure is parsed. The CVSS vector (AV:N/AC:L/PR:N/UI:N) confirms exploitation requires no authentication, no user interaction, and no elevated complexity, making internet-exposed services that parse client-supplied PKCS#12 inputs the primary risk surface. No public exploit code exists and the vulnerability is not listed in the CISA KEV catalog at time of analysis.

Memory exhaustion in Oban Web's cron expression rendering engine allows a low-privileged attacker who can schedule jobs to crash the BEAM VM node. By submitting a cron expression with an astronomically large range such as '0 0 1-100000000 * *', the attacker causes Elixir.Oban.Web.CronExpr.describe/1 to eagerly materialize the range into a list via Enum.to_list/1, allocating approximately 2.4 GB of memory and stalling or crashing the node when a dashboard user views the cron job list. No public exploit identified at time of analysis, but the attack requires no specialized tooling - the malicious expression is trivial to craft given knowledge of the unguarded parse path.

Allocation of Resources Without Limits or Throttling vulnerability in benoitc hackney allows Flooding. hackney_h3:await_response_loop/6 accumulates the HTTP/3 response body in memory without any size cap. The after Timeout clause is a per-message inactivity timer that resets on every received chunk, housekeeping message, or settings frame - it is not a wall-clock deadline. A malicious HTTP/3 server that emits one small chunk every Timeout - 1 ms with Fin = false and never sends a final frame keeps the loop alive indefinitely while the accumulation buffer grows linearly without bound, eventually exhausting the BEAM process heap and causing an out-of-memory condition. This issue affects hackney: from 2.0.0 before 4.0.1.

Unauthenticated denial of service in GNU SASL before version 2.2.3 occurs through a NULL pointer dereference in the DIGEST-MD5 authentication mechanism. Remote attackers can crash both client and server applications by sending a malformed authentication token that lacks an equals sign character, causing the getsubopt.c parser to dereference a NULL pointer.

Pre-authentication denial of service in Parse Server (npm parse-server) lets a remote attacker who knows a publicly-known Parse Application ID pin a Node.js worker for seconds to minutes by sending a single crafted request with adversarial input in the X-Parse-Client-Version header or _ClientVersion JSON body field. The vulnerable client SDK version parser executes before session authentication and rate limiting on every /parse/* route, so a handful of concurrent requests can starve worker capacity. No public exploit identified at time of analysis, but the vendor advisory (GHSA-38m6-82c8-4xfm) and merged patch PRs confirm the issue and provide regression tests demonstrating the trigger.

Parsing arbitrary HTML can consume excessive CPU time, possibly leading to denial of service.

Server crash via race condition in Mattermost's persistent notification and channel archival subsystem allows any low-privileged authenticated user to bring down the server with no user interaction required. Affected branches span 10.11.x through 11.6.x across multiple maintenance lines. No public exploit code has been identified at time of analysis and the vulnerability is absent from CISA KEV, but the low authentication bar combined with network accessibility and low attack complexity makes this a credible insider threat or targeted denial-of-service vector against any exposed Mattermost deployment.

Authenticated denial-of-service in Mattermost's plugin subsystem allows a low-privileged user to crash the plugin process by sending a crafted HTTP request to the PR details API endpoint. Affected across four active release branches (10.11.x, 11.4.x, 11.5.x, 11.6.x), the flaw stems from missing input validation in API request handlers (CWE-1287). No public exploit code exists and the vulnerability is not listed in CISA KEV; however, the low authentication barrier (any valid account) combined with network accessibility makes it a realistic insider or post-compromise nuisance risk.

Denial of service in Mattermost server (versions 11.6.0, 11.5.0-11.5.3, 11.4.0-11.4.4, and 10.11.0-10.11.14) allows remote attackers to crash the server process by sending a crafted msgpack-encoded binary WebSocket frame to the public endpoint. The flaw stems from missing validation of frame sizes before memory allocation, enabling a full service outage for all users. No public exploit identified at time of analysis, and the CVSS 7.5 score reflects the unauthenticated network-reachable nature of the attack with high availability impact.

Denial of service in Mattermost's plugin HTTP endpoint layer allows an authenticated high-privilege attacker to exhaust server resources by sending crafted oversized HTTP request bodies. Affected across four concurrent release branches - 10.11.x through 11.6.x - with no published EPSS score and no confirmed active exploitation or public proof-of-concept at time of analysis. The CVSS score of 4.9 (Medium) accurately reflects the high-privilege prerequisite that meaningfully limits the realistic attacker population, though availability impact is rated High, meaning successful exploitation disrupts service availability entirely.

Uncontrolled memory allocation in Mattermost's TIFF image processing allows authenticated users to trigger server-side out-of-memory (OOM) conditions, effectively taking down the collaboration platform. Affected are all Mattermost deployments running versions 10.11.x through 11.6.0. Any account holding file upload or URL-posting permissions can exploit this remotely without elevated privileges, making it a realistic insider or compromised-account threat. No public exploit code or CISA KEV listing has been identified at time of analysis, but the low attack complexity and broad authentication base increase practical risk.

The RSA and DSA public key parsers did not enforce size limits on key parameters. A crafted public key with an excessively large modulus or DSA parameter could cause several minutes of CPU consumption during signature verification. This could be triggered by unauthenticated clients during public key authentication. RSA moduli are now limited to 8192 bits, and DSA parameters are validated per FIPS 186-2.

A malicious SSH peer could send unsolicited global request responses to fill an internal buffer, blocking the connection's read loop. The blocked goroutine could not be released by calling Close(), resulting in a resource leak per connection. Unsolicited global responses are now discarded.

HP ENVY 5000 series printers VERBASPP1N003.2237A.00 do not properly manage concurrent TCP connections to port 9100 (JetDirect/RAW printing). An unauthenticated remote attacker on the same network can establish a persistent connection to port 9100 and send keep-alive packets, causing the printer's session threads to remain locked in a waiting state. The firmware lacks connection timeouts and concurrent session limits, resulting in a persistent Denial of Service (DoS) that renders the printer unresponsive to all user commands and print jobs. Physical intervention (manual restart) is required to restore functionality, and the attack can be immediately re-initiated.

Use-after-free in Ruby 4.x (before 4.0.5) lets remote attackers who can manipulate DNS response timing crash applications calling Addrinfo.getaddrinfo with a timeout: option or Socket.tcp with resolv_timeout:. The flaw lives in the pthread-based getaddrinfo timeout handler (rb_getaddrinfo in ext/socket/raddrinfo.c) and, while reliably exploitable for denial of service, also raises a theoretical possibility of memory-corruption-based code execution. No public exploit identified at time of analysis.

Remote denial-of-service in @libp2p/gossipsub (versions <= 15.0.22) allows a single unauthenticated peer to exhaust the Node.js heap of any gossipsub node running default options. Three cooperating defects - an uncapped decode limit (maxSubscriptions = Infinity), unbounded growth of the internal this.topics Map on subscription handling, and a memory leak that leaves empty Sets behind on peer disconnect - combine to produce ~22x amplification, crashing a 1.5GB-heap process after roughly 68MB of attacker bandwidth (~5 seconds at 100Mbps). A working PoC is published in the GitHub Security Advisory GHSA-4f8r-922h-2vgv; no public exploit identified at time of analysis as a separate weaponized tool, but the advisory itself contains reproducible test code.

Unbounded formatter memoization in twig/intl-extra versions prior to 3.26.0 enables memory exhaustion denial of service on persistent PHP worker runtimes. The IntlExtension caches every unique combination of template filter arguments (locale, pattern, grouping_used, attrs, etc.) as ICU formatter objects with no eviction policy; because ICU allocates its backing buffers outside the Zend memory manager, this growth entirely bypasses PHP's memory_limit directive. On long-running runtimes such as RoadRunner, Swoole, FrankenPHP worker mode, and ReactPHP - where a single Twig\Environment persists across requests - the cache accumulates indefinitely across all requests, making targeted or incidental denial of service achievable without any authentication. No public exploit has been identified at time of analysis and no CISA KEV listing exists.

Denial-of-service via unchecked memory allocation in russh (Rust SSH library) versions <= 0.60.2 allows local SSH agent peers to trigger uncontrolled buffer growth by sending oversized frame length values, and in pre-0.58.0 releases the same CryptoVec allocation path was reachable from remote SSH transport and zlib decompression buffers. The flaw stems from CryptoVec performing unchecked capacity growth, unchecked length arithmetic, and unsafe allocation/locking calls including NonNull::new_unchecked on potentially failed allocations, which can abort the process under memory pressure. Publicly available exploit code exists in the form of researcher-supplied PoC tests demonstrating both rejection on patched code and crash behavior on historical versions; no public exploit identified at time of analysis for active campaigns and the issue is not listed in CISA KEV.

Attachment size limit bypass in NocoDB (npm, versions up to and including 0.301.3) allows authenticated users with upload permission to store files exceeding the operator-configured `NC_ATTACHMENT_FIELD_SIZE` quota via the upload-by-URL pathway. The attachments service failed to validate file size against either the remote server's `Content-Length` HTTP header or the decoded byte length of `data:` URI payloads before fetching, and the local storage plugin did not set `maxContentLength` on the axios download, enabling unconstrained resource consumption. No public exploit has been identified at time of analysis, and no vendor-released patched version is confirmed available.

Disk exhaustion denial of service in NocoDB's v1/v2 attachment upload-by-URL API allows authenticated users with Editor-level privileges or higher to direct the server to fetch arbitrarily large remote files, consuming all available disk space. The root cause is missing enforcement of the NC_ATTACHMENT_FIELD_SIZE configuration limit in attachments.service.ts for the v1/v2 code paths, despite the v3 equivalent already implementing the constraint correctly. Cascading failures follow disk exhaustion: database writes block, log rotation fails, and the application itself may crash - making this a high-availability-impact issue for any NocoDB deployment with untrusted authenticated users.

Remote unauthenticated denial-of-service in the Nimiq core-rs-albatross client (nimiq-primitives crate prior to 1.5.0) lets any state-sync peer crash a syncing node by sending a ResponseChunk whose first TrieItem.key is the empty ROOT key, triggering a panic in MerkleRadixTrie::put_chunk → put_raw. No public exploit identified at time of analysis, but the issue is trivially triggerable with a single malformed chunk and affects all nodes performing initial sync or recovery against untrusted peers. EPSS data was not provided; CVSS A:H impact and zero attacker prerequisites make this a high-priority availability bug for Nimiq node operators.

Unauthenticated remote crash of Nimiq full nodes running nimiq-blockchain versions before 1.5.0 is achievable by any network peer sending a single crafted RequestBatchSet message referencing the genesis block hash. The node's batch set handler iterates backward through macro blocks without a lower-bound guard, causing a Rust panic in Policy::macro_block_before when iteration reaches genesis, immediately terminating the process. No CISA KEV listing and no public exploit code exist at time of analysis; however, the attack requires no authentication and trivially low complexity, posing a real availability threat to any reachable full node.

Process crash in the nimiq-keys Rust crate (versions below 1.4.0) occurs when the Ed25519 multisig delinearization path receives a 32-byte public key that is length-valid but does not represent a valid point on the Edwards25519 curve, triggering a Rust `.unwrap()` panic that kills the hosting wallet process. Affected users are those running the Nimiq web-client WASM library or nimiq-wallet crate who can be persuaded by an attacker to include a crafted key in a multisig setup; validator nodes and all consensus infrastructure are explicitly out of scope. No public exploit has been identified at time of analysis, and no KEV listing exists, indicating this has not been broadly weaponized.

Arbitrary code execution in InternLM lmdeploy <= 0.12.3 occurs because trust_remote_code=True is hardcoded across HuggingFace model-loading call sites in lmdeploy/archs.py and lmdeploy/utils.py. An attacker who can influence the model_path passed to an lmdeploy serving process can point it at a malicious HuggingFace repository, causing Transformers to download and execute attacker-controlled Python code with the privileges of the serving daemon. Publicly available exploit code exists in the GHSA advisory, and an upstream fix has been merged via PR #4511 (fixed in 0.13.0).

Remote denial of service in PowerDNS Authoritative Server arises from insufficient validation of SOA queries received via the Autoprimary (formerly 'supermaster') replication mechanism, allowing unauthenticated network-based attackers to disrupt service availability. The flaw carries a CVSS 7.5 (AV:N/AC:L/PR:N/UI:N) with availability-only impact, and no public exploit identified at time of analysis. The OX-reported issue is documented in PowerDNS Security Advisory 2026-06.

Netatalk versions 3.1.2 through 4.4.2 are distributed as binaries compiled without the FORTIFY_SOURCE flag, stripping away runtime buffer overflow detection that the compiler would otherwise embed into unsafe C standard library calls. Remote unauthenticated attackers can, under high-complexity conditions, trigger memory errors that the absent protection would have safely caught and terminated, instead manifesting as minor availability impact (CVSS A:L). No public exploit code exists and CISA has not added this to the KEV catalog; the CVSS score of 3.7 (Low) reflects the limited impact ceiling and high attack complexity.

Unbounded realloc during charset conversion in Netatalk 2.0.0 through 4.4.2 allows an authenticated remote attacker to trigger excessive memory allocation, resulting in limited availability impact. The flaw is classified under CWE-770 (resource allocation without limits) and carries a low CVSS score of 3.1, reflecting constrained exploitability due to high attack complexity and required authentication. No public exploit code or active exploitation has been identified at time of analysis; a fix was released in version 4.5.0.

Denial of service in Netatalk versions 1.5.0 through 4.4.2 allows remote unauthenticated attackers to crash the AFP (Apple Filing Protocol) service by exploiting an integer underflow in the dsi_writeinit() function. The flaw is network-reachable with low complexity (CVSS 7.5, AV:N/AC:L/PR:N) and no public exploit identified at time of analysis, though the trivial trigger conditions make exploitation straightforward once a proof-of-concept emerges. Netatalk has resolved the issue in version 4.4.3.

Heap-based buffer overflow in libsolv's repo_add_solv() function enables a remote unauthenticated attacker to crash the parsing process by delivering a specially crafted .solv repository metadata file containing negative values in the maxsize or allsize header fields. The malformed values bypass allocation sizing logic, producing an undersized heap buffer that is subsequently written past its bounds, yielding a denial of service. No public exploit identified at time of analysis; however, an upstream fix has been submitted via openSUSE/libsolv GitHub PR #617, and Red Hat has acknowledged the issue via a dedicated security advisory.

Buffer Overflow vulnerability in Uncrustify Project Affected v.Uncrustify_d-0.82.0-132-bcc41cbdc and Fixed in commit 68e67b9a1435a1bb173b106fedb4a4f510972bdc allows a local attacker to cause a denial of service via the check_template.cpp, check_template function, tokenize_cleanup function, uncrustify executable components

Stack-based buffer overflow in libsolv's Debian metadata parser allows remote, unauthenticated attackers to cause a denial of service by serving maliciously crafted Debian repository metadata containing SHA384 or SHA512 checksum tags. The root cause, confirmed by the GitHub PR #616 diff, is a statically allocated 65-byte stack buffer in `ext/repo_deb.c` sized only for SHA256 digests, which is overflowed by the larger SHA384 (96 hex chars) and SHA512 (128 hex chars) values. No active exploitation has been confirmed (not in CISA KEV) and no public exploit code has been identified at time of analysis; an upstream fix is available as an open pull request.

Panic-triggered denial of service in Nimiq's core-rs-albatross (versions prior to 1.4.0) allows a network-level attacker to crash the node's RPC task by injecting a signed PeerContact with an empty addresses list into the libp2p peer discovery layer. The crash is deferred: the malicious contact is accepted and stored silently, but any subsequent call to get_address_book - from an RPC client or web client - triggers an unconditional Rust panic via .expect() on an empty iterator. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog, though the low attack complexity and network-accessible vector make casual exploitation plausible against any exposed node operator workflow.

Remote code execution in Google Chrome versions prior to 148.0.7778.179 allows a remote attacker to execute arbitrary code within the renderer sandbox via a crafted HTML page that triggers a use-after-free in the DOM implementation. The flaw requires user interaction (visiting a malicious page) but no authentication, and while Chromium rates its security severity as Medium, the CVSS 3.1 base score of 8.8 reflects high confidentiality, integrity, and availability impact. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV.

Remote code execution in Google Chrome versions prior to 148.0.7778.179 stems from a use-after-free flaw in the WebRTC component, enabling a remote attacker to run arbitrary code when a victim visits a crafted HTML page. Chromium rates the severity as High and the CVSS 3.1 score is 8.8, but exploitation requires user interaction (UI:R); no public exploit identified at time of analysis.

Remote code execution in Google Chrome on Windows prior to 148.0.7778.179 stems from a use-after-free flaw in the XR (WebXR) component, enabling a remote attacker to run arbitrary code in the renderer process by enticing a user to visit a crafted HTML page. Chromium rates the issue High severity and CVSS scores it 8.8; no public exploit identified at time of analysis and SSVC reports exploitation status as none. A vendor patch is available via the Stable Channel update referenced in the Chrome Releases advisory.

Remote code execution in Google Chrome versions prior to 148.0.7778.179 stems from a use-after-free condition in the QUIC networking stack, allowing remote attackers to execute arbitrary code within the browser sandbox via malicious network traffic. Exploitation requires user interaction (visiting a malicious site or processing attacker-controlled QUIC traffic), and no public exploit has been identified at time of analysis. Chromium rates this as High severity, and a vendor patch is available.

Remote code execution in Google Chrome on Windows prior to version 148.0.7778.179 stems from a use-after-free condition in the GPU component, enabling a remote attacker to run arbitrary code within the renderer sandbox after the victim loads a crafted HTML page. Google has rated the issue High severity and shipped a fix; no public exploit identified at time of analysis and SSVC indicates exploitation status 'none' despite total technical impact.

Remote code execution in Google Chrome on Linux before 148.0.7778.179 stems from a use-after-free flaw in the WebRTC component, allowing a remote attacker who lures a victim to a crafted HTML page to execute arbitrary code in the renderer process. Chromium rates the severity as Critical and a vendor patch is available, though there is no public exploit identified at time of analysis and SSVC indicates no observed exploitation. The CVSS 8.8 score reflects high impact across confidentiality, integrity, and availability with required user interaction (visiting a page).

MISP's CSP report endpoint in versions 2.5.0 through 2.5.37 accepts payloads up to 1 MB per report instead of the developer-intended 1 KB limit, due to a 1,024x magnitude error in the truncation guard (`1024 * 1024` instead of `1024`). On deployments where the endpoint is reachable by untrusted clients, unauthenticated remote parties (per CVSS PR:N) can abuse this discrepancy to flood application logs with oversized reports, contributing to disk exhaustion or log integrity degradation. No public exploit code exists and active exploitation has not been confirmed; the CVSS 4.0 score of 5.1 (Low-Medium) reflects the limited, availability-only impact.

Arbitrary file write in Altium Enterprise Server ComparisonService allows authenticated workspace users to escape the temporary upload directory and plant files anywhere on the host filesystem via crafted multipart Content-Disposition headers in the Gerber upload APIs. The flaw (CVSS 4.0 score 9.4, CWE-22) escalates to remote code execution by dropping payloads into web-accessible paths or overwriting service binaries, and a vendor patch is available. No public exploit identified at time of analysis.

Path traversal in NVIDIA BioNeMo Core for Linux allows remote attackers to escape intended directory boundaries when a user is induced to load a malicious file, enabling code execution, information disclosure, data tampering, or denial of service. The flaw carries a high CVSS score of 8.8 driven by network reachability and full CIA impact, though exploitation requires user interaction; no public exploit identified at time of analysis.

Arbitrary code execution in NVIDIA BioNemo Framework on Linux allows a local attacker to abuse unsafe deserialization of untrusted data (CWE-502), leading to code execution, denial of service, information disclosure, and data tampering. The CVSS 7.8 vector indicates local attack vector with required user interaction, and no public exploit has been identified at time of analysis.

Host impersonation and machine-in-the-middle attacks against NVIDIA DGX OS systems are possible because the factory provisioning process clones a base image that ships identical SSH host keys onto every similarly provisioned system, primarily affecting DGX Spark deployments. With a CVSS of 8.1 and a CWE-321 (Use of Hard-Coded Cryptographic Key) root cause, an unauthenticated network attacker who possesses the shared key material from any one device can impersonate peers, potentially leading to code execution, data tampering, privilege escalation, information disclosure, or denial of service. There is no public exploit identified at time of analysis and the CVE is not listed in CISA KEV.

Denial of Service in Splunk Enterprise and Splunk Cloud Platform allows a low-privileged authenticated user to render the entire instance non-functional by exploiting missing input validation in the `coldToFrozen.sh` script bundled with the `splunk_archiver` app. The script accepts arbitrary file paths and renames them without restricting operations to safe directories, enabling renaming of critical Splunk system directories. No public exploit or CISA KEV listing has been identified at time of analysis, but the low privilege requirement (PR:L per CVSS) makes this actionable for any authenticated non-admin user in multi-tenant or enterprise deployments. A vendor patch is available via advisory SVD-2026-0504.

BGP session flapping denial-of-service in Cisco NX-OS on Nexus 3000 and 9000 Series Switches exposes data-center routing infrastructure to disruption from unauthenticated remote attackers. The flaw resides in the enforce-first-as BGP feature, where incorrect parsing of a transitive BGP attribute causes an affected switch to drop its BGP peer session and enter a flap loop upon receiving a crafted BGP UPDATE message. No active exploitation has been confirmed (not in CISA KEV), and no public exploit code has been identified at time of analysis, though the Changed scope in the CVSS vector reflects that the instability can propagate beyond the directly attacked peer, amplifying network-wide impact.

Unauthenticated denial-of-service in phenixdigital phoenix_storybook (0.2.0 through versions before 1.1.0) lets a remote attacker crash the entire BEAM virtual machine by exhausting its atom table. Multiple LiveView event handlers in ExtraAssignsHelpers feed user-controlled strings into String.to_atom/1, and because BEAM atoms are never garbage-collected, ~1,048,576 unique attacker-supplied keys/values permanently consume the atom table and abort every application running on that node. No public exploit identified at time of analysis, but the upstream fix is in commit 96d5246 and version 1.1.0.

Unauthenticated resource exhaustion in Progress Software MOVEit Automation enables a low-privileged remote attacker to degrade availability by triggering excessive resource allocation without server-side throttling controls. Affecting all MOVEit Automation releases prior to 2025.0.11 and the 2025.1.x branch prior to 2025.1.7, successful exploitation results in limited availability impact (A:L per CVSS) against the targeted instance. No active exploitation has been confirmed by CISA KEV and no public exploit code has been identified at time of analysis; the vendor has released patched versions.

Unauthenticated remote flooding of Progress Software MOVEit Automation exploits a missing resource throttling control (CWE-770), allowing an attacker to degrade service availability without any credentials or user interaction. Affected versions span the 2025.0.x branch (before 2025.0.11) and the 2025.1.x branch (before 2025.1.7). Progress Software has released patched versions; no public exploit code or CISA KEV listing has been identified at time of analysis, though MOVEit products remain high-value targets given their history as enterprise MFT infrastructure.

Resource exhaustion in ISC BIND 9's resolver state machine allows remote unauthenticated attackers to trigger an unbounded resend loop by sending crafted DNS queries that activate bad-server retry conditions, degrading resolver availability. Multiple active release branches are affected across standard and Subscription Edition builds spanning versions 9.18.36 through 9.21.21. No public exploit has been identified and the vulnerability is not listed in CISA KEV; however, the fully network-accessible, zero-authentication attack vector makes every exposed BIND 9 resolver a potential target.

Remote denial of service in ISC BIND 9 named allows unauthenticated attackers to trigger assertion failures and crash the resolver by sending DNS messages with non-Internet classes (CHAOS, HESIOD) or meta-classes (ANY, NONE) through code paths involving recursion, dynamic UPDATE, NOTIFY, or IN-specific record processing in non-IN data. The flaw affects BIND 9.11.0 through 9.21.21 across both open-source and Supported Preview (S1) branches, with no public exploit identified at time of analysis. CVSS 7.5 reflects high availability impact with network-reachable, low-complexity, unauthenticated exploitation.

Denial of service in Microsoft Defender Antimalware Platform allows a local, unprivileged attacker to partially degrade availability with low attack complexity and no user interaction required. The CVSS 4.0 score reflects limited impact - confidentiality and integrity are unaffected, and availability impact is rated Low. Vendor patch is available via Microsoft Security Response Center; no public exploit identified at time of analysis and no CISA KEV listing.

Denial of service in 389-ds-base LDAP server allows remote unauthenticated attackers to exhaust CPU and heap memory by sending a single LDAP request packed with hundreds of thousands of minimal controls. Because get_ldapmessage_controls_ext() does not cap the per-message control count, the 2 MB default BER message limit is the only ceiling, and concurrent abuse causes worker thread starvation or OOM termination. No public exploit identified at time of analysis, and the issue is not on CISA KEV.

Heap use-after-free in Unbound's RPZ (Response Policy Zone) subsystem crashes the DNS resolver under a specific race condition affecting multi-threaded deployments. Versions 1.14.0 through 1.25.0 are affected when an RPZ zone with 'rpz-nsip' or 'rpz-nsdname' triggers is served via XFR (zone transfer) and a simultaneous read occurs in another thread. The crash is remotely triggerable by timing a DNS query against an in-progress XFR, but requires multiple co-occurring non-default conditions; no public exploit exists and no active exploitation has been confirmed.

Denial of service in NLnet Labs Unbound 1.25.0 and earlier allows remote unauthenticated attackers to exhaust CPU resources by querying for content from a specially crafted malicious DNS zone containing very large RRsets whose records share no suffix above the root. The name compression logic fails to increment its bounding counter in this edge-case code path, causing an unbounded CPU-locking loop until packet construction completes. This is a complement fix to CVE-2024-8508, which introduced a compression limit in 1.21.1 that did not cover this specific bypass scenario; no public exploit has been identified at time of analysis.

Remote denial of service in NLnet Labs Unbound recursive DNS resolver (versions up to and including 1.25.0) allows an attacker controlling a DNSSEC-signed domain to crash the resolver process with a single crafted query. The DNSSEC validator uses an incorrect counter when computing write offsets for ADDITIONAL section rrsets while building chase-reply messages, leaving an uninitialized pointer that is later dereferenced. No public exploit identified at time of analysis, and the issue is fixed in Unbound 1.25.1.

Heap overflow denial-of-service in NLnet Labs Unbound recursive DNS resolver versions 1.14.0 through 1.25.0 allows remote unauthenticated attackers to crash the resolver by sending DNS queries containing multiple NSID, DNS Cookie, and/or EDNS Padding options. The flaw stems from a numeric truncation in EDNS field size calculation that lets attacker-influenced data overflow the response buffer. No public exploit identified at time of analysis and not listed in CISA KEV, but the impact is service-wide DNS outage for any user of an affected resolver.