Information Disclosure

In the Linux kernel, the following vulnerability has been resolved: media: em28xx: defer audio-only extension registration The audio-only path registers extensions while probing the primary device. For a dual-TS board, this happens before dev_next is created. The duplicate device inherits is_audio_only and is then independently inserted into em28xx_devlist. The list is intended to contain only primary devices: extension operations reach the secondary device through dev_next. The independently linked secondary can be freed during disconnect while its list node remains reachable, resulting in a use-after-free. Defer audio-only extension registration to the module-request work item. It runs only after probing has completed construction of the optional secondary device, so only the primary is registered and extension callbacks reach the secondary through dev_next.

In the Linux kernel, the following vulnerability has been resolved: media: em28xx: fix use-after-free of dev_next->devlist on disconnect When a device with has_dual_ts=1 is probed and the is_audio_only path is taken, both dev and dev->dev_next are added to the global em28xx_devlist via em28xx_init_extension(). However, during disconnect, em28xx_close_extension(dev) only calls list_del(&dev->devlist), leaving dev->dev_next->devlist still linked in the global list. When dev_next is subsequently freed via kref_put(), its devlist entry becomes a dangling pointer in em28xx_devlist. The next device probe that calls em28xx_init_extension() triggers a list corruption BUG when list_add_tail detects the freed node. This bug was exposed by commit a368ecde8a50 ("USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor") which clears reserved bits in bEndpointAddress during endpoint parsing. This causes fuzzed endpoint addresses like 0xf3 to be normalized to 0x83, which em28xx interprets as a vendor audio endpoint, enabling the is_audio_only + has_dual_ts code path that was previously unreachable with such descriptors. Fix this by removing dev->dev_next->devlist from the global list in em28xx_close_extension() before the device is freed.

In the Linux kernel, the following vulnerability has been resolved: media: i2c: imx415: Release runtime PM reference on VBLANK error The VBLANK path returned immediately when programming VMAX failed after pm_runtime_get_if_in_use() had taken a runtime PM reference. Break out of the switch instead so the common pm_runtime_put() path is used.

In the Linux kernel, the following vulnerability has been resolved: media: intel/ipu6: fix async notifier cleanup leak on parse error isys_notifier_init() calls v4l2_async_nf_init() and then adds fwnode remote subdevs in a loop with v4l2_async_nf_add_fwnode_remote(). If an endpoint parse or add fails partway through the loop, it jumps to err_parse and returns without calling v4l2_async_nf_cleanup(), leaking every v4l2_async_connection already added to the notifier's waiting list. The register-failure path just below already cleans up correctly, and the caller only tears the notifier down (isys_notifier_cleanup()) once isys_notifier_init() has returned success. Clean up the notifier on the parse error path too.

In the Linux kernel, the following vulnerability has been resolved: media: platform: mtk-mdp3: fix NULL deref on failed SCP lookup Add the missing sanity check after looking up the SCP to avoid dereferencing a NULL-pointer in case its driver has not yet been bound.

