Information Disclosure

In the Linux kernel, the following vulnerability has been resolved: power: supply: qcom_battmgr: fix use-after-free qcom_battmgr_pdr_notify() queues enable_work when the PMIC GLINK service comes up, and the worker recovers battmgr through container_of() to issue firmware requests. The PMIC GLINK client stays on the client list until its devres release action runs, so a PDR notification can keep queueing the work, and a pending or running worker can access battmgr after devres frees it. Make enable_work device-managed with devm_work_autocancel(), registered before the PMIC GLINK client is allocated. The devres cleanup then releases the client first, so no further notification can queue the work, and cancels the work before battmgr is freed. This issue was found by an in-house static analysis tool.

In the Linux kernel, the following vulnerability has been resolved: power: supply: twl4030_charger: cancel workers via devm bci is devm-allocated. Two workers (bci->work and bci->current_worker) dereference it. twl4030_bci_remove() disables charging and masks interrupts. It cancels neither worker. A worker pending at remove() can run after devm frees bci. The USB transceiver comes from devm_usb_get_phy_by_node(). devm unregisters its notifier only after remove() returns. A cancel_work_sync() in remove() can then race a notifier reschedule. devm_work_autocancel() and devm_delayed_work_autocancel() avoid that. They cancel the workers during devm release, before bci is freed. The current_worker is registered first, since devm will cancel in reverse order and bci->work can reschedule current_worker. [Move comment about order into the commit message]

In the Linux kernel, the following vulnerability has been resolved: power: supply: ucs1002: fix use-after-free on remove ucs1002 has no remove callback, so unbind runs entirely through devm. The alert IRQ handler queues the health_poll delayed work, and the work reschedules itself while the chip reports a bad-health condition. devm frees the alert IRQ, which only synchronizes the handler; it does not cancel the delayed work, which can then run after devm frees the driver data and dereference it. Register health_poll with devm_delayed_work_autocancel() before the alert IRQ is requested. devm then frees the IRQ before cancelling the work, so the handler can no longer queue it and the work is cancelled before the driver data is freed. This issue was found by an in-house static analysis tool.

In the Linux kernel, the following vulnerability has been resolved: power: supply: max17040: propagate register read errors max17040_get_vcell() and max17040_get_soc() ignore errors returned by regmap_read(). When an I2C transfer fails, the uninitialized register value is converted and reported to userspace as a valid voltage or state of charge. The polling worker can also replace the cached state of charge with the bogus value and emit a spurious change event. Propagate read errors through the power supply get_property callback and keep the last valid cached state of charge when polling fails.

In the Linux kernel, the following vulnerability has been resolved: power: supply: max17040: synchronize work cancellation on suspend max17040_work() requeues itself after every poll. cancel_delayed_work() only cancels a pending instance and does not wait for a callback that is already running. If system suspend races with the polling callback, the callback can continue accessing the fuel gauge and requeue itself after the suspend callback returns. Use cancel_delayed_work_sync() to ensure polling is quiesced before suspend completes.

In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Do not complete a failed ESE read as successful dasd_int_handler() completes an NRF read of an unallocated ESE track by calling ese_read() and unconditionally marking the request DASD_CQR_SUCCESS. dasd_eckd_ese_read() can return an error before it has zeroed the destination buffer: a failed sense-data parse or a current track outside the requested range both return early, leaving the destination pages untouched. The request is still completed successfully, so the block layer is handed stale / uninitialized memory instead of zeros. Check the ese_read() return value and fail the request through the normal error path instead of forcing DASD_CQR_SUCCESS.

In the Linux kernel, the following vulnerability has been resolved: PCI: plda: Fix use-after-free of event IRQs during teardown plda_pcie_irq_domain_deinit() removes pcie->event_domain via irq_domain_remove(), but the per-event IRQs mapped from that domain are requested with devm_request_irq() in plda_init_interrupts(). The actual free_irq() for a devm-managed IRQ is deferred by devres until after the calling probe()/remove() function returns. This means irq_domain_remove() can free the domain's internal data before the deferred free_irq() for IRQs still mapped into it has run. When devres later processes that deferred cleanup, it can end up dereferencing the already-freed domain. Free each event IRQ explicitly with devm_free_irq() before removing the domain. This triggers the free immediately and removes the IRQ from the devres tracking list, so devres will not attempt to free it a second time later. Also dispose of the event, INTx, and MSI IRQ mappings with irq_dispose_mapping() before their owning domains are removed. Finally, guard the calls to irq_set_chained_handler_and_data() for pcie->irq, pcie->msi_irq, and pcie->intx_irq so they only run when those fields hold a valid (>0) IRQ number. This is a pre-existing issue, flagged by automated review during work on an earlier, unrelated patch to this driver. Build-tested and boot-tested on StarFive VisionFive v1.2A board

In the Linux kernel, the following vulnerability has been resolved: PCI: plda: Fix IRQ domain leaks in the error paths of plda_init_interrupts() plda_init_interrupts() initializes IRQ domains and creates IRQ mapping but does not unwind them when later step fails. If platform_get_irq() or either irq_create_mapping() fails in plda_init_interrupts(), the domains are never deinitialized. If irq_create_mapping() fails, port->intx_irq stays initialized. Hence, remove the IRQ domains in the error path by calling plda_pcie_irq_domain_deinit(). Since plda_pcie_irq_domain_deinit() now disposes of the intx_irq and msi_irq mappings itself before removing their domains, the msi_irq mapping failure path can go directly to err_irq_domain_deinit instead of disposing of port->intx_irq separately first. This issue was found by automated review of sashiko-bot [mani: commit log]

In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Put PCI device after handling PPR faults iommu_call_iopf_notifier() looks up the requester with pci_get_domain_bus_and_slot(), which returns a PCI device with its reference count incremented. Neither the successful iommu_report_device_fault() path nor the abort path drops that reference, so every handled PPR request leaks a PCI device reference. This is the same ownership rule that was fixed for the old iommu_v2 ppr_notifier() path by commit 6cf0981c2233 ("iommu/amd: Fix pci device refcount leak in ppr_notifier()"), but iommu_call_iopf_notifier() was added later as a separate PPR/IOPF notifier path. Drop the PCI device reference after handling the PPR entry.

In the Linux kernel, the following vulnerability has been resolved: iommu/sva: Set handle->dev before the SVA handle is visible iommu_attach_device_pasid() installs the new SVA attach handle in the group PASID lookup before iommu_sva_bind_device() returns. A concurrent bind can therefore find and reuse the same handle after iommu_sva_lock is dropped. handle->dev was initialized after dropping iommu_sva_lock. This leaves a window where a racing bind can return a handle whose dev pointer is still NULL. A subsequent iommu_sva_unbind_device() can then dereference it via handle->dev->iommu_group. Initialize handle->dev before releasing iommu_sva_lock so any visible SVA handle is fully initialized.

In the Linux kernel, the following vulnerability has been resolved: iommu: Fix dev_iommu memory leak when device_add fails in iommu_mock_device_add iommu_mock_device_add() first calls iommu_fwspec_init(), which on success allocates both dev->iommu (via dev_iommu_get()) and dev->iommu->fwspec. If the subsequent device_add(dev) call fails, the error path only calls iommu_fwspec_free(dev), which frees fwspec but leaves dev->iommu still allocated. This triggers the following kmemleak report when fuzzing with Syzkaller: BUG: memory leak unreferenced object 0xffff888011e0a200 (size 192): comm "syz.1.1695", pid 24885, jiffies 4295222527 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de .............N.. ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff ................ backtrace (crc 25df5bb3): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4575 [inline] slab_alloc_node mm/slub.c:4899 [inline] __kmalloc_cache_noprof+0x47a/0x710 mm/slub.c:5415 kmalloc_noprof include/linux/slab.h:950 [inline] kzalloc_noprof include/linux/slab.h:1188 [inline] dev_iommu_get+0x10c/0x1a0 drivers/iommu/iommu.c:408 iommu_fwspec_init+0x288/0x4d0 drivers/iommu/iommu.c:3087 iommu_mock_device_add+0x46/0xb0 drivers/iommu/iommu.c:385 mock_dev_create drivers/iommu/iommufd/selftest.c:1025 [inline] iommufd_test_mock_domain drivers/iommu/iommufd/selftest.c:1066 [inline] iommufd_test+0x2f8a/0x6190 drivers/iommu/iommufd/selftest.c:2072 iommufd_fops_ioctl+0x367/0x540 drivers/iommu/iommufd/main.c:533 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by calling dev_iommu_free(dev) instead of iommu_fwspec_free(dev) in the device_add() failure path. dev_iommu_free() frees both fwspec and the outer dev_iommu struct and clears dev->iommu.

In the Linux kernel, the following vulnerability has been resolved: iommufd: Avoid locking internal accesses during unmap iommufd_access_notify_unmap() skips internal accesses because they do not have an external unmap callback to invoke. However, the current test calls iommufd_lock_obj() before checking whether the access is internal. If iommufd_lock_obj() succeeds, the loop then sees the internal access and continues, bypassing the matching iommufd_put_object() used by the normal unmap path. This leaks the object reference taken by iommufd_lock_obj(). Check for internal accesses first so skipped entries are never locked.

In the Linux kernel, the following vulnerability has been resolved: iommufd: Release current IOAS on xa_store() failure iommufd_take_all_iova_rwsem() takes an object reference and the iova_rwsem write lock before storing the IOAS in the temporary ioas_list xarray. If xa_store() fails, the current IOAS has not been inserted into ioas_list yet. iommufd_release_all_iova_rwsem() only unwinds IOAS objects already present in that xarray, so it cannot release the current IOAS. Release the current IOAS rwsem and object reference before unwinding the previously stored entries.

In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Don't hex dump attribute security buffer set_attribute() populates the security area of the BIOS attribute request buffer with the current admin password via populate_security_buffer(), then dumps the whole request buffer with print_hex_dump_bytes(). This can expose the plaintext admin password in the kernel log. The same issue was fixed for the password attribute path by commit d1a196e0a6dc ("platform/x86: dell-wmi-sysman: Don't hex dump plaintext password data"). Remove the remaining dump from the BIOS attribute path.

In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Add a NULL check for sst_inst[] To be consistent with other places, add a NULL check for failed socket loading by checking isst_common.sst_inst[].

In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Validate logical CPU id and clos id Validate max CLOS ID and logical CPU ID for core power feature. Reject any clos level or logical CPU number greater than the supported maximum. These are used to calculate MMIO offset.

In the Linux kernel, the following vulnerability has been resolved: platform/x86: int1092: Fix potential memory leak in sar_probe() The memory allocated for device_mode_info in parse_package() called by sar_get_data() is not freed in some of the error paths in sar_probe(). Fix that by converting to use device managed allocations.

In the Linux kernel, the following vulnerability has been resolved: platform/x86: think-lmi: Free system certificate signatures Multi-certificate support also allows the system authentication object to store ->signature and ->save_signature, which leak when the driver is removed. Free the signatures to avoid leaking memory.

In the Linux kernel, the following vulnerability has been resolved: io_uring/query: cap user size passed to copy_struct_to_user io_handle_query_entry() clamps hdr.size for the inbound copy_from_user() but keeps the original user value as usize. copy_struct_to_user() uses that usize and, when it is larger than the kernel result, clear_user()s the trailing bytes. As hdr.size is a __u32, a query can request nearly 4 GiB of zeroing, including on the error path where res_size stays 0. The interface is reachable without a ring via IORING_REGISTER_QUERY. Reject sizes larger than PAGE_SIZE, as recommended for copy_struct_* interfaces.

In the Linux kernel, the following vulnerability has been resolved: net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO rtl83xx_reset_assert() and rtl83xx_reset_deassert() are only called from the probe path, which may sleep and is not timing-critical. When the reset GPIO is provided by a sleeping controller such as an I2C I/O expander, gpiod_set_value() warns: WARNING: drivers/gpio/gpiolib.c:4030 at gpiod_set_value+0x44/0x80, CPU#1: kworker/u16:4/61 Hardware name: B&O MAP CA33 Rev f (UNKNOWN) (DT) Workqueue: events_unbound deferred_probe_work_func pc : gpiod_set_value+0x44/0x80 lr : rtl83xx_probe+0x1d8/0x3a0 Call trace: gpiod_set_value+0x44/0x80 (P) rtl83xx_probe+0x1d8/0x3a0 realtek_mdio_probe+0x24/0xa0 mdio_probe+0x38/0x78 really_probe+0xc4/0x3e0 __driver_probe_device+0x15c/0x1b8 driver_probe_device+0xb4/0x120 __device_attach_driver+0xb8/0x1a0 bus_for_each_drv+0x88/0xf0 __device_attach+0xa0/0x1d8 device_initial_probe+0x54/0x68 bus_probe_device+0x38/0xa0 deferred_probe_work_func+0xb8/0x120 process_one_work+0x184/0x4e8 worker_thread+0x188/0x308 kthread+0x130/0x150 ret_from_fork+0x10/0x20 Switch both helpers to gpiod_set_value_cansleep() so such a reset GPIO can be used without triggering the warning. The reset GPIO has been driven with the non-sleeping gpiod_set_value() since the driver was added in v4.19. The call has since been refactored across several files - from realtek-smi.c / realtek-mdio.c into the common rtl83xx.c module and then into the rtl83xx_reset_assert() and rtl83xx_reset_deassert() helpers (both in v6.9). This patch therefore applies as-is only to kernels that carry those helpers (v6.9+); older stable kernels need the same gpiod_set_value_cansleep() conversion at the corresponding open-coded call sites.