In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix DMA leak rtl2832_sdr_remove() runs on USB disconnect and clears dev->udev to NULL before any pending streaming teardown has run. When user space later closes its file descriptor, vb2 calls rtl2832_sdr_stop_streaming() which in turn calls rtl2832_sdr_free_stream_bufs(). That helper releases each coherent buffer with: usb_free_coherent(dev->udev, dev->buf_size, dev->buf_list[dev->buf_num], dev->dma_addr[dev->buf_num]); usb_free_coherent() returns immediately when its dev argument is NULL, so every DMA stream buffer that was live at disconnect is silently leaked. The URBs allocated in rtl2832_sdr_alloc_urbs() outlive the device for the same reason. The rtl2832_sdr driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&dev->vdev) with vb2_video_unregister_device(&dev->vdev) and move it before clearing dev->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs rtl2832_sdr_stop_streaming() if streaming is active, so URBs and coherent DMA stream buffers are freed while dev->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&dev->vb_queue_lock) / mutex_lock(&dev->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around dev->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/

In the Linux kernel, the following vulnerability has been resolved: media: s2255: bound JPEG frame size before copying into the buffer s2255_fillbuff() memcpy()s vc->jpg_size bytes of a captured JPEG/MJPEG frame into the vb2 plane. vc->jpg_size is taken verbatim from the S2255_MARKER_FRAME header the device sends (pdword[4] in save_frame()) and, unlike the frame payload length just above it, is never bounded: payload = le32_to_cpu(pdword[3]); if (payload > vc->req_image_size) /* payload is checked ... */ return -EINVAL; vc->pkt_size = payload; vc->jpg_size = le32_to_cpu(pdword[4]); /* ... jpg_size is not */ A malicious or malfunctioning device can therefore report a jpg_size larger than the destination vb2 plane, and the memcpy() writes past it. jpg_size is a signed int, so a value with the top bit set also turns into a huge length. Reject a frame whose jpg_size is negative or exceeds the plane size before copying it.

In the Linux kernel, the following vulnerability has been resolved: media: s2255: check firmware size before reading trailing marker s2255_probe() reads a 4-byte marker and version from the last 8 bytes of the firmware blob (fw->data[fw_size - 8] and [fw_size - 4]). If the firmware file is shorter than 8 bytes, fw_size - 8 underflows and the access reads out of bounds. Validate the firmware size before indexing.

In the Linux kernel, the following vulnerability has been resolved: media: v4l2-async: avoid deleting unlinked ASC entry on link error v4l2_async_match_notify() creates ancillary media links before adding asc->asc_subdev_entry to sd->asc_list. If ancillary link creation fails, the function jumps to err_call_unbind while asc_subdev_entry has not been linked yet. Async connections are zero-allocated, so the list entry still has NULL next and prev pointers on this path. Calling list_del() on it can therefore dereference NULL instead of returning the original link creation error. Do not delete asc_subdev_entry from err_call_unbind. There is no list insertion to undo on this path; the bound callback and sub-device registration are the operations that need to be rolled back.

In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix fwnode leak in v4l2_fwnode_parse_link In v4l2_fwnode_parse_link(), the remote endpoint fwnode reference is acquired using fwnode_graph_get_remote_endpoint(). This reference is properly released in the error paths, but it is leaked on the success path. Add the missing fwnode_handle_put() before returning 0 to prevent the reference leak. [Sakari Ailus: Fix subject prefix and coding style a little.]

In the Linux kernel, the following vulnerability has been resolved: media: qcom: iris: use disable_irq() during power-off The IRQ is registered as a threaded IRQ. Using disable_irq_nosync() in iris_vpu_power_off() does not wait for an already queued threaded IRQ handler to complete before returning. As a result, a threaded IRQ handler may still run after the VPU has been powered down and access hardware registers after power-off. Replace disable_irq_nosync() with disable_irq() so the power-off path waits for any in-flight threaded IRQ handler to complete before returning.

In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Defer job_finish() only when a DEC_PIC was queued Decoder instances sharing a VPU also share one v4l2_m2m job slot, released when the running context calls v4l2_m2m_job_finish(). While draining, device_run() defers job_finish() once EOS is sent (sent_eos), expecting a later finish_decode() (from a DEC_PIC completion IRQ) to release the slot. But the m2m core checks job_ready() only when a job is queued, not when it is dispatched. A job queued while draining can run after finish_decode() has already moved the instance to STOP and sent EOS. device_run() then runs in STOP, issues no DEC_PIC, yet still skips job_finish() - so no IRQ, no finish_decode(), and the shared slot is leaked, stalling every instance. With several v4l2h264dec instances in parallel, GStreamer hangs at EOS. Track whether the run actually queued a DEC_PIC (cmd_issued) and defer job_finish() only then. Otherwise finish the job immediately

In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Resume device before setting EOS flag Setting the EOS flag talks to the firmware via send_firmware_command(), which accesses VPU registers. Both the STREAMOFF path (wave5_vpu_dec_job_abort()) and the V4L2_DEC_CMD_STOP path (wave5_vpu_dec_stop()) can run while the device is runtime suspended, so those register accesses hit powered-down hardware and the SoC raises an asynchronous SError, panicking the kernel: SError Interrupt on CPU3, code 0x00000000bf000000 -- SError send_firmware_command+0x2c/0x160 [wave5] wave5_vpu_dec_set_bitstream_flag+0x6c/0x80 [wave5] wave5_vpu_dec_update_bitstream_buffer+0x80/0xec [wave5] wave5_vpu_dec_job_abort+0x44/0xa0 [wave5] v4l2_m2m_cancel_job+0x110/0x19c [v4l2_mem2mem] v4l2_m2m_streamoff+0x24/0x140 [v4l2_mem2mem] Resume the device with pm_runtime_resume_and_get() around the EOS firmware command and release it with pm_runtime_put_autosuspend(), matching the runtime PM handling already done in wave5_vpu_dec_device_run().

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers The FRU and I2C bsg handlers stage their transfer in a DMA_POOL_SIZE (256-byte) bounce buffer obtained from dma_pool_alloc(), which does not zero the allocation. They initialize only a few leading bytes before handing the buffer to qla2x00_write_sfp(). qla2x00_write_sfp() can override the transfer length with a user-supplied value: if (len == 1) opt |= BIT_0; if (opt & BIT_0) len = *sfp; *sfp is the first byte of the (user-controlled) payload, so len can grow up to 255. The device then DMA-reads len bytes from the 256-byte pool buffer. Since only a small prefix was written (e.g. MAX_FRU_SIZE == 36 bytes for a FRU version, one byte for a FRU status register), the hardware reads past the initialized region and writes up to ~219 bytes of stale DMA-pool heap memory to the device flash. Allocate the buffer with dma_pool_zalloc() in all five FRU/I2C handlers so any bytes beyond the initialized data are zero rather than stale heap contents.

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix BSG job leak on validate flash image error path qla28xx_validate_flash_image() returns QLA_SUCCESS (0) unconditionally, telling the FC BSG transport (fc_bsg_host_dispatch()) that the driver owns and will complete the request. But bsg_job_done() is guarded by "if (!rval)", so on the error path (rval == -EINVAL) neither the driver nor the transport completes the job. The request dangles until it times out, leaking block layer resources. Commit c2c68225b145 ("scsi: qla2xxx: Fix bsg_done() causing double free") added the "if (!rval)" guard to a batch of BSG handlers. That is correct for handlers that also return the error code (the transport then completes the job once via fail_host_msg), but this function returns QLA_SUCCESS unconditionally, so the guard turned a correct single completion into a leak. Always call bsg_job_done(): bsg_reply->result is DID_OK and the error is reported in vendor_rsp[0], and since the function returns 0 the transport will not complete the job a second time.

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero dport diagnostics buffer to avoid info leak qla2x00_do_dport_diagnostics() allocates the qla_dport_diag response buffer with kmalloc_obj() (non-zeroing) and, on success, copies the full sizeof(*dd) back to user space via sg_copy_from_buffer(). The inbound sg_copy_to_buffer() only fills as many bytes as the user request payload provides, and qla26xx_dport_diagnostics() zeroes only dd->buf. The options and unused[] fields are therefore copied out uninitialized, leaking kernel heap contents to user space. Allocate with kzalloc_obj(), matching qla2x00_do_dport_diagnostics_v2().

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound image count in qla2x00_update_fru_versions() qla2x00_update_fru_versions() copies the user-supplied BSG request into a fixed 256-byte stack buffer (bsg[DMA_POOL_SIZE]) and then iterates list->count times over the qla_image_version array embedded in that buffer, advancing the image pointer each iteration. count is taken directly from user input with no upper bound, while only (DMA_POOL_SIZE - sizeof(list->count)) / sizeof(struct qla_image_version) = 6 entries actually fit. A larger count walks the image pointer off the end of the stack buffer, reading adjacent kernel stack memory and sending it to the device via qla2x00_write_sfp(). Reject requests whose declared count does not fit in the buffer.

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Serialize flash version read in reset handler The "update cache versions without reset" sysfs reset operation (0x20261) calls get_flash_version(), which reads hardware flash registers, without holding ha->optrom_mutex. The VPD update path serializes the same call under optrom_mutex, so this reset path can interleave its flash register accesses with a concurrent VPD or optrom flash operation and corrupt the reads. Hold ha->optrom_mutex across the get_flash_version() call to match the VPD update path.

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix FCE trace use-after-free during firmware dump qla2x00_free_fce_trace() freed and cleared ha->fce while holding only fce_mutex. The firmware-dump consumers qla27xx_fwdt_entry_t264() and qla25xx_copy_fce() read ha->fce (NULL check followed by a copy of the buffer) under hardware_lock and never take fce_mutex. A debugfs FCE disable could therefore free the DMA buffer between a dump's NULL check and its copy, resulting in a use-after-free. Unpublish ha->fce under hardware_lock, then release the lock and free the DMA buffer (dma_free_coherent() may sleep). A concurrent dump either completes its check and copy with the buffer still valid, or observes ha->fce == NULL and skips it.

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero mailbox struct in qla2x00_get_firmware_state() The mbx_cmd_t is allocated on the stack but left uninitialized. qla2x00_mailbox_command() has several early-return paths (PCI permanent failure, device failed, EEH busy, ISP abort pending, mailbox access timeout, purge mbox) that return without writing the input mailbox registers back into mcp->mb[]. qla2x00_get_firmware_state() then unconditionally copies mcp->mb[1..6] (and mb[12]) into the caller's states[] array regardless of the return value. On such a failure the copied values are uninitialized kernel stack memory, which is then exposed to userspace via the fw_state and mpi_fw_state sysfs handlers. Zero the mailbox struct so a failed query yields deterministic zeroed state instead of leaking stack contents.

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix FCE trace enable parsing in debugfs qla2x00_dfs_fce_write() called kstrtoul() with a NULL result pointer, so a successful parse would dereference NULL and oops. Worse, the int return value (0 on success, negative errno on failure) was assigned to the unsigned long enable flag, inverting the intended logic: a valid number was treated as "disable" while a parse failure enabled FCE. Parse the value into enable and propagate parse errors to userspace.

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Don't query firmware state while chip is down qla2x00_fw_state_show() initializes rval to QLA_FUNCTION_FAILED and jumps to the out: label when the chip is down or EEH is busy. The out: block then re-issued qla2x00_get_firmware_state() because rval != QLA_SUCCESS, defeating the chip-down/EEH-busy guards and issuing a mailbox command (outside optrom_mutex) during ISP reset or PCI error recovery, which can hang the adapter. It also turned a normal in-lock mailbox failure into a second unsynchronized mailbox attempt. Make the out: fallback only mark the firmware state as unknown. The mailbox is now issued at most once, inside optrom_mutex, and only when the chip is up and not EEH-busy.

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Avoid req_q_map double-read in qla2x00_error_entry() qla2x00_error_entry() reads ha->req_q_map[que] twice: once for the NULL check and again when assigning it to req. The map slot is cleared by qla25xx_free_req_que() (ha->req_q_map[que_id] = NULL under mq_lock) during queue teardown, while the response-queue interrupt that drives qla2x00_error_entry() is still registered (the IRQ is released later in qla25xx_free_rsp_que()). If the slot is set to NULL between the two reads, req becomes NULL and is dereferenced. Read the slot once into req and NULL-check the local before use. mq_lock is a mutex and cannot be taken from interrupt context, so the single read plus local check is the appropriate fix for the reported NULL dereference.

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak Several bsg handlers stage their request/reply in an uninitialized 256-byte on-stack buffer (uint8_t bsg[DMA_POOL_SIZE]) and fill it via sg_copy_to_buffer(), which only copies as many bytes as the user-supplied request payload. When the request is shorter than the structure, the remainder of the buffer is left holding stale stack data. qla2x00_read_fru_status() and qla2x00_read_i2c() then copy the full structure back to the reply payload with sg_copy_from_buffer(), leaking the uninitialized stack bytes to user space. The write/update paths do not copy the buffer back, but can feed uninitialized fields to the device. Zero the stack buffer at declaration in all five handlers, mirroring the heap kzalloc() approach, so short requests can no longer expose stale memory.

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Skip NVMe LS reject IOCB when FW not started qla_nvme_xmt_ls_rsp() bails out to the out: label when firmware is not started (!ha->flags.fw_started), but the out: path unconditionally calls qla_nvme_ls_reject_iocb(), which ends in qla2x00_start_iocbs() and an unconditional doorbell write to the request queue in-pointer register. This rings the firmware doorbell and queues an IOCB that stopped or resetting firmware cannot consume, and touches MMIO during the reset/EEH window where fw_started is also clear. Only emit the LS reject IOCB (and ring the doorbell) when fw_started is set; otherwise just clean up and return. The post-allocation failure cases (SRB alloc / qla2x00_start_sp() failure) run with firmware started and still send the reject. Apply the same guard to the reject emission in qla2xxx_process_purls_pkt().

In the Linux kernel, the following vulnerability has been resolved: f2fs: use the mount idmap for the owner check in f2fs_xattr_advise_set() f2fs_xattr_advise_set() calls inode_owner_or_capable() with &nop_mnt_idmap before allowing the "system.advise" xattr to be set, instead of the idmap that the VFS passes to the ->set() handler. f2fs supports idmapped mounts, so on such a mount this checks the caller's fsuid against the unmapped on-disk owner rather than the mapped owner: the actual owner can be wrongly denied with -EPERM and an unrelated caller wrongly allowed. Pass the handler's idmap instead.

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix dentry folio leak in find_in_level find_in_level() gets a dentry folio with f2fs_find_data_folio() before calling find_in_block(). If find_in_block() returns an error, the function stores the error in res_folio and breaks out of the loop without dropping the dentry folio. This leaks the folio reference on the find_in_block() error path. Drop the dentry folio before returning the error to the caller.

In the Linux kernel, the following vulnerability has been resolved: f2fs: avoid NULL checkpoint thread access in sysfs checkpoint_merge can be enabled even when no checkpoint merge thread is running. A read-only mount is one case: f2fs does not start f2fs_issue_ckpt there, but ckpt_thread_ioprio is still writable through sysfs. The ckpt_thread_ioprio store path updates the saved ioprio value and, when checkpoint_merge is enabled, calls set_task_ioprio() for the checkpoint thread. If cprc->f2fs_issue_ckpt is NULL, that dereferences a NULL task pointer. Protect ckpt_thread_ioprio sysfs writes with s_umount as well, so the checkpoint thread cannot disappear under the store path while updating its ioprio.

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid potential deadloop in f2fs_fsync_node_pages() There is potential deadloop in race condition: Thread A Thread B - fsync - f2fs_do_sync_file - f2fs_fsync_node_pages - last_fsync_dnode - folio_get(last_folio) - f2fs_setattr - f2fs_truncate - f2fs_truncate_blocks - f2fs_do_truncate_blocks - f2fs_truncate_inode_blocks - truncate_dnode - truncate_node - invalidate_mapping_pages - folio->mapping = NULL - is_node_folio alwasy return false - atomic && !marked is always true, then goto retry

In the Linux kernel, the following vulnerability has been resolved: f2fs: protect critical_task_priority updates with s_umount The sysfs store path already takes s_umount for GC thread control entries, and ckpt_thread_ioprio is covered as well. critical_task_priority also updates checkpoint or GC kthread scheduling state, but it is not covered by that serialization. It can race with remount or teardown paths that are stopping those threads. Protect critical_task_priority sysfs writes with s_umount too.

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix valid block count leak on data block allocation failure In __allocate_data_block(), when allocating a new data block (dn->data_blkaddr == NULL_ADDR), inc_valid_block_count() is called first to increment total_valid_block_count and i_blocks. If the subsequent f2fs_allocate_data_block() fails, the function returns the error directly without rolling back the already-incremented block counts, causing a permanent leak. Fix this by calling dec_valid_block_count() to undo the increment before returning the error. The condition old_blkaddr == NULL_ADDR precisely identifies the case where inc_valid_block_count() was called.

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: avoid force-completing uninitialized UVD rings uvd_v7_0_sw_init() does not initialize the UVD decode ring for an SR-IOV VF. However, amdgpu_uvd_resume() unconditionally force-completes the decode ring when restoring its fence sequence. Skip fence completion when the fence driver is not initialized.

In the Linux kernel, the following vulnerability has been resolved: drm/panel-edp: fix i2c adapter leak on probe failure Make sure to drop the i2c adapter reference on probe failure (e.g. probe deferral) and on driver unbind also if a devicetree redundantly uses the 'ddc-i2c-bus' property to point to the aux ddc bus.

In the Linux kernel, the following vulnerability has been resolved: drm/i915: Guard against NULL driver_data in i915_pci_probe() pci_match_device() can return the dummy pci_device_id_any entry when a device is force-bound via sysfs driver_override, in which case ->driver_data is unset (NULL). i915_pci_probe() casts it to struct intel_device_info * unconditionally and dereferences intel_info->require_force_probe, causing a NULL-ptr-deref. (cherry picked from commit 2727922084672cc274ecea726ea00363c2893731)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: avoid divide-by-zero in __is_lut_linear() __is_lut_linear() computes the expected value of each entry with expected = i * MAX_DRM_LUT_VALUE / (size - 1); If it is ever called with a single-entry LUT, size - 1 is zero and the kernel takes a divide error (#DE). A LUT with fewer than two entries cannot describe a linear mapping anyway, so return false early instead of dividing by zero.

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix dc_lock leak on GPU reset error paths On GPU reset, dm_suspend() takes dc_lock and leaves it for dm_resume() to drop. If amdgpu_dm_commit_zero_streams() or dm_dmub_hw_init() fails, the function returns with the lock still held. The matching resume path is then skipped, so every later dc_lock take hangs. Release the cached DC state and unlock before returning the error.

In the Linux kernel, the following vulnerability has been resolved: drm/gud: NUL-terminate TV mode names read from the device gud_connector_add_tv_mode() reads a buffer of fixed-size mode names from the USB device and passes pointers into it to drm_mode_create_tv_properties_legacy(), which calls strlen() on each one. Nothing guarantees the device NUL-terminates a name, so strlen() can run past the end of a slot and, for the last mode, past the end of the allocation. Terminate each name at the end of its slot before use.

In the Linux kernel, the following vulnerability has been resolved: drm: Fix drm_crtc_commit leak if signaled when PAGE_FLIP_EVENT is used Commit 1c6ceeee6ebb ("drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits") fixed a very similar issue when the event was allocated by drm_atomic_helper_setup_commit() itself. However, if the event is allocated in prepare_signaling(), it will also be set to NULL in complete_signaling(), which prevents drm_crtc_commit from being put in __drm_atomic_helper_crtc_destroy_state(). Dropping the reference when the event is set to NULL at complete_signaling() fixes the leak. The leak can be reproduced by sending a signal to the thread using DRM_MODE_PAGE_FLIP_EVENT and using a sw_sync fence to cause the atomic ioctl to block at drm_atomic_helper_wait_for_fences(). It happened both with amdgpu and vkms.

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: force complete the KIQ ring fences on reset Like the MES scheduler ring, the KIQ ring sets no_scheduler = true and uses a polling fence, so it is skipped by the force-completion loop in amdgpu_device_pre_asic_reset(). Its hw fence value lives in wb (GTT) memory and survives a MODE1 reset while fence_drv.sync_seq keeps advancing, so after a reset the first KIQ submission can poll forever on a seq that is never written back. Force complete the KIQ ring fences too so their hw fence is realigned to sync_seq.

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: force complete the MES ring fences on reset The MES scheduler ring has no drm scheduler (no_scheduler = true), so it is skipped by the force-completion loop in amdgpu_device_pre_asic_reset(). It uses a polling fence whose hw value lives in wb (GTT) memory and survives a MODE1 reset, while fence_drv.sync_seq keeps advancing for every packet. When the reset is triggered because MES itself stopped responding, the timed-out packets advance sync_seq past the last hw fence value MES wrote. After resume the first MES submission polls forever on a seq that is never written back, failing the resume and wedging the box on a second reset: amdgpu: MES ring buffer is full. amdgpu: *ERROR* ring gfx_0.0.0 test failed (-110) amdgpu: resume of IP block <gfx_v11_0> failed -110 amdgpu: GPU reset end with ret = -110 Force complete the MES scheduler ring fences together with the scheduler rings so their hw fence is realigned to sync_seq. v2: cover all XCCs (one scheduler ring each), not just mes.ring[0].

In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/uvmm: fix NULL deref unwinding an OP_MAP_SPARSE op Each bind_job_op is zeroed by kzalloc_obj() in bind_job_op_from_uop(), and the OP_MAP_SPARSE case in nouveau_uvmm_bind_job_submit() only creates a region, so op->ops stays NULL for a successfully processed sparse map. If a later op in the same job fails, the reverse unwind loop revisits that op and calls drm_gpuva_ops_free(&uvmm->base, op->ops) unconditionally. drm_gpuva_ops_free() dereferences its argument right away (list_for_each_entry_safe on &ops->list), so a NULL op->ops oopses. The path is reachable by any render-node fd holder, since NOUVEAU_VM_BIND is DRM_RENDER_ALLOW. Guard the free with IS_ERR_OR_NULL(), as nouveau_uvmm_bind_job_cleanup() already does for the identical free.

In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/uvmm: clear the dirty flag when unwinding an OP_UNMAP_SPARSE A successful OP_UNMAP_SPARSE marks its region dirty with nouveau_uvma_region_dirty() and defers the teardown to nouveau_uvmm_bind_job_cleanup(); it does not remove the region from uvmm->region_mt. If a later op in the job fails, the unwind path never clears reg->dirty (set in one place, cleared nowhere) and sets op->reg = NULL, so cleanup skips the teardown. The region is left in the tree with dirty set and its completion never signalled. Later binds over that range then fail permanently -- -ENOENT or -EINVAL from the dirty checks, or an unkillable wait_for_completion() in bind_validate_region() -- for the lifetime of the uvmm. Clear reg->dirty when the unwind reverts the sparse unmap, restoring the region to the state it was found in.

In the Linux kernel, the following vulnerability has been resolved: rpcrdma: arm rn_done before publishing the notification rpcrdma_rn_register() inserts @rn into rd_xa with xa_alloc() before storing the caller's callback in rn->rn_done. The xarray makes @rn reachable to rpcrdma_remove_one(), which walks rd_xa and invokes rn->rn_done(rn) for every registered notification. A device removal that races a fresh registration can therefore observe @rn with rn_done still NULL, because the notification objects are zero allocated by their owners, and call through a NULL function pointer. Store rn->rn_done before xa_alloc() publishes @rn. The xarray's store-side and load-side ordering then guarantees that any CPU which finds @rn in rd_xa also observes the armed callback. rpcrdma_rn_unregister() treats a non-NULL rn_done as the sentinel for a completed registration, so the early store must not survive a failed registration. Clear rn_done again when xa_alloc() fails. Were it left set, the failed-accept cleanup path would call rpcrdma_rn_unregister() on an @rn that was never inserted, erasing an unrelated rd_xa slot and underflowing rd_kref.

In the Linux kernel, the following vulnerability has been resolved: power: supply: ab8500_fg: fix use-after-free on remove ab8500_fg_remove() destroys the driver workqueue while the threaded interrupt handlers are still armed; they are devm-managed and freed only after ->remove() returns, so a handler that fires in that window queues work on the freed workqueue. Tear the workqueue down through devm instead, registering its cleanup after the power supply and before the interrupt requests. devm then frees the interrupts first, so the handlers can no longer queue work, before disabling the delayed and plain work items and destroying the workqueue. Disabling the items, rather than cancelling them, keeps them disabled so no producer (including the power-supply external_power_changed callback) can requeue them. Found by an in-house static analysis tool.

In the Linux kernel, the following vulnerability has been resolved: ksmbd: zero pipe read compound padding Compound response handling extends the last response iov to an eight-byte boundary. smb2_read_pipe() allocates only the payload size, so the alignment padding can expose up to seven bytes of uninitialized kernel heap memory. Allocate the aligned size and clear the unused tail before pinning the response buffer.

Arista EOS devices configured with SNMPv3 users store the one-way hashed, localized SNMPv3 authentication key inside the running configuration and, notably, inside sanitized configuration exports, so any authenticated user who can read either artifact obtains reusable credential material for that device's SNMP engine. With that material an attacker can issue unauthorized SNMP read operations against MIB tables or inject fraudulent trap notifications into the Network Management System, though there is no configuration-write or availability impact. The vendor discovered the flaw internally, states it is unaware of malicious exploitation in customer networks, and no public exploit code has been identified at time of analysis; the CVSS 3.1 base score is 4.2 (AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N), with exploitation gated on SNMPv3 being in use and on the attacker already holding authenticated device access or a leaked sanitized configuration.

Local attackers with authenticated access can retrieve cleartext-stored credentials from the Fermax DuoxMe Android app versions prior to 4.3.4 and impersonate the user account. This CWE-312 vulnerability requires local access to the device, and on non-rooted devices the app sandbox normally protects the data, so root or device-level access is the practical prerequisite. No public exploit code has been identified at time of analysis, and the risk is assessed as a modest-severity local issue.

Arista EOS devices that run OpenConfig-based management services (gNMI, gNSI, RESTCONF, NETCONF) can inadvertently write sensitive request and response payloads into logs that persist on the local switch or are forwarded to remote accounting/AAA servers. The leaked material includes plaintext CLI secrets such as 'username bob secret myPass' and sensitive OpenConfig YANG leafs like system/aaa/global/tacacs/config/secret-key, so the exposure is a credential/secret disclosure problem rather than an integrity or availability issue. Exploitation requires that those services be enabled, that secrets actually transit them, and that an attacker obtain read access to the resulting log or accounting sinks; triggering also requires an authenticated actor (PR:L) and some user interaction (UI:P) per the assessed vector. The issue was found internally by Arista, which states it has no evidence of malicious exploitation in customer networks, and no public exploit code has been identified at time of analysis. gRPC-based streaming telemetry from the Streaming Telemetry Agent to CloudVision is explicitly not affected.

In the Linux kernel, the following vulnerability has been resolved: ext4: check dir entry fits before reading the hash trailer in ext4_search_dir() For casefolded encrypted directories ext4 stores an 8-byte hash trailer after the name (EXT4_DIRENT_HASHES()), at an offset derived from de->name_len. On the sb_no_casefold_compat_fallback() path ext4_match() reads that trailer, but ext4_search_dir()'s by-hand pre-check only tests de->name + de->name_len <= dlimit, which proves the name fits, not the rounded trailer. A crafted entry whose name ends at the block boundary passes the check while EXT4_DIRENT_HASHES(de) lands past the block end, so ext4_match() reads out of bounds on an ordinary lookup. KASAN reports it as a use-after-free when the page after the directory block holds a freed object: BUG: KASAN: use-after-free in ext4_match (fs/ext4/namei.c:1435) Read of size 4 at addr ffff888010458000 by task exploit Call Trace: ext4_match (fs/ext4/namei.c:1435) ext4_search_dir (fs/ext4/namei.c:1470) __ext4_find_entry (fs/ext4/namei.c:1268 fs/ext4/namei.c:1632) ext4_lookup (fs/ext4/namei.c:1703 fs/ext4/namei.c:1769) ... filename_lookup (fs/namei.c:2842) vfs_statx (fs/stat.c:353) __do_sys_newfstatat (fs/stat.c:538) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Require, for hash-in-dirent directories, that the whole entry including the rounded trailer fits before calling ext4_match(). This is the same bound ext4_check_dir_entry() already enforces via ext4_dir_rec_len(), so no well-formed entry is rejected. The other caller, ext4_find_dest_de(), runs ext4_check_dir_entry() first and is unaffected.

In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: restore skb->dev on deaggregated frames rmnet_map_deaggregate() allocates each sub-frame with alloc_skb() and leaves skb->dev NULL. __rmnet_map_ingress_handler() assigns skb->dev = ep->egress_dev only on the data path, but a MAP command frame is dispatched to rmnet_map_command() before that, so rmnet_map_send_ack() runs netif_tx_lock(skb->dev) on a NULL device. An unprivileged user reaches this by unsharing a user+net namespace, creating an rmnet link over a tap device with INGRESS_DEAGGREGATION and INGRESS_MAP_COMMANDS, and writing an aggregated frame carrying a flow-control command to the tap fd. Restore the assignment dropped by 378e25357ac7, so every skb leaving rmnet_map_deaggregate() has a valid device. BUG: KASAN: null-ptr-deref in _raw_spin_lock (kernel/locking/spinlock.c:158) Write of size 4 at addr 00000000000004b4 by task exploit/144 Call Trace: _raw_spin_lock (kernel/locking/spinlock.c:158) netif_tx_lock (net/sched/sch_generic.c:497) rmnet_map_command (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c:67) rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:125) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6103) ... __netif_receive_skb_one_core (net/core/dev.c:6214) netif_receive_skb (net/core/dev.c:6474) tun_get_user (drivers/net/tun.c:1966) tun_chr_write_iter (drivers/net/tun.c:2012) vfs_write (fs/read_write.c:687) ksys_write (fs/read_write.c:739) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception in interrupt