In the Linux kernel, the following vulnerability has been resolved: net: l2tp: do not propagate multicast notification errors The tunnel create, tunnel modify, session create, and session modify netlink handlers send multicast notifications through helpers that can fail while allocating or encoding a message, or while multicasting it. For tunnel and session create/modify, a notification is sent after the live operation has completed. Returning a best-effort notification error as the command result can therefore report failure for an operation that already committed and can cause callers to retry and accumulate live objects. Keep sending notifications for listener visibility, but do not propagate their best-effort status as the command result. This also keeps the tunnel modify command consistent with the other notification-only paths.

In the Linux kernel, the following vulnerability has been resolved: net: phylink: correctly validate returned PCS in phylink_inband_caps In phylink_inband_caps(), the PCS returned by mac_select_pcs is only checked if NULL but mac_select_pcs can also return an error pointer. This can cause a kernel panic as phylink_pcs_inband_caps() only checks if passed PCS is not NULL and directly dereference ops from the phylink_pcs struct. Use the IS_ERR_OR_NULL macro to address both case where the returned PCS can be NULL or an error pointer and prevent a kernel panic.

In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Release the Rx HopID that was handed out on mismatch tb_xdomain_alloc_in_hopid() passes the wanted HopID to ida_alloc_range() as the lower bound, so a taken id is not an error there: the allocator returns the next free one above it. tbnet_connected_work() asks for the peer's transmit path, treats any other id as a failure and returns without releasing what it got, so that allocation stays live for the rest of the XDomain connection with nothing left holding a reference to it. Release the id when it is not the one we asked for, the same way the error unwind at the end of the function releases the expected one.

In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_transport: Fail TX enqueue when the QP link is down Commit f195a1a6fe41 ("ntb: Drop packets when qp link is down") meant to make ntb_transport_tx_enqueue() drop packets submitted while the QP link is down, but it only returns 0 without consuming the packet. Zero means success by this function's contract, so ntb_netdev reports NETDEV_TX_OK and forgets the skb: nothing queued it, nothing frees it, and it leaks, one skb for every transmit racing a link-down. Return -ENOLINK instead, restoring the contract that a non-zero return leaves the buffer owned by the caller. With the preceding patch, ntb_netdev frees the skb on non-retryable enqueue failures and returns NETDEV_TX_OK, so a packet racing with link-down is dropped without leaking or entering a busy retry loop.

In the Linux kernel, the following vulnerability has been resolved: net/smc: do not dereference an unset send buffer on the SMC-D teardown path smc_close_stream_wait() calls smc_tx_prepared_sends() from inside its sk_wait_event() condition, and sk_wait_event() evaluates that condition once with the socket lock released. smcd_buf_detach() clears conn->sndbuf_desc from smc_conn_kill() under lock_sock(), so a link group terminating while a socket waits there leaves the helper dereferencing NULL, faulting out of close(). SIOCOUTQ reads the field by hand, and smc_close_cancel_work() drops the lock across two cancel_*_sync() calls. Sample the pointer once in the helper, report nothing prepared while it is unset, and bound the ioctl the same way. The receive tasklet dereferences the field directly in smc_cdc_msg_recv_action(), not through this helper; 1/2 is what keeps it from running that late.

In the Linux kernel, the following vulnerability has been resolved: net/smc: fix socket refcount leak in smc_switch_conns() smc_switch_conns() takes a reference on the SMC socket before dropping lgr->conns_lock, so the connection stays alive while the CDC slot is fetched: sock_hold(&smc->sk); read_unlock_bh(&lgr->conns_lock); /* pre-fetch buffer outside of send_lock, might sleep */ rc = smc_cdc_get_free_slot(conn, to_lnk, &wr_buf, NULL, &pend); if (rc) goto err_out; The err_out label only drops the wr_tx link reference, so this early exit returns without the matching sock_put(). The second error exit is not affected, because sock_put() has already run by then. A leaked sk_refcnt means the smc_sock is never destroyed. Its send and receive buffers stay allocated, and for a user socket the reference held on the network namespace is never released, so the netns can no longer be torn down. smc_cdc_get_free_slot() fails when the target link goes down or when the connection has been killed while the switch is in progress. Both are reachable during the link failover this function implements, so the leak is triggered by the same hardware events that make smc_switch_conns() run in the first place. Restructure so there is a single sock_put() covering both outcomes, instead of adding a second one to the error path.

In the Linux kernel, the following vulnerability has been resolved: mfd: sm501: Fix potential memory leaks during remove The memory allocated for struct sm501_devdata in sm501_pci_probe() and sm501_plat_probe() is not freed by the corresponding remove functions sm501_pci_remove() and sm501_plat_remove(). Fix that by adding a call to kfree().

In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Check card index validity at probe aloop driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as "none", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.

In the Linux kernel, the following vulnerability has been resolved: ALSA: FCP: do not copy out an uninitialised init response fcp_ioctl_init() allocates its response buffer with kmalloc() and copies the whole buffer back to userspace: buf_size = init.step0_resp_size + init.step2_resp_size; void *resp __free(kfree) = kmalloc(buf_size, GFP_KERNEL); ... if (copy_to_user(arg->resp, resp, buf_size)) return -EFAULT; Nothing clears the buffer, and the only writer of its leading step0_resp_size bytes is the step-0 control transfer: err = snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), FCP_USB_REQ_STEP0, USB_RECIP_INTERFACE | USB_TYPE_CLASS | USB_DIR_IN, 0, private->bInterfaceNumber, step0_resp, private->step0_resp_size); if (err < 0) return err; usb_fill_control_urb() does not set URB_SHORT_NOT_OK, so a short or zero-length data stage completes with status 0 and snd_usb_ctl_msg() returns a small actual_length. The only check is err < 0, so a short transfer is accepted as success. snd_usb_ctl_msg() copies the full size back unconditionally: buf = kmemdup(data, size, GFP_KERNEL); ... memcpy(data, buf, size); Bytes the device never wrote are therefore restored into resp unchanged and copied to userspace. step0_resp_size and step2_resp_size are each validated only to 1..255, so the caller also picks the slab cache, from kmalloc-8 up to kmalloc-512. On 7.2.0-rc5 (arm64), device answering step 0 with a zero-length data stage, s0 = s2 = 255: # init_on_alloc off, no spray step0 window [0,255): nonzero=94/255 000: 00 80 60 06 00 00 ff ff 18 00 00 00 57 01 ea 01 010: 08 78 22 13 00 00 ff ff a8 c4 5f 80 00 80 ff ff # same kernel, kmalloc-512 pre-seeded with an 8-byte tag step0 window [0,255): nonzero=219/255 tagbytes=232 # identical run, init_on_alloc=1 step0 window [0,255): nonzero=0/255 tagbytes=0 # all three runs step2 window [255,510): device words matched=62/62 a8 c4 5f 80 00 80 ff ff is the little-endian kernel text address ffff8000805fc4a8. The step-2 window is unaffected, so the disclosure is exactly the step-0 region. Zero the buffer, and require the step-0 transfer to deliver the full step0_resp_size bytes so a short data stage is reported as an error. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>

In the Linux kernel, the following vulnerability has been resolved: ALSA: mpu401: Check card index validity at probe mpu401 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as "none", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.

In the Linux kernel, the following vulnerability has been resolved: ALSA: mts64: Check card index validity at probe Although mts64 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as "none" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.

In the Linux kernel, the following vulnerability has been resolved: ALSA: portman2x4: Check card index validity at probe Although portman2x4 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as "none" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.

In the Linux kernel, the following vulnerability has been resolved: ALSA: serial-u16550: Check card index validity at probe serial-u16550 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as "none", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.

In the Linux kernel, the following vulnerability has been resolved: ALSA: virmidi: Check card index validity at probe virmidi driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as "none", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.

In the Linux kernel, the following vulnerability has been resolved: dm-pcache: detect a cycle in the last-kset chain during replay cache_replay() follows the on-media last-kset chain by next_cache_seg_id with no cond_resched(). A forged chain that points back into a segment it has already visited makes the replay loop follow it forever. Cap the last-kset hops at cache->n_segs; a valid chain visits each segment at most once.

In the Linux kernel, the following vulnerability has been resolved: dm-pcache: only hand out initialized cache segments get_cache_segment() scans the segment map up to cache->n_segs, the physical device segment count, but cache_segs_init() only initializes the first cache_info->n_segs segments. A crafted image with cache_info->n_segs smaller than the device count leaves the remaining pcache_cache_segment structs zeroed (segment.data == NULL), and the allocator can hand one to cache_kset_close(), which writes through the returned segment's data pointer with no NULL check. Bound the allocator's search to cache_info->n_segs so only initialized segments are ever returned. A conforming cache sets n_segs equal to the device segment count, so this rejects nothing legitimate.

In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix memory leak in brcmf_sdio_read_control() The memory allocated for buf is not freed in some of the error paths in brcmf_sdio_read_control(). Fix that by adding vfree() calls. [arend: rework as suggested by Johannes]

In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: dvm: fix memory leak in iwl_op_mode_dvm_start() In iwl_op_mode_dvm_start(), jumping to out_free_eeprom currently bypasses the out_free_eeprom_blob label. Consequently, error paths triggered after successfully parsing the EEPROM free priv->nvm_data but leak priv->eeprom_blob. Fix this memory leak by reordering the error handling labels so that out_free_eeprom falls through to out_free_eeprom_blob. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc6. An x86_64 allyesconfig build showed no new warnings. As we do not have supported Intel DVM wireless hardware and firmware to test with, no runtime testing was able to be performed.

In the Linux kernel, the following vulnerability has been resolved: fuse: copy request headers via a stack buffer for io-uring The fuse-io-uring transport copies req->in.h out to the ring in fuse_uring_copy_to_ring() and req->out.h back in fuse_uring_commit(). Both headers live inside the fuse_request slab object, whose cache (fuse_req_cachep) is created without a usercopy whitelist, so copying them directly to/from userspace trips CONFIG_HARDENED_USERCOPY and panics: usercopy: Kernel memory exposure attempt detected from SLUB object 'fuse_request' (offset 56, size 40)! kernel BUG at mm/usercopy.c:102! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:usercopy_abort (mm/usercopy.c:90) Call Trace: __check_heap_object (mm/slub.c:8268) __check_object_size (mm/usercopy.c:197 mm/usercopy.c:258 mm/usercopy.c:223) copy_header_to_ring (fs/fuse/dev_uring.c:618) fuse_uring_prepare_send (fs/fuse/dev_uring.c:776 fs/fuse/dev_uring.c:785) fuse_uring_send_in_task (fs/fuse/dev_uring.c:1306) tctx_task_work_run (io_uring/tw.c:96) task_work_run (kernel/task_work.c:233) io_run_task_work (io_uring/tw.h:84) io_cqring_wait (io_uring/wait.c:278) __do_sys_io_uring_enter (io_uring/io_uring.c:2685) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Bounce both headers through an on-stack copy so the usercopy touches stack memory, not the slab object.

In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: rtl8192du: Fix possible memory leak in rtl92du_init_sw_vars() The memory allocated inside rtl92du_init_shared_data() is not freed in any of the subsequent error paths in rtl92du_init_sw_vars(). Fix that by adding a call to rtl92du_deinit_shared_data() in the error path.

In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: Fix potential memory leak in rtw_txq_push_skb() The skb passed to the rtw_hci_tx_write() is expected to be freed when the function fails, but the error path in rtw_txq_push_skb() does not free the skb before returning. This can lead to a memory leak in rtw_txq_push() where a dequeued skb is passed to rtw_txq_push_skb().

In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: pci: fix resource leak on failed NAPI setup rtw_pci_probe() allocates PCI resources through rtw_pci_setup_resource() before it sets up NAPI. If rtw_pci_napi_init() fails, the error path jumps straight to err_pci_declaim and skips rtw_pci_destroy(), leaving the PCI resources allocated by rtw_pci_setup_resource() behind. Add a dedicated cleanup label for the NAPI setup failure path so probe destroys the PCI resources. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing current mainline kernels. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc7. An x86_64 allyesconfig build showed no new warnings. As we do not have a suitable rtw88 PCI board to test with, no runtime testing was able to be performed.