In the Linux kernel, the following vulnerability has been resolved: vxlan: vnifilter: enforce exact length of GROUP/GROUP6 attributes The VXLAN VNI filter entry policy declares the GROUP/GROUP6 address attributes as NLA_BINARY with only a maximum length, so validate_nla() accepts a payload shorter than the address. The GROUP consumer reads it with nla_get_in_addr(), an unconditional 4-byte load, so a short attribute over-reads up to 3 bytes of uninitialised slab data, which are stored into remote_ip and echoed back via RTM_GETTUNNEL, disclosing kernel memory. Switch both entries to NLA_POLICY_EXACT_LEN() so the validator rejects any GROUP/GROUP6 that is not exactly 4 / 16 bytes; a valid address is always sent at full width.

Unbound versions 1.22.0 through 1.26.1 built with DNS-over-QUIC support (--with-libngtcp2) can be driven to an abnormal exit by an unauthenticated remote attacker who manipulates QUIC stream state. The attacker sends a DoQ query, withholds ACKs, issues RESET_STREAM to free the per-stream output buffer, then waits for a PTO timeout so ngtcp2 re-encodes a STREAM frame from the freed memory; a spray of roughly 20 such queries forces the daemon down. Default builds compiled without QUIC support are not affected, and exploitation also requires precise timing against the QUIC state machine, making this a moderate, configuration-gated availability threat rather than a top-tier priority. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the authoritative assessment rates it AV:N/AC:H/PR:N/UI:N/S:U with low confidentiality and high availability impact, so the practical outcome is denial of service against the resolver rather than broad data compromise.