In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: pci: add .shutdown callback to stop rfkill polling on reboot Since the hardware rfkill polling was introduced, arm64 platforms can panic with an asynchronous SError during warm reboot: SError Interrupt on CPU8, code 0x00000000be000011 -- SError Workqueue: events_power_efficient rfkill_poll [rfkill] rtw89_pci_ops_read8+0x94/0x160 [rtw89_pci] rtw89_core_rfkill_poll+0x50/0x1e0 [rtw89_core] rtw89_ops_rfkill_poll+0x40/0x68 [rtw89_core] ieee80211_rfkill_poll+0x3c/0x70 [mac80211] cfg80211_rfkill_poll+0x40/0x2a0 [cfg80211] rfkill_poll+0x30/0x88 [rfkill] Kernel panic - not syncing: Asynchronous SError Interrupt On the reboot path the kernel only runs device_shutdown(), which calls each driver's .shutdown callback; .remove is not invoked. The rtw89 PCI driver had no .shutdown callback, so nothing stopped the rfkill polling work while the platform was tearing the PCIe link down. Once the link is gone, the next MMIO read from the poll handler targets a non-responding device and is reported as a fatal asynchronous SError on arm64. Add rtw89_pci_shutdown(), wired to all rtw89 PCI device drivers, which sets a new RTW89_FLAG_SHUTDOWN flag (mirroring the USB RTW89_FLAG_UNPLUGGED pattern). When the flag is set, rtw89_ops_rfkill_poll() returns early, so no MMIO read is issued to the chip after shutdown begins and the SError no longer occurs. This does not call the full .remove path from .shutdown, to keep the shutdown handler minimal and avoid running the non-idempotent teardown twice.

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex mt7615_suspend() acquired the mt76 mutex and then called cancel_delayed_work_sync() on mac_work. mt7615_mac_work() acquires the same mutex via mt7615_mutex_acquire() at the top of the worker, so if mac_work is already running and blocked on the mutex, the suspend path deadlocks waiting for the work it holds the mutex against. Flush scan_work and mac_work before taking the mutex, matching the suspend paths in mt7921 and mt7925. scan_work only takes the mt76 spinlock, but moving it keeps the sequence consistent. This also keeps mac_work from running over an already suspended HIF, which the previous split (async cancel under the lock, sync cancel after release) would have allowed.

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix TX DMA mapping leak for AddBA req frames mt7996/mt7992 hand the firmware a HW MAC-TXP for AddBA req action frames (MT_TXD7_MAC_TXD, set in mt7996_mac_write_txwi_80211()), but are otherwise FW-TXP devices. On tx free mt76_connac_txp_skb_unmap() therefore decodes the per-frame txp as a struct mt76_connac_fw_txp. For a MAC-TXP the fw_txp.nbuf byte aliases the AddBA TID word (MT_TXP1_TID_ADDBA), which is always zero, so the unmap loop runs zero times and the skb DMA mapping in buf[1] is never unmapped. buf[1].skip_unmap is set unconditionally, so the generic DMA-ring cleanup skips it as well. Each AddBA req therefore leaks one TX DMA mapping, roughly one per (re)association. With WED enabled these mappings are bounced through the WED swiotlb pool, so under continuous client reconnect churn the pool is exhausted after ~1-2 days, after which DMA mapping fails for WED, the WiFi MCU and other on-SoC consumers. Keep the deferred (token release) unmap that the design relies on, and add an mt7996-specific txp unmap that inspects MT_TXD7_MAC_TXD and unmaps buf[1] from the MAC-TXP layout for those frames, delegating to mt76_connac_txp_skb_unmap() otherwise.

In the Linux kernel, the following vulnerability has been resolved: tpm: tpm_i2c_nuvoton: disable IRQ on wait timeout i2c_nuvoton_wait_for_stat() enables the IRQ before waiting for the interrupt handler to report a status change. If the wait times out, or is interrupted before the handler runs, the function returns without balancing the enable_irq() call. Disable the IRQ before leaving the failed wait path. Also preserve an interrupted wait's original error code instead of converting it to -ETIMEDOUT inside the helper.

In the Linux kernel, the following vulnerability has been resolved: timekeeping: Check the return value of tk_get_aux_ts64 in __do_adjtimex() If the auxiliary clock is disabled during tk_get_aux_ts64() but is enabled before tks->clock_valid is checked, then uninitialized stackdata will be used in the calculations and indirectly leaked to userspace. The same race window also exists after this change and also for the core timekeeper. But in these cases the only effect would be incorrect adjustments and this is userspace's responsibility to avoid this.

Out-of-bounds read (CWE-125) in Citrix Workspace App for Windows exposes local, low-privileged users to limited memory disclosure and partial availability impact across Current Release and both LTSR branches. An attacker with local access and a standard user account can trigger the defect without user interaction, potentially reading a small amount of process memory and causing intermittent instability. No active exploitation or public exploit code has been identified; the vendor-released patch addresses the issue across all three affected release trains.

Workspace data exfiltration in Amazon Kiro IDE before version 0.8.135 allows remote unauthenticated attackers to steal developer credentials and sensitive project data through crafted repository content. When a developer opens a malicious project, the Kiro AI agent is manipulated - via CWE-829 inclusion from an untrusted control sphere - into overwriting the workspace settings file, redirecting the Kiro Powers registry to an attacker-controlled endpoint. Once the developer subsequently opens the Powers panel, workspace data, including any credentials present in the project, is transmitted to the attacker's server. Vendor-released patch 0.8.135 is available; no public exploit has been identified at time of analysis.

Sensitive data exposure in the ElasticPress WordPress plugin (versions through 5.3.4) allows unauthenticated network attackers to retrieve embedded sensitive information from plugin responses. The root cause is CWE-201: the plugin inserts confidential data into outbound payloads - likely search query results or API responses passed to Elasticsearch/OpenSearch - where it becomes accessible without authentication. Reported by Patchstack with a CVSS 5.3 Medium rating; no public exploit code or active exploitation confirmed at time of analysis.

Sensitive data exposure in bbPress WordPress forum plugin 2.6.14 and earlier allows unauthenticated remote attackers to access restricted information due to missing authorization checks (CWE-862). The CVSS vector confirms network-accessible, no-authentication-required exploitation with a low confidentiality impact, consistent with unauthorized read access to content that should be gated. No public exploit code and no CISA KEV listing are identified at time of analysis, and the moderate CVSS 5.3 score reflects a real but bounded data-exposure risk rather than a full compromise.

Unauthorized group enumeration in Concrete CMS 9.2.0 through 9.5.2 exposes the full organizational group structure to any authenticated API user holding a groups:read token. The root cause is a permission-checker callback in the REST API Groups controller that unconditionally returns true, eliminating per-object (tree-node) authorization on the group collection endpoint. With authentication required and no public exploit identified, the practical blast radius is limited to insiders or compromised API accounts, but the disclosed group hierarchy can materially assist privilege-escalation reconnaissance on affected sites.

The Endpoint DLP kernel driver (epdlpdrv.sys) in Netskope Client for Windows before release R141 exposes two overlapping flaws: an absent token-validation check on the internal kernel-to-userspace IPC channel, and an uninitialized reply buffer in the port message handler that returns residual kernel pool contents to callers. Any local unprivileged process can send unauthorized queries to the driver port without proving it is the legitimate hook DLL, then read uninitialized response buffers to extract DLP configuration data, feature flags, live session tokens, and kernel memory fragments from other users' concurrent operations. No public exploit code or CISA KEV listing exists at time of analysis.