An authorization bypass in the Ash framework (Elixir) lets authenticated, lower-privileged actors recover values they are not permitted to see by using filtered calculations or aggregates as a yes/no oracle. Ash field policies are designed to protect against filter-based disclosure by rewriting references to forbidden attributes into an expression that evaluates to nil, but prior to 3.33.4 that rewriting only matched Ash.Resource.* structs and not Ash.Query.Calculation or Ash.Query.Aggregate structs, so filters on those ran against real values. Any application that uses Ash.Policy.Authorizer with field policies on calculations or aggregates and exposes filter arguments (commonly via AshGraphql or AshJsonApi) is affected; no public exploit identified at time of analysis, and the disclosure is gradual - one probe at a time - with no integrity or availability impact.

ZenHive mpp (MPP.Plug payment middleware for Elixir/Phoenix) versions 0.1.0 through 0.16.1 can allow a shared HTTP cache - a CDN or reverse proxy - to store a paid 200 response together with its Payment-Receipt header and replay both to clients that never paid, because the library's own Cache-Control: private is silently replaced when the mounting application sets its own cache directive on the same connection. An unauthenticated remote client that reaches such a cache can therefore obtain paid content and a valid receipt for free, and a related weaker case has a downstream non-2xx response still carrying a Payment-Receipt for a resource that was never delivered (CWE-524). The real-world risk is tightly bounded: the library's default behavior (private on success, no-store on 402) is safe, so the leak requires an application-level caching misconfiguration plus a shared cache in the response path, and no public exploit code was identified at time of analysis.

Password hash disclosure in Pepperl+Fuchs ICE2/ICE3 IO-Link Master devices and Phoenix Contact IOL MA8 PN DI8 (plus OEM variants) exposes all user credential hashes to any authenticated low-privileged user. The PHP-based diagnostics endpoint `/index.php/diagnostics_tab/ajax_diag_table_rows` accepts a manipulable `schema` path parameter that, when tampered with using a valid session cookie, causes the server to return the device's full user credential hash store. No public exploit or active exploitation has been identified at time of analysis; three separate CERTVDE advisories (VDE-2026-014, VDE-2026-027, VDE-2026-028) indicate the same underlying vulnerability spans multiple vendor product lines sharing common firmware.

Hard-coded cryptographic key exposure in Qualitysoft QND's Windows client allows any local authenticated user to decrypt and recover administrator credentials - including login ID and password - stored or processed by the PC management software. All three product lines (QND Advance, QND Premium, QND Standard) through their respective current versions are affected. No public exploit or active exploitation has been identified, but the attack is low-complexity and requires only a standard Windows session on a machine where the QND client is installed.

Unauthenticated attackers can book time slots in the Appointment Hour Booking WordPress plugin (before 1.5.95) that have already reached their configured capacity, because each appointment in a multi-appointment booking submission is not validated against the capacity limit of its own slot. The plugin assigns a CVSS 3.1 base score of 5.3 (AV:N/AC:L/PR:N/UI:N, integrity-only impact), meaning any anonymous visitor can submit a crafted booking form and overwrite or occupy fully booked slots, denying legitimate customers their reservations. Publicly available exploit code exists per WPScan, but the issue is not listed in CISA KEV and EPSS-style mass exploitation signals are absent, so this is best treated as a business-logic abuse and booking-integrity risk rather than a code-execution emergency.