Kernel pointer disclosure in NetBSD's mm_open() allows unprivileged local users to bypass the CANSEE_KPTR address obfuscation mechanism and recover real kernel virtual addresses. The flaw stems from world-accessible device nodes such as /dev/null and /dev/zero incorrectly inheriting the PK_KMEM process flag - a privilege reserved for kernel memory inspection tools - which then grants those processes unfiltered sysctl KERN_PROC results containing actual pointers to sensitive kernel structures including struct proc, kauth_cred, filedesc, and vmspace. No public exploit code has been identified and the vulnerability is not listed in the CISA KEV catalog, but the reliability of exploitation (AC:L, PR:L, no user interaction) makes it a useful primitive for chaining into privilege escalation attacks.

Keycloak's Dynamic Client Registration endpoint exposes confidential client secrets in cleartext to users holding the view-clients realm management role, violating the principle of least privilege. Affected deployments include Red Hat Build of Keycloak and Red Hat Single Sign-On 7 across all tracked versions. An attacker granted only read-only view-clients access can harvest any confidential OAuth/OIDC client secret via the registration API and subsequently authenticate as that client, escalating their effective permissions within the realm to whatever the compromised client is authorized to do.

Unauthenticated information disclosure in AVideo's WebRTC plugin exposes sensitive server-side configuration data to any remote user. When the WebRTC plugin is installed, the `/plugin/WebRTC/status.json.php` endpoint responds with the absolute filesystem path of the WebRTC2RTMP binary (revealing document-root layout), the configured WebRTC port, binary existence and executability status, WebRTC log file contents, and TCP reachability results for both loopback and the public address. The endpoint performs no authentication or authorization check of any kind, and no vendor patch had been released at the time of reporting.

User account enumeration via observable response discrepancy (CWE-204) affects Kingdom Communication Associated's Smart Video Intercom System across four product lines (EH3040, EH4200, EH1000B, EH2070). Unauthenticated remote attackers can distinguish valid from invalid usernames by measuring or parsing differences in system responses to authentication or lookup requests, yielding a valid account list without credentials. No public exploit code or KEV listing has been identified; the practical impact is limited to reconnaissance - harvested account names enable targeted credential attacks such as password spraying or brute force against the intercom management interface.

Out-of-bounds read in Qt's NFC connectivity module (qtconnectivity) exposes applications to denial of service or limited process memory disclosure when parsing crafted NFC tags with malformed language code length fields. All Qt versions fall within the affected CPE scope, with the flaw residing in NDEF Text Record parsing logic invoked when a user scans a malicious tag. No active exploitation has been confirmed and no public exploit code exists, but the zero-privilege requirement lowers the bar for a physically proximate adversary.

Unauthenticated information disclosure in the Teddy Bear Customize Addon WordPress plugin through version 1.0.5 exposes WooCommerce order metadata and customer-uploaded file attachment URLs to any network attacker without credentials. The plugin's data-return endpoints implement no authorization or ownership checks whatsoever, enabling an attacker to enumerate and retrieve private order records and attachment links belonging to arbitrary customers. Publicly available exploit code exists via WPScan; the same plugin also carries a separate RCE vulnerability (CVE-2026-14560), making immediate removal or patching urgent.

Two-byte memory disclosure in PCRE2's pcre2_serialize_encode function exposes a small amount of potentially sensitive memory to local adversaries who already have some form of unsafe process access. All PCRE2 releases prior to 10.48 are affected across all supported platforms, per CPE cpe:2.3:a:pcre:pcre2:*:*:*:*:*:*:*:*. No public exploit code or active exploitation has been identified; the vendor advisory explicitly qualifies that exploitation occurs in contexts where the adversary's access is already unsafe, substantially constraining real-world impact beyond the minimal two-byte leak.

Integer overflow in GStreamer's gst-plugins-good isomp4 plugin exposes adjacent heap memory when parsing CEA-608 closed-caption data embedded in specially crafted MP4 or MOV files. The 32-bit unsigned arithmetic wraparound bypasses a bounds check, enabling an out-of-bounds heap read of up to 244 bytes that is forwarded into downstream caption output - leaking process memory to an attacker who controls caption rendering output. Affected platforms include Red Hat Enterprise Linux 6 through 10; no public exploit has been identified at time of analysis, and no active exploitation is confirmed.

XML External Entity (XXE) injection in TP-Link Omada Controller's SAML SSO metadata parsing allows an authenticated user with SAML configuration privileges to read arbitrary files from the server, resulting in high-confidentiality information disclosure. The vulnerability arises because the controller does not disable external entity resolution when parsing user-supplied SAML metadata XML, enabling server-side file exfiltration. No public exploit code or active exploitation has been identified at time of analysis, and a vendor-released patch is available.

Out-of-bounds heap read in Netskope Client's Endpoint DLP (EPDLP) service allows a local unprivileged user to crash the kernel driver handler by sending a specially crafted, unbounded message, temporarily suspending DLP policy enforcement. The flaw additionally leaks per-boot kernel memory layout information, providing an attacker a potential ASLR-bypass primitive. No public exploit code exists and the vulnerability has not been added to the CISA KEV catalog at time of analysis.

HttpTransferCache in Angular's SSR stack leaks authenticated user data to subsequent unauthenticated visitors when hierarchical HttpClient is misconfigured with withRequestsMadeViaParent and SSR HTML is shared via a CDN or reverse proxy. The child injector's TransferCache evaluates each request before delegating it to the parent interceptor chain, so it sees the request as anonymous and stores the private authenticated response in the ng-state script tag serialized in the rendered HTML. Versions 20.x through 22.x are affected; no public exploit code has been identified at time of analysis.

NoSQL query injection in the GridFS component of the MongoDB Ruby Driver allows an authenticated low-privileged user to exceed their intended file access scope. When an application passes a caller-influenced structured identifier - such as a Ruby Hash containing MongoDB query operators - to GridFS retrieval or deletion operations without coercing it to a literal BSON type, the driver forwards the structure directly to the MongoDB query layer, which interprets it as a query condition. Exploitation can yield unauthorized read access to stored GridFS file chunks belonging to other identifiers, or mass deletion of all chunks within the affected bucket, permanently rendering all stored files unreadable. No public exploit has been identified at time of analysis.

NoSQL injection in the GridFS component of the MongoDB Python Driver allows an authenticated attacker who controls a caller-supplied file identifier to inject MongoDB query operators instead of literal identifiers. Depending on the affected operation, exploitation can expose stored file content beyond the intended target (reads), permanently destroy all GridFS file chunks in the affected bucket (deletes), or corrupt stored file metadata by renaming the wrong file (renames). No public exploit has been identified at time of analysis, and no KEV listing exists; the CVSS 4.0 score of 6.1 reflects the authentication requirement and the specific attack condition that the application must pass user-controlled identifiers directly to GridFS APIs.