Unauthenticated information disclosure in the Rox Appointment Booking WordPress plugin before 1.2.8 lets any remote attacker read the private internal notes attached to booking services and categories, because the endpoints that return those records perform no authorization check. No login, user interaction, or non-default configuration is required - only network reachability of the WordPress site - though the leaked data is limited to internal notes rather than full site content or credentials. A publicly available exploit code exists, but the flaw is not confirmed actively exploited (CISA KEV), and EPSS is very low at 0.18% (8th percentile), so this is a genuine but low-severity disclosure rather than a critical priority; sites already on 1.2.8 or later are unaffected.

Unauthenticated information disclosure in the Rox Appointment Booking WordPress plugin (all versions before 1.2.8) allows any remote visitor to query the booking-agent endpoint and retrieve staff email addresses, phone numbers, private internal notes, and the linked WordPress account name for every configured agent. The root cause is a complete absence of authorization checks on that endpoint (CWE-200), so exploitation requires no credentials, no user interaction, and no non-default configuration - only that the vulnerable plugin version is installed and at least one staff record exists. Publicly available exploit code exists and the vendor has released a fixed version, but the flaw is not in CISA KEV and EPSS is low at 0.18% (8th percentile), consistent with a genuine but modest-severity, read-only PII leak rather than a high-impact priority.

Unauthenticated remote attackers can retrieve a WooCommerce store's complete subscription roster - customer usernames, product names, recurring amounts and payment dates - because the Subscriptions for WooCommerce plugin from WPSwings (all versions before 2.0.3) validates the shared secret protecting one of its REST endpoints incorrectly. The flaw is rated CVSS 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N), so exploitation requires no credentials or user interaction and is limited to confidentiality loss - no data modification, privilege escalation or account takeover - but the store must actually be using the plugin's subscriptions feature for meaningful data to be exposed. Publicly available exploit code exists (documented by WPScan), the CVE is not listed in CISA KEV, and EPSS is 0.18% (8th percentile), indicating low observed exploitation likelihood; the vendor has released a fixed version 2.0.3.

Unauthenticated information disclosure in the LearnPress WordPress plugin affects all sites running versions from 4.2.7.1 up to but not including 4.4.7, where a REST route applies a user-supplied post status filter without checking the caller's capabilities. Any remote attacker, with no authentication or user interaction and no special configuration, can enumerate non-public course entries - drafts, pending, private, scheduled and trashed items - exposing content the site owner intended to keep hidden. Publicly available exploit code exists and the vendor has released a fix in 4.4.7, but EPSS is only 0.19% (9th percentile) and there is no confirmed active exploitation (no CISA KEV listing), making this a genuine but modest-severity exposure best treated as low-to-moderate priority; the impact is limited to disclosure of course listing metadata and does not include write access, code execution, or exposure of unrelated sensitive data.

Unauthenticated information disclosure in the LearnPress WordPress plugin (versions 4.3.2.8 through before 4.4.7) allows anyone who can determine the identifier of a previously generated order export file to download it directly and harvest customer names, purchase details, order amounts and guest email addresses. No authentication, capability check, nonce or user interaction is required once a valid export identifier is known (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N, base 3.7), with the High attack-complexity rating reflecting the need to discover or guess that identifier and the fact that an export must already exist on the server. Publicly available exploit code exists and the issue is tracked as EUVD-2026-80203, but there is no confirmed active exploitation (CISA KEV not applicable) and EPSS is a low 0.22% (13th percentile); this is a genuine but modest-severity data-exposure issue rather than a critical priority.

Unauthenticated information disclosure in the LearnPress WordPress plugin (versions before 4.4.7) allows any remote attacker to hit an administrative course tool that omits its capability check, listing every enrolled student's display name and user identifier for a given course and, through the same handler's search filter, recovering those students' email addresses. Publicly available exploit code exists, though the EPSS score is only 0.19% (9th percentile) and there is no CISA KEV entry, so confirmed active exploitation has not been established. The practical impact is confined to disclosure of enrolled-student PII rather than any compromise of the WordPress site or its integrity.

Unauthenticated information disclosure in the LearnPress WordPress plugin (versions 4.2.9 through before 4.4.7) lets any remote attacker query an administrative template handler that performs no capability check, returning the text, identifier, and type of every published quiz question on the site plus keyword search over that content - material the plugin otherwise keeps non-public. All default installations that actively publish LearnPress courses or quizzes are affected; no authentication, user interaction, or non-default configuration is required, as confirmed by the CVSS:3.1/AV:N/AC:L/PR:N/UI:N/C:L/I:N/A:N vector. Publicly available exploit code exists and WPScan has published the vulnerability, though EPSS is only 0.19% (9th percentile), and the independent assessment rates this a genuine but low-severity information disclosure issue rather than a high-priority emergency; a vendor patch is available in 4.4.7.

Stored HTML injection in the WordPress Formidable Forms plugin before 6.35 allows unauthenticated visitors to submit form entries that carry a forged 'last edited by' identifier pointing to an administrator, causing the plugin to skip its normal HTML stripping and render attacker-supplied markup inside the wp-admin entry view; the same forgery falsely attributes the submission to an administrator. Exploitation requires a public-facing form on the site and, critically, requires a privileged user to actually open the poisoned entry in the admin entry view (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N), so the real-world impact is bounded to that admin view context plus false attribution rather than full site compromise. Publicly available exploit code exists and a WPScan advisory documents the flaw, but EPSS is only 0.12% (2nd percentile) and there is no indication of active exploitation; the independent assessment rates this a genuine but modest-priority issue.

Tutor LMS WordPress plugin versions 4.0.0 through 4.0.7 return lesson discussion content without verifying that the requesting user is enrolled in or otherwise authorized for the course, so any authenticated account - including a low-privilege subscriber on a site with self-registration enabled, which is common for LMS deployments - can read other courses' discussion comments, including comments still pending moderation. Publicly available exploit code exists, but the exposure is confined to information disclosure (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, 4.3) with no write, integrity, or availability impact, and the EPSS score is just 0.18% (8th percentile), so this is a low-severity authorization gap rather than a broad emergency. Sites where lesson-discussion privacy or comment moderation integrity matters should treat it as a real priority.

Information disclosure in the FluentBoards WordPress plugin before version 2.0.15 lets any authenticated user - including a Subscriber with no board access whatsoever - retrieve the private board memberships of arbitrary users simply by referencing their user ID. The flaw is an authorization failure rather than a memory-safety or injection bug: the endpoint that returns a user's board list performs no ownership or capability check, so the requester's identity is never validated against the target user. Publicly available exploit code exists, but there is no CISA KEV listing and no evidence of active exploitation; EPSS is just 0.18% (8th percentile), and CVE severity is low (CVSS 4.3) because only membership associations leak, not board contents, credentials, or write access.

Unauthenticated visitors can read the body content of WordPress posts that authors marked as password protected when the Schema & Structured Data for WP & AMP plugin is installed at any version before 1.66. The plugin assembles its structured-data output without checking WordPress's post-password state, and it leaks the protected text through more than one public output route, so the only real precondition is that the site actually uses password-protected posts holding content worth hiding; sites that never set post passwords have nothing to expose. Publicly available exploit code exists (no CISA KEV entry), the vendor has released a fix in 1.66 per WPScan, and EPSS is low at 0.19% (9th percentile), making this a genuine but low-to-moderate severity information-disclosure issue rather than a high-urgency emergency.

Unauthenticated information disclosure in the Ni WooCommerce Sales Report WordPress plugin before version 4.2.0 allows remote attackers to dump WooCommerce order details and customer contact information, target a specific order by identifier, and search the store's entire order set by customer name or email address. Exploitation requires only that the plugin be installed and active on a WordPress site with WooCommerce data present - no credentials, roles, or user interaction are needed (CVSS:3.1/AV:N/AC:L/PR:N/UI:N) - and publicly available exploit code exists alongside a WPScan-published proof of concept. Impact is limited to confidentiality (C:L) with no write or code-execution capability, and EPSS places exploitation likelihood at roughly 0.22% (13th percentile), making this a moderate-priority exposure whose real risk scales with the sensitivity and volume of customer records the store holds.

Mass assignment (CWE-915) in the a2ui message-processing component lets an authenticated remote attacker inject arbitrary, dynamically-determined object attributes by submitting crafted messages to the message processor, producing limited confidentiality, integrity and availability effects. All a2ui versions up to and including 0.10.6 are affected according to the CPE range, and the upstream maintainers have not responded to the reported issue (#2297), so no patched release exists. No public exploit code and no CISA KEV entry were identified at time of analysis; the EPSS probability was not supplied with the input data.

Token generation in EspoCRM through 10.0.8 relies on PHP's non-cryptographic rand() function, producing roughly 31-bit identifiers for lead-capture opt-in links, event invitations, and campaign URLs. Remote unauthenticated attackers who can reach those public endpoints can guess or enumerate valid tokens, allowing them to confirm opt-ins, accept or decline event invitations on behalf of other contacts, and read event details. Publicly available exploit code exists (a vendor commit and a public write-up), but there is no evidence of confirmed active exploitation in the wild, and the CVSS 6.3 rating reflects high attack complexity and only low confidentiality/integrity impact.

MikroTik firmware 7.19.4 stores sensitive authentication credentials and network state in cleartext within non-volatile storage. An attacker with physical access to the device can extract this material from an SPI flash dump, without authenticating to the device and without knowledge of the administrative password.

DD-WRT firmware, as deployed on TP-Link TL-WR740N v1 through v4 hardware, stores sensitive authentication credentials in cleartext within non-volatile memory. The exposed material includes SSH private keys, dynamic DNS passwords, email notification credentials and administrative passwords. An attacker with physical access to the device can extract these credentials from an SPI flash dump, leading to device compromise, infiltration of the connected network and unauthorised access to dependent third-party services.

Arbitrary host file creation in Podman's `podman load` command lets anyone who can supply a crafted tar archive write files on the host with the privileges of the user running Podman. The flaw (CWE-277, insecure inherited permissions) affects Podman installations where image archives are loaded from untrusted sources, and is scored a moderate CVSS 5.5 because the write primitive is limited to the invoking user's permissions rather than root. No public exploit code and no CISA KEV listing were identified at time of analysis, though the Red Hat advisory and Bugzilla tracker confirm the issue is acknowledged upstream.

An out-of-bounds read in the ARP filter import handler (filter_arp_put_file.cgi) of Netcore NR255-V firmware 1.5.130703 lets an attacker who can reach the router's web management interface and supply a malformed, non-null-terminated string cause the string-handling API to read past the end of an allocated buffer, exposing adjacent process memory in the response. The flaw is rated CVSS 5.3 (CVSS:4.0/AV:N/AC:L/PR:L/UI:N/VC:L/VI:N/VA:L), indicating a network-reachable, low-privilege issue with limited confidentiality and availability impact only — there is no confirmed integrity impact, no CISA KEV listing, and no confirmed public exploit code; the only public material is a VulnCheck advisory plus a third-party GitHub technical reference whose exploit content is unverified.

An incorrect authorization flaw in the Netcore NR255-V router (firmware 1.5.130703) lets any authenticated user with a broad or low-privileged role pull live QoS/bandwidth telemetry from the mod_qos_bandwidth plan.json read routes, exposing network activity data they are not entitled to see. The bug is rooted in missing role checks within filter_conns_dump_cgi.c and IGD_CgiCall.c, so the endpoints return connection and bandwidth statistics regardless of the caller's privilege level. Impact is confidentiality-only and rated moderate (CVSS 4.0 base 5.3, AV:N/PR:L/UI:N/VC:L); no CISA KEV listing or confirmed public exploit code exists, though a public technical write-up of the QoS telemetry disclosure is referenced from the NVD entry.

Authenticated users who hold log-read permission on Devolutions PowerShell Universal 2026.2.5 and earlier can recover application tokens, data protection key material, and other stored credentials, because the slow query logging feature writes raw SQL parameter values into the system log on instances backed by Microsoft SQL Server. The issue is CWE-532 (insertion of sensitive information into a log file) and carries a CVSS v3.1 score of 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), meaning confidentiality is fully impacted while integrity and availability are untouched. There is no public exploit identified at time of analysis, no CISA KEV listing, and EPSS is low at 0.15% (roughly the 5th percentile), consistent with a genuine but moderate-priority disclosure whose prerequisites - an authenticated log-viewing account, an MSSQL backend, and slow query logging actively enabled - narrow the exposed population.