GridFS NoSQL injection in the MongoDB C Driver (libmongoc) enables authenticated users with influence over file identifier parameters to either access file content beyond their intended authorization or destroy all GridFS file chunks in the affected bucket, rendering stored data permanently unreadable. The root cause (CWE-943) is the driver's failure to distinguish between structured query operators and literal identifier values in GridFS operations, allowing attacker-controlled input to redirect or broaden MongoDB queries. No public exploit code or CISA KEV listing has been identified at time of analysis, but the high integrity and availability sub-scores in the CVSS 4.0 vector indicate genuinely severe outcomes in vulnerable deployments.

NoSQL injection (CWE-943) in the GridFS component of the MongoDB C++ Driver allows an authenticated low-privileged user who can influence file identifiers to read unauthorized stored file content or cause mass deletion of all GridFS chunks in an affected bucket, rendering stored data unreadable. The flaw arises because caller-supplied structured file identifiers are not neutralized before being evaluated as query conditions rather than literal values. No public exploit has been identified at time of analysis, but the potential for irreversible, bucket-wide data destruction makes this a significant integrity and availability risk for any C++ application using GridFS where user-controlled identifiers reach the driver API.

NoSQL injection in the GridFS component of the MongoDB Java Driver allows an authenticated low-privilege user who can influence the file identifier passed by an affected application to break out of the intended document scope. By supplying a structured identifier containing MongoDB query operators instead of a literal file ID, the attacker can read file chunks belonging to other owners, delete all file chunks in the affected GridFS bucket (rendering stored content permanently unreadable), or rename an arbitrary stored file rather than the intended target. No public exploit code or CISA KEV entry has been identified at time of analysis, and exploitation requires a specific application code pattern that forwards user-controlled input directly to GridFS operations without sanitization.

NoSQL injection in the GridFS component of the MongoDB C# Driver allows an authenticated low-privilege attacker who can influence file identifiers passed by an affected application to execute query-condition attacks against GridFS bucket operations. Exploitation can yield unauthorized read access to stored file content, complete destruction of all file chunks in the affected bucket (rendering all stored content unrecoverable), or misdirection of rename operations to unintended files. No public exploit has been identified at time of analysis; the CVSS 4.0 score of 6.1 reflects the AT:P (attack-requirements present) constraint that the vulnerable application must forward user-controlled identifiers to the driver without sanitization.

NoSQL injection in the MongoDB Rust Driver's GridFS component allows an authenticated, low-privileged user to supply a crafted file identifier that is evaluated as a query predicate rather than a literal scalar value. Depending on the operation targeted, this can expose GridFS file content belonging to unintended records within the bucket, or - in the most destructive path - cause all file chunks in the affected bucket to be deleted, permanently rendering stored file content unreadable. No public exploit code or CISA KEV listing has been identified at time of analysis; the issue is acknowledged by MongoDB via JIRA issue RUST-2469.

NoSQL injection (CWE-943) in the MongoDB PHP Library's GridFS component allows a low-privileged authenticated user who can influence the file identifier parameter to achieve three distinct impacts: reading file content beyond the intended target, deleting all GridFS file chunks within a bucket (rendering stored files unrecoverable), or renaming an unintended file. The CVSS 4.0 vector (AT:P) confirms exploitation depends on the target application routing attacker-influenced input directly into GridFS operations without sanitization. No public exploit or CISA KEV listing has been identified at time of analysis.

Kernel pool memory disclosure in Silicon Labs silabser.sys driver (v11.5.0 and earlier) allows a local attacker with physical device access to leak up to 145 bytes of uninitialized kernel pool memory by presenting a malicious USB device that sends malformed packets to the driver on Windows 10 and earlier. The CVSS 4.0 score of 2.4 reflects the narrow physical-access prerequisite (AV:P) and limited read-only confidentiality impact. No public exploit code and no CISA KEV listing have been identified at time of analysis.

Credential and infrastructure state disclosure in AWS Security Agent MCP Server (versions ≤0.1.5) is enabled by the server's failure to verify S3 bucket ownership before uploading scan archives: an attacker who pre-registers the expected bucket name - derived from the target's publicly known AWS account ID - in their own account will silently receive every subsequent scan archive, which may contain long-lived credentials, Terraform or CloudFormation state files, and other sensitive workspace artifacts. The attack requires no privileges on the victim's account and only passive user interaction (the victim running a scan), but does require the attacker to act before the victim's first deployment. No public exploit has been identified and this CVE is not listed in CISA KEV; vendor-released patch 0.2.0 adds ownership verification, though Amazon explicitly notes that patching alone does not reclaim a bucket name already seized by a third party.

Bucket-squatting in the AWS Security Agent Plugin (aws-agents-for-devsecops) before 1.1.0 allows a remote unauthenticated attacker to intercept private workspace source archives uploaded during security scans. Because the S3 bucket name is deterministically derived from the victim's AWS account ID and region - both non-secret and frequently exposed in public ARNs, IAM policy documents, and ECR URIs - a third party can pre-register the predictable name in their own AWS account before the victim's setup runs. When a scan is subsequently triggered, the unpatched plugin uploads source.zip (containing source code, credentials, and infrastructure state) to the attacker-controlled bucket without verifying ownership, silently exfiltrating sensitive data. Vendor-released patch: 1.1.0.

rclone's HTTP backend (versions 1.49.0-1.75.0) leaks user-configured secret headers - including Authorization, Cookie, and X-Api-Key values - to untrusted redirect destinations because the underlying Go HTTP client follows redirects without a CheckRedirect policy that strips sensitive headers at host boundaries. When a configured HTTP remote issues a cross-host redirect, net/http copies the original headers verbatim to the new destination; a same-host HTTPS-to-HTTP redirect similarly exposes those headers in cleartext. Listing, stat, download, mount, and serve operations can all trigger the leak during normal use. No public exploit has been identified at time of analysis and the issue is not listed in CISA KEV.

Incomplete authorization logic in AVideo's video API endpoint exposes private user account fields to any authenticated low-privilege user. The `API::get_api_video()` method calls `removeSensitiveUserFields()` only when the caller is a guest or lacks a valid API secret, but never compares the authenticated caller's user ID against the video row's `users_id` column. Any account holder can therefore request another user's video via `APIName=video` and receive the owner's email address, account name, isAdmin, canUpload, and canStream flags - data that should be restricted to the owner or callers with a valid API secret. No patch was available at the time of advisory publication; no public exploit has been identified at time of analysis.

Improper encryption configuration across thirteen Hikvision video door station and intercom models enables physical-proximity attackers to forge MIFARE Classic (M1) access cards, bypassing the card-based authentication enforced by these devices. The vulnerability stems from weak or misconfigured Crypto-1 sector key handling in the card reader subsystem, allowing an attacker with commodity NFC tools to clone or synthesize valid credentials. With a forged card, an attacker can gain unauthorized physical entry to premises protected by these intercoms. No public exploit or CISA KEV listing is present, but MIFARE Classic attack tooling (Proxmark, libnfc) is mature and widely available.

Observable response discrepancy in DernekPlus Website Template enables unauthenticated remote account footprinting against all versions through 10092026. By submitting targeted requests and observing differing server responses for valid versus invalid accounts, attackers can enumerate valid usernames or registered member identities without any credentials. No patch is available; the vendor did not respond to TR-CERT disclosure, leaving affected deployments exposed with no vendor-side remediation path.

Pacemaker Configuration System (PCS) on Red Hat Enterprise Linux 8, 9, and 10 exposes an arbitrary file-read primitive to local members of the 'haclient' group via the `pcs host auth --token` command. The pcsd daemon reads the attacker-specified file path with root privileges, base64-encodes up to 256 bytes of content, and transmits it through cluster node communication channels the attacker controls - enabling exfiltration of short sensitive files such as API tokens, symmetric keys, or credential snippets that are otherwise inaccessible to the attacker. No public exploit has been identified at time of analysis, but the attack requires only local access and group membership, making it a realistic insider-privilege escalation threat in multi-tenant HA environments.

SP Property, a Joomla real estate extension by joomshaper.com, allows unauthenticated remote attackers to redirect booking inquiry emails to arbitrary destinations by manipulating client-submitted hidden form fields that control recipient routing. Versions 1.0.0 through 4.1.3 are affected; vendor-released patch version 4.1.4 addresses the flaw by moving recipient resolution server-side. No public exploit code or CISA KEV listing has been identified at time of analysis, but the attack requires no authentication against any publicly accessible property booking form.

Out-of-bounds stack read in Bosch BME690 SensorAPI v1.0.3 enables a physically adjacent attacker - or a compromised peripheral mimicking the sensor - to leak up to 6 bytes of adjacent stack memory and corrupt gas sensor measurement outputs. The flaw is in gas_index parsing within read_all_field_data (bme69x.c): a 4-bit mask permits values 0-15 while the heater configuration stack buffer only covers indices 0-9, and the leaked OOB byte is written directly into the public gas_wait field where it may be telemetered or logged. No public exploit is identified at time of analysis, and exploitation requires physical or hardware bus access.

Arbitrary file read in GeoVision GV-LPC2211 v1.13 allows authenticated remote users to exfiltrate any file accessible to the root-run web service by supplying unsanitized absolute path parameters to BKDownloadLink.cgi. The CGI handler fails entirely to restrict the filename input, making the vulnerability straightforward to exploit by any valid credential holder. No public exploit or active exploitation has been identified, and no patched firmware version is confirmed in available sources.

Information disclosure in the Palo Alto Networks Prisma® Access Agent on Linux allows local low-privileged users to read sensitive configuration data and credentials stored by the agent process. Only the Linux platform is affected; Palo Alto Networks has explicitly confirmed that macOS, Windows, iOS, Android, and Chrome OS deployments are not impacted. No public exploit code and no active exploitation have been identified; the CVSS 4.0 vector carries an E:U (unexploited) modifier.

DLP policy enforcement bypass in Palo Alto Networks Prisma Access Agent on Windows allows a low-privileged local user to circumvent configured EndPoint Data Loss Prevention controls and exfiltrate sensitive data that configured policy should block. The vulnerability is explicitly scoped to Windows deployments only - macOS, Linux, iOS, Android, and Chrome OS agents are confirmed unaffected by the vendor. No public exploit code is identified at time of analysis, and the CVSS 4.0 exploitation metric (E:U) indicates no observed active exploitation.

Information disclosure in Open WebUI 0.7.0-0.10.x allows authenticated low-privilege users to enumerate the identifiers, names, and descriptions of knowledge bases they are not authorized to access. The built-in knowledge search tool constructed a metadata filter restricting results to the caller's readable collections, but all eleven shipped vector-store backends (Elasticsearch, Milvus, Milvus Multitenancy, OpenGauss, and others) silently ignored that filter during search execution. No public exploit has been identified at time of analysis; the vendor released a fix in v0.11.1 confirmed by GitHub Security Advisory GHSA-pcvc-8vrv-8q6w.

Session cookie leakage in Open WebUI versions 0.6.27 through 0.11.0 allows an attacker who operates a connected tool server to capture a victim user's Open WebUI session cookies and achieve full account takeover. The root cause is a Python closure-in-loop bug in tools.py where a shared cookie jar from the enclosing async loop was captured by all tool callable functions instead of being bound per-function; when a session- or OAuth-authenticated tool server was processed last in the initialization loop, its cookies were incorrectly propagated into requests directed at other attached servers. Vendor-released patch version 0.11.1 is available; no public exploit code or CISA KEV listing has been identified at time of analysis.

Insufficient session expiration in Open WebUI 0.9.0-0.11.0 allows a demoted administrator to retain full read and write access to all users' collaborative notes by keeping an existing Socket.IO connection open after their role is revoked. The flaw exists because role updates applied through trusted role headers, OAuth role mapping, or SCIM provisioning write the new role to the database but do not invalidate the stale user record cached in the Socket.IO SESSION_POOL. The vulnerability is fixed in version 0.11.1; no public exploit code has been identified at time of analysis.

Cyrus IMAP before 3.12.4 exposes a Sieve-based mailbox existence oracle that allows authenticated users to enumerate private mailboxes belonging to other users and read shared mailbox annotation values. By crafting conditional Sieve filter scripts using `fileinto` branches and observing delivery outcomes during LMTP processing, an attacker can infer the existence of otherwise inaccessible mailboxes or annotation content through a side-channel. No public exploit exists and the vulnerability is not listed in CISA KEV; the EPSS risk is commensurately low, reflecting a medium-severity information disclosure limited to authenticated insiders.

Heap memory disclosure in Cyrus IMAP before 3.12.4 allows authenticated users to leak adjacent heap contents via a crafted JMAP blob ID. By issuing a JMAP blob download request using the internal format H<emailid>-<index> with an index value that exceeds the length of the blob_headers array, an attacker triggers an out-of-bounds read (CWE-125) and receives whatever heap memory follows the array in the server's response. The CVSS 3.1 score of 3.1 (Low) reflects the authentication requirement, high attack complexity, and limited confidentiality impact; no public exploit has been identified at time of analysis.