Let me construct the JSON. CVE-2026-91744: Chrome on Mac, race condition in PlatformIntegration, renderer compromise + social engineering, info disclosure, CVSS 5.3, CWE-367. Let me write fields carefully. Product name: "Google Chrome" — 1-3 words. Or "Google Chrome (macOS)". Keep "Google Chrome". Summary: must not start with "A vulnerability". Start with impact verb + product. Info disclosure in Google Chrome for macOS prior to 153.0.8010.47... Race condition in PlatformIntegration component. Requires attacker to already have compromised renderer process and use social engineering (UI:R). CVSS 5.3. No KEV, no POC identified. Technical context: PlatformIntegration is macOS-specific integration layer (native macOS APIs, app bindings, drag-and-drop, services, etc.). CWE-367 TOCTOU race condition — check and use of resource with different timing, enabling a race window where a resource's state changes between check and use, allowing access to data not intended for the renderer. Chrome's multi-process architecture & site isolation — renderer compromise is assumed by Chrome's threat model. The flaw crosses the sandbox boundary in the sense that the renderer-obtained access to macOS integration surfaces yields sensitive info. Risk assessment: CVSS 5.3 moderate, AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N. AC:H reflects the race condition timing win. UI:R because social engineering. PR:N per the vector — unauthenticated. Requires a compromised renderer, which raises the practical bar considerably: a separate renderer exploit is needed first. EPSS not provided — state missing. KEV not listed. No POC identified. Include "radom" once, naturally, in one sentence as illustrative hypothetical mid-sized operator. Affected products: Google Chrome on macOS prior to 153.0.8010.47. EUVD lists Chrome 153.0.8010.47 <153.0.8010.47 (odd formatting). References: chromereleases blog, chromium issue 520019273. CPE not provided — state that. Remediation: upgrade to 153.0.8010.47 or later (Ch

Uninitialized memory handling in the Skia graphics library shipped with Google Chrome before 153.0.8010.47 lets a remote attacker leak cross-origin data when a victim opens a crafted HTML page. Exploitation is unauthenticated but requires the user to visit attacker-controlled content (UI:R), and impact is limited to partial confidentiality loss with no integrity or availability effect (CVSS 4.3). Google has released a stable-channel fix; no public exploit code and no CISA KEV listing were identified at time of analysis.

Cross-origin data disclosure in Google Chrome versions prior to 153.0.8010.47 occurs when an attacker who has already compromised the renderer process lures a victim to a crafted HTML page. The weakness lives in the GetUserMedia media-capture code path, where incomplete cleanup (CWE-459) leaves cross-origin data recoverable, as captured by the CVSS v3.1 vector AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N (score 3.1) - unauthenticated network reach but high attack complexity, mandatory user interaction, and confidentiality-only, low-magnitude impact. No public exploit code or confirmed active exploitation has been identified at time of analysis, and Google has shipped the fix in Chrome 153.0.8010.47.

Google Chrome for Android versions prior to 153.0.8010.47 contain an out-of-bounds read in the WebGL rendering path that allows a remote attacker to leak memory from outside the browser sandbox by luring a victim into opening a crafted HTML page. Google labels the Chromium security severity as Critical, while the published CVSS 3.1 base score is a comparatively modest 4.7 (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N) because the flaw yields a limited confidentiality leak rather than code execution or data modification. A vendor patch is available, and no public exploit code or CISA KEV entry was identified at the time of analysis.

Information disclosure in Google Chrome desktop builds prior to 153.0.8010.47 allows a remote attacker to leak sensitive data by measuring observable CSS rendering discrepancies induced by a crafted HTML page. Exploitation is unauthenticated (PR:N) but requires the victim to open the attacker-controlled page (UI:R), and the leak depends on high-attack-complexity side-channel measurement rather than a deterministic parsing bug, so the impact is limited to confidentiality with no integrity or availability effect. The issue is rated Medium by Chromium; no public exploit code has been identified at time of analysis, and Google has released a fixed build.

An uninitialized-resource flaw (CWE-908) in ANGLE, the graphics translation layer used by Chrome to render WebGL and accelerated 2D content, is present in Google Chrome builds prior to 153.0.8010.47. A remote attacker who convinces a user to open a crafted HTML page can cause ANGLE to return memory contents that were never initialized, disclosing data that is outside Chrome's sandbox boundary — an information-disclosure primitive rather than a code-execution bug. Google rates the issue High severity (Chromium) and has published a fixed build; the NVD CVSS score is 4.7 and there is no CISA KEV entry or identified public exploit code at time of analysis.

Information disclosure in Google Chrome builds prior to 153.0.8010.47 allows a remote, unauthenticated attacker to leak sensitive data from the victim's browser by measuring font-related observable discrepancies on a crafted HTML page, a technique that requires the victim to be socially engineered into loading that page (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N, base 5.3). Impact is confidentiality-only, with no integrity or availability effect, and the high attack complexity reflects the probabilistic nature of the CWE-203 side channel, so reliable exfiltration demands specific conditions rather than a single deterministic request. No public exploit code was identified at time of analysis and the flaw is not listed in CISA KEV; Google has shipped a vendor-released patch in Chrome 153.0.8010.47, and auto-updating installations at or above that version are not affected.

Cross-origin data disclosure in Google Chrome prior to 153.0.8010.47: a race condition (TOCTOU) in the browser's Network component lets a remote attacker who has already achieved code execution inside the renderer process read data belonging to other origins by luring a victim to a crafted HTML page. The impact is limited to confidentiality of cross-origin responses (C:L, I:N, A:N), and exploitation is rated High complexity with required user interaction; no public exploit code or CISA KEV entry was present in the supplied intelligence, and the vendor has shipped a fix in 153.0.8010.47.

A maliciously constructed mail header could lead to multiple fields being parsed as one, or potential memory safety violations. This vulnerability was fixed in Thunderbird 156 and Thunderbird 140.16.

Arbitrary image-file read in Newell Brands DYMO Connect Desktop allows a crafted file-path parameter sent to the local LoadImageAsPngBase64 web-service endpoint to pull image files from anywhere on the host filesystem rather than from the intended directory. Versions before 1.6.2 are affected; the shipped fix only whitelists file extensions and does not enforce a directory boundary, so out-of-scope reads of files with allowed image extensions remain possible by accepted design. No public exploit code has been identified at time of analysis, and impact is limited to confidentiality (CVSS 4.0 base 5.1, Medium, AV:L/PR:N/UI:N/VC:L).

Unauthenticated memory disclosure in HPE Networking EdgeConnect SD-WAN Gateways lets an attacker on an adjacent network segment read portions of system memory, exposing internal service details and workflow information. All shipping 9.4.x, 9.5.x, 9.6.x and 9.7.0.0 branches are affected per the vendor-published version ranges. The CVSS score is only 4.3 (confidentiality-only, adjacent vector) and there is no public exploit code or CISA KEV listing, so this is best treated as a reconnaissance enabler rather than a standalone compromise — its value to an adversary is in chaining it with a separate privilege-escalation or authentication flaw.

Unauthenticated remote attackers can query an API endpoint in HPE Networking EdgeConnect SD-WAN Orchestrator and read security-relevant configuration details and security feature status. The flaw is a CWE-200 information exposure rated CVSS 5.3 (AV:N/AC:L/PR:N/UI:N, with only a low confidentiality impact and no integrity or availability impact), so it does not by itself compromise the platform but hands an adversary reconnaissance material that directly enables follow-on attacks against the managed SD-WAN fabric. There is no public exploit identified at time of analysis and the CVE is not listed in CISA KEV.

Denial of service in HPE Networking EdgeConnect SD-WAN Gateways lets an authenticated local attacker with low privileges destabilize the appliance operating system and disrupt traffic forwarding. Affected builds span the 9.4.x, 9.5.x, 9.6.x and 9.7.x branches — up to 9.4.8.2, 9.5.8.1, 9.6.3.1 and 9.7.0.0 respectively — and the trigger is both local-only and high-complexity, which keeps the CVSS score at 5.8 despite the High availability impact. No public exploit code or CISA KEV entry was identified at time of analysis, so the practical priority is patch hygiene on devices where local or delegated accounts exist.