Information Disclosure
Monthly
Arbitrary file write outside the worktree boundary in gix-worktree-state (part of gitoxide) before 0.33.0 on Windows enables an attacker-controlled repository to overwrite files at arbitrary paths on a victim's filesystem. The flaw manifests when gix_worktree_state::checkout() performs an incremental materialization: a malicious repo first places a symlink entry at path P pointing outside the worktree, then a subsequent incremental checkout of a regular-file entry at the same path follows the Windows reparse point and writes attacker-supplied blob content through the link. No public exploit code is identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.
Stale public share links in filebrowser through 2.63.23 can silently redirect to unrelated files uploaded after a rename operation, unexpectedly exposing new content to anyone holding the original link. The defect (CWE-459, Incomplete Cleanup) arises because share records are keyed by file path rather than a file identifier - deletion triggers cleanup, but rename does not, leaving the share dormant. No public exploit or CISA KEV listing exists at time of analysis, and the CVSS 4.0 score of 2.3 reflects the multi-step preconditions required, but the confidentiality risk is real for deployments where multiple users share create permissions on overlapping directories.
Stale public share links in File Browser 2.63.6-2.63.23 expose subsequently uploaded content to unauthenticated network access after a privileged user deletes another user's shared file without triggering proper link invalidation. Because the surviving share URL continues to resolve to whatever is later placed at the same storage path, an attacker who retains or discovers the original link can retrieve entirely unrelated files without authentication. No public exploit code is identified at time of analysis, and the CVSS 4.0 score of 2.3 reflects the constrained, multi-step preconditions required.
Unauthenticated information disclosure in WWBN AVideo through version 30.0 exposes user registration statistics via two unprotected PHP endpoints. The report4.json.php and report4.1.json.php files return daily and cumulative user-registration counts to any remote requester without authentication or session validation. No public exploit code has been identified at time of analysis and this vulnerability is not listed in the CISA KEV catalog; however, its trivial exploitation path and network accessibility make it easy for any actor who can reach the server to enumerate platform growth data.
Timing side-channel in OX Dovecot Pro and CE exposes the length of configured doveadm passwords and API keys to adjacent-network attackers who can send repeated unauthenticated requests and measure response latency with high precision. The secret value itself is never disclosed - only its length - which marginally reduces brute-force search space. No active exploitation is identified and no public exploit exists; the vendor-assigned CVSS score of 3.1 accurately reflects the constrained attack surface and limited practical impact.
Memory disclosure in OX Dovecot Pro and OX Dovecot CE exposes uninitialized server process memory to authenticated IMAP users who send a malformed URLFETCH command. The IMAP URLAUTH extension's error-handling path fails to sanitize its response buffer, returning raw memory contents to the requesting client that may include session tokens, cached credentials, or message data from co-resident sessions. No active exploitation has been identified and no public exploits are known, though the low attack complexity for authenticated users makes insider threats and compromised accounts realistic vectors.
IMAP compression in OX Dovecot Pro and CE enables a CRIME/BREACH-class side-channel attack where shared compression state across session responses leaks information about mailbox contents. An adversary who can both send mail to a target user and observe the byte sizes of that user's IMAP traffic can use response-size variations to confirm whether a small message body matches a guessed candidate text. No public exploits are known and the attack has not been confirmed as actively exploited; arbitrary content recovery was not demonstrated, bounding real-world impact to oracle-style guess confirmation against short messages.
Authenticated availability disruption in OX Dovecot Pro and OX Dovecot CE allows any valid credential holder to crash the imap-hibernate service by opening many concurrent connections and sending malformed IMAP commands, triggering an intermittent out-of-bounds read (CWE-125). The crash terminates the imap-hibernate process, dropping hibernated IMAP sessions for co-hosted users and degrading service availability. No public exploit code is known and the vulnerability is not listed in CISA KEV; however, the low attack complexity means any authenticated user on a shared mail platform could attempt disruption.
In the Linux kernel, the following vulnerability has been resolved: mm: mglru: fix stale batch updates after memcg reparenting The mglru page table walker batches per-generation size deltas in walk->nr_pages while walking page tables without holding the lruvec lock. The reset_batch_size() later folds those deltas into walk->lruvec under the lruvec lock. The page table walker can run concurrently with the memcg reparenting path as follows: CPU0 CPU1 ==== ==== walk_mm --> walk_page_range --> update_batch_size --> walk->nr_pages += delta mem_cgroup_css_offline --> memcg_reparent_objcgs --> lock lruvec lru_gen_reparent_memcg --> reparent child folios to parent unlock lruvec lock lruvec reset_batch_size --> child lrugen->nr_pages += delta This will trigger the following warning in lru_gen_exit_memcg(): VM_WARN_ON_ONCE(memchr_inv(lruvec->lrugen.nr_pages, 0, sizeof(lruvec->lrugen.nr_pages))); And the user-visible impact of underestimated nr_pages in MGLRU was premature OOMs because MGLRU does not try to reclaim memory when nr_pages reaches zero, but there are still more pages. To fix it, make reset_batch_size() check CSS_DYING under RCU before flushing the pending batch. A non-dying memcg keeps the original lruvec stable against RCU-delayed offlining; a dying memcg redirects the deltas to the first non-dying ancestor.
In the Linux kernel, the following vulnerability has been resolved: igc: remove napi_synchronize() in igc_down() When an AF_XDP zero-copy application is killed abruptly, the XSK pool is torn down but NAPI keeps polling. igc_clean_rx_irq_zc() then returns the full budget on every poll, so napi_complete_done() never clears NAPI_STATE_SCHED. igc_down() calls napi_synchronize() before napi_disable(), so it spins forever waiting for that bit and the interface never goes down. Drop the napi_synchronize() and let napi_disable() do the job -- it sets NAPI_STATE_DISABLE, which forces the stuck poll to complete. Reorder it ahead of igc_set_queue_napi() so the NAPI mapping is cleared only after polling has stopped, matching the recent igb fix b1e067240379.
In the Linux kernel, the following vulnerability has been resolved: power: supply: max17040: handle missing status supplier MAX17040 does not report charger state itself, so the driver forwards POWER_SUPPLY_PROP_STATUS to a supplier power supply. If no supplier is registered, power_supply_get_property_from_supplier() returns -ENODEV and leaves the output value untouched. max17040_get_property() currently ignores that error and returns success, so userspace can read an uninitialized status value from the battery power supply. This happens on systems that use the fuel gauge without a charger supplier relationship in firmware. Return POWER_SUPPLY_STATUS_UNKNOWN when no supplier provides STATUS, and propagate other supplier lookup errors.
In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Fix missing mem scrub at clear key import in cca_clr2cipherkey() The helper function _ip_cprb_helper() uses internal buffer memory for building and processing CPRBs. After use this buffer was never scrubbed which could lead to leaving for example clear key material in memory which could be exposed via tricky reuse of this same memory. Extend the _ip_cprb_helper() function with another parameter 'scrub' used to steer scrubbing of this buffer. So now the caller has the opportunity to decide if scrubbing is needed or not. Extend the clear key to secure key token import process in function cca_clr2cipherkey() to tell the helper function from above to scrub the cprb buffer when the clear key value is part of the request data. Add explicit scrubbing on return from function cca_clr2cipherkey() for the random EXOR buffer and the cprb buffer. Overall this cleans the internal used buffer in case of clear key import to prevent sensitive data to get exposed.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: check if dml21_add_phantom_plane() is successful Verify that the phantom plane was allocated to avoid a later segfault. (cherry picked from commit 5adb54abe5a8e82cbff7f8806db30a5f4924329f)
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Avoid double-deactivate of IRQs in the nested context In the nested state, the physical interrupt has already been deactivated through the HW bit in the LR. The extra deactivation would be harmless but can hit an errata case on AmpereOne, so avoid it here. On AmpereOne, deactivating a physical interrupt through ICC_DIR_EL1 or ICC_EOIR1_EL1 (depending on EOImode) which is not active, but is the highest priority pending interrupt causes the cpu to lose the interrupt pending state and also prevents the delivery of future interrupts.
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix double free of wq, engine, and group structs The release callbacks for wq, engine, and group devices (idxd_conf_wq_release, idxd_conf_engine_release, idxd_conf_group_release) each call kfree() on the enclosing struct. The setup error paths and cleanup functions also call kfree() explicitly after put_device(), producing a double free whenever put_device() drops the reference count to zero and fires the release. In the setup functions, device_initialize() is called before device_add(), so the reference count is exactly 1 at the error sites. put_device() unconditionally fires the release, which frees the struct; the subsequent explicit kfree() then operates on freed memory. For idxd_setup_wqs(), the wq release callback also owns opcap_bmap and wqcfg. The error unwind additionally freed those fields explicitly before calling put_device(), causing further double frees on both. Remove the redundant explicit kfree() calls from all setup error paths and cleanup functions for wq, engine, and group structs, delegating sole ownership of those allocations to the release callbacks.
In the Linux kernel, the following vulnerability has been resolved: hwmon: (sht3x) Fix unaligned accesses Sashiko reports: In sht3x_update_client(), the 16-bit temperature and humidity values are extracted from a stack-allocated byte array using be16_to_cpup(). The pointers passed to this function are calculated as buf and buf + 3. Since the difference between the two pointers is an odd number of bytes, at least one of them is guaranteed to be at an unaligned offset. This will trigger an alignment fault on strict-alignment architectures such as ARMv5 or SPARC, resulting in a kernel panic. Fix the problem by using get_unaligned_be16() instead of be16_to_cpup(), and put_unaligned_be16() instead of cpu_to_be16().
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Initialize hba->rpmbs list in ufshcd Initialize the hba->rpmbs list in ufshcd_alloc_host() to prevent NULL pointer dereference in the device teardown path if ufs_rpmb_probe() fails.
In the Linux kernel, the following vulnerability has been resolved: riscv: drop __init from vec_check_unaligned_access_speed_all_cpus This function runs within a kthread and need not necessarily finish before system finishes boot and free_initmem() unmaps the .init.text section. This function makes calls to SBI for probing unaligned access speed, and if this is slow for some reason (say some debug prints were added to SBI), the kthread can still be running at this point and result in an instruction page fault when trying to fetch from the freed region. [ 25.642087] Unable to handle kernel paging request at virtual address ffffffff80a04ef8 [ 25.646694] Current vec_check_unali pgtable: 4K pagesize, 48-bit VAs, pgdp=0x00004000316e9000 [ 25.653170] [ffffffff80a04ef8] pgd=000010004be7e401, p4d=000010004be7e401, pud=000010004be7e001, pmd=000010000c3000e3 [ 25.661244] Oops [#1] [ 25.662997] Modules linked in: [ 25.665357] CPU: 3 UID: 0 PID: 42 Comm: vec_check_unali Not tainted 7.0.0-tt-blackhole-asrinivasan-00007-g30ff73f18211 #570 PREEMPTLAZY [ 25.674669] Hardware name: Tenstorrent Blackhole (DT) [ 25.678545] epc : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.683458] ra : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.688372] epc : ffffffff80a04ef8 ra : ffffffff80a04ef8 sp : ffff8f8000203e20 [ 25.693874] gp : ffffffff814dc168 tp : ffffaf8001ad9900 t0 : 0000000000000000 [ 25.699401] t1 : fffffffffffffff0 t2 : ffffaf8001ad9a10 s0 : ffff8f8000203e30 [ 25.704912] s1 : ffffaf80018dc780 a0 : 0000000000000000 a1 : 0000000000000002 [ 25.710407] a2 : 00000000000001f0 a3 : 0000000000000018 a4 : 0000000000000000 [ 25.715917] a5 : 0000000000000000 a6 : ffffaf8001c03d98 a7 : ffffaf8001c03e30 [ 25.721419] s2 : ffff8f8000023c98 s3 : ffffaf8001aa1240 s4 : ffffffff80a04ee0 [ 25.726937] s5 : 0000000000000000 s6 : 0000000000000000 s7 : 0000000000000000 [ 25.732450] s8 : 0000000000000000 s9 : 0000000000000000 s10: 0000000000000000 [ 25.737944] s11: 0000000000000000 t3 : 0000000000000002 t4 : 0000000000000402 [ 25.743481] t5 : 0000000000000040 t6 : 0000000000000004 ssp : 0000000000000000 [ 25.749024] status: 0000000200000120 badaddr: ffffffff80a04ef8 cause: 000000000000000c [ 25.755060] [<ffffffff80a04ef8>] vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.760964] [<ffffffff80047a10>] kthread+0xd8/0xfc [ 25.764660] [<ffffffff80010c48>] ret_from_fork_kernel+0x18/0x1c4 [ 25.769220] [<ffffffff80895fe6>] ret_from_fork_kernel_asm+0x16/0x18 [ 25.774018] Code: cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc (cccc) cccc Drop __init from its signature so that this doesn't happen.
In the Linux kernel, the following vulnerability has been resolved: iommufd/viommu: Release the igroup lock on the vdevice_size error path iommufd_vdevice_alloc_ioctl() takes idev->igroup->lock, then validates the driver's vdevice_size against the core structure size with a WARN_ON_ONCE. On failure that guard jumps to out_put_idev, below out_unlock_igroup, so it skips the mutex_unlock(), leaving the igroup lock held and deadlocking the next vDEVICE operation on that group. Jump to out_unlock_igroup instead.
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1]
In the Linux kernel, the following vulnerability has been resolved: bpf: Disable xfrm_decode_session hook attachment BPF LSM programs can currently attach to xfrm_decode_session(). That hook may return an error, but security_skb_classify_flow() calls it from a void path and triggers BUG_ON() if an error is returned. Disable BPF attachment to the hook to prevent a BPF LSM program from turning packet classification into a full panic.
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: LAG, MPESW, Fix missing complete() on devcom error mlx5_mpesw_work() returned without calling complete() when mlx5_lag_get_devcom_comp() returned NULL. A caller that queued the work and waited on mpesww->comp would block indefinitely. Funnel the early-return path through a new "complete" label so the waiter is always woken.
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: sco: Fix a race condition in sco_sock_timeout() sco_sock_timeout() runs asynchronously and lock_sock(sk). If the socket is closing while the timer is running, it holds the same lock (lock_sock(sk)) twice, leading to a deadlock. CPU 0 CPU 1 ==================== ====================== sco_sock_close() sco_sock_timeout() lock_sock(sk) // <-- LOCK __sco_sock_close() sco_chan_del() sco_conn_put() sco_conn_free() disable_delayed_work_sync() lock(sk) // <-- SAME LOCK Fix this by moving disable_delayed_work_sync() outside of lock_sock(sk), ensuring that no lock_sock(sk) is held before sco_sock_timeout(). Lockdep splat: WARNING: possible circular locking dependency detected 6.13.0-rc4 #7 Not tainted syz-executor292/9514 is trying to acquire lock: ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_lock_acquire sect/v6.13-rc4/./include/linux/rcupdate.h:337 [inline] ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_read_lock sect/v6.13-rc4/./include/linux/rcupdate.h:849 [inline] ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4137 [inline] ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: __flush_work+0xd1/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195 but task is already holding lock: ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline] ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: sco_sock_close+0x25/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:524 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}: lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849 lock_sock_nested+0x48/0x130 sect/v6.13-rc4/net/core/sock.c:3622 lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline] sco_sock_timeout+0xbe/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:158 process_one_work sect/v6.13-rc4/kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa99/0x18f0 sect/v6.13-rc4/kernel/workqueue.c:3310 worker_thread+0x8a9/0xd80 sect/v6.13-rc4/kernel/workqueue.c:3391 kthread+0x2c6/0x360 sect/v6.13-rc4/kernel/kthread.c:389 ret_from_fork+0x4e/0x80 sect/v6.13-rc4/arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 sect/v6.13-rc4/arch/x86/entry/entry_64.S:244 -> #0 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}: check_prev_add sect/v6.13-rc4/kernel/locking/lockdep.c:3161 [inline] check_prevs_add sect/v6.13-rc4/kernel/locking/lockdep.c:3280 [inline] validate_chain+0x1888/0x5760 sect/v6.13-rc4/kernel/locking/lockdep.c:3904 __lock_acquire+0x13b4/0x2120 sect/v6.13-rc4/kernel/locking/lockdep.c:5226 lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849 touch_work_lockdep_map sect/v6.13-rc4/kernel/workqueue.c:3909 [inline] start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4163 [inline] __flush_work+0x70f/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195 __cancel_work_sync sect/v6.13-rc4/kernel/workqueue.c:4351 [inline] disable_delayed_work_sync+0xbb/0xf0 sect/v6.13-rc4/kernel/workqueue.c:4514 sco_conn_free sect/v6.13-rc4/net/bluetooth/sco.c:95 [inline] kref_put sect/v6.13-rc4/./include/linux/kref.h:65 [inline] sco_conn_put+0x18f/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:107 sco_chan_del+0xe2/0x210 sect/v6.13-rc4/net/bluetooth/sco.c:236 sco_sock_close+0x8f/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:526 sco_sock_release+0x62/0x2d0 sect/v6.13-rc4/net/blueto ---truncated---
In the Linux kernel, the following vulnerability has been resolved: hwmon: (occ) unregister sysfs devices outside occ lock occ_active(false) and occ_shutdown() unregister sysfs-backed devices while occ->lock is held. hwmon_device_unregister() and sysfs_remove_group() can wait for active sysfs callbacks to drain, and those callbacks can enter the OCC update path and try to take occ->lock again. That gives the unregister paths the lock ordering occ->lock -> sysfs callback drain, while a callback has the opposite edge sysfs callback -> occ->lock. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the real unregister and callback carrier: occ_shutdown() hwmon_device_unregister() occ_show_temp_1() occ_update_response() Lockdep reported the circular dependency with occ_shutdown() already holding the OCC mutex and hwmon_device_unregister() waiting on the sysfs side: WARNING: possible circular locking dependency detected ... (sysfs_lock) ... at: hwmon_device_unregister+0x12/0x30 [vuln_msv] ... (&test_occ.lock) ... at: occ_shutdown.constprop.0+0xe/0x40 [vuln_msv] occ_update_response.isra.0+0xb/0x20 [vuln_msv] occ_show_temp_1.constprop.0.isra.0+0x23/0x40 [vuln_msv] *** DEADLOCK *** Serialize hwmon registration and removal with a separate hwmon_lock. Under that lock, detach occ->hwmon and update occ->active while occ->lock is held so concurrent OCC state changes still see a stable state, then drop occ->lock before calling hwmon_device_unregister(). Remove the driver sysfs group before taking occ->lock in occ_shutdown(), so draining the driver attributes cannot wait while the OCC mutex is held. Also make OCC update callbacks return -ENODEV after deactivation, so callbacks that already passed sysfs active protection do not poll the hardware after teardown has detached the hwmon device.
In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: defer reset until cmd_mutex is unlocked vub300_cmndwork_thread() holds cmd_mutex while it sends a command and waits for the command response. If the response wait times out, __vub300_command_response() kills the command URBs and then synchronously resets the USB device through usb_reset_device(). That reset path re-enters the driver through vub300_pre_reset(), which also takes cmd_mutex. The worker therefore tries to acquire the same mutex recursively while it is still holding it from the command path. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the real worker and timeout/reset carrier: vub300_cmndwork_thread() __vub300_command_response() usb_lock_device_for_reset() usb_reset_device() vub300_pre_reset() Lockdep reported the same-task recursive acquisition on cmd_mutex: WARNING: possible recursive locking detected ... (&test_vub300.cmd_mutex) ... at: usb_reset_device... [vuln_msv] ... (&test_vub300.cmd_mutex) ... at: vub300_cmndwork_thread+0x12/0x20 [vuln_msv] Workqueue: vub300_cmd_wq vub300_cmndwork_thread [vuln_msv] *** DEADLOCK *** Return a flag from __vub300_command_response() when the timeout path needs a device reset, then perform the reset after vub300_cmndwork_thread() has cleared the in-flight command state and dropped cmd_mutex. The reset is still attempted before mmc_request_done(), preserving the existing request completion ordering while avoiding the recursive lock.
In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Treat zero-length cert chain as query for blob lengths When handling a PDH export, treat a zero-length userspace cert chain buffer as a request to query the length of the relevant blobs. Failure to account for the zero-length buffer trips a BUG_ON() when running with CONFIG_DEBUG_VIRTUAL=y due to trying to get the physical address of the ZERO_SIZE_PTR (returned by kzalloc() on the bogus allocation). kernel BUG at arch/x86/mm/physaddr.c:28 ! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 30 UID: 0 PID: 28580 Comm: syz.2.18 Kdump: loaded Tainted: G W 6.18.16-smp-DEV #1 NONE Tainted: [W]=WARN Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 RIP: 0010:__phys_addr+0x16a/0x180 arch/x86/mm/physaddr.c:28 RSP: 0018:ffffc9008329fc80 EFLAGS: 00010293 RAX: ffffffff8179110a RBX: 0000778000000010 RCX: ffff8884e6992600 RDX: 0000000000000000 RSI: 0000000080000010 RDI: 0000778000000010 RBP: ffffc9008329fdf0 R08: 0000000000000dc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff126d297 R12: dffffc0000000000 R13: 1ffff92010653fc8 R14: 0000000080000010 R15: dffffc0000000000 FS: 0000555556bec9c0(0000) GS:ffff88aa4ce1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd3159e7000 CR3: 00000004fbc44000 CR4: 0000000000350ef0 Call Trace: <TASK> [<ffffffff853d3869>] sev_ioctl_do_pdh_export+0x559/0x7a0 drivers/crypto/ccp/sev-dev.c:2308 [<ffffffff853d1fdd>] sev_ioctl+0x2cd/0x480 drivers/crypto/ccp/sev-dev.c:2556 [<ffffffff82549ebc>] vfs_ioctl fs/ioctl.c:52 [inline] [<ffffffff82549ebc>] __do_sys_ioctl fs/ioctl.c:598 [inline] [<ffffffff82549ebc>] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:584 [<ffffffff8630115f>] do_syscall_x64 arch/x86/entry/syscall_64.c:64 [inline] [<ffffffff8630115f>] do_syscall_64+0x9f/0xf40 arch/x86/entry/syscall_64.c:98 [<ffffffff81000136>] entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fd3158eac39 </TASK> Thankfully, the bug is benign outside of CONFIG_DEBUG_VIRTUAL=y as getting the physical address is just arithmetic, and the PSP errors out before trying to write to the garbage address (which it must, otherwise querying the blob lengths would clobber memory at pfn=0).
In the Linux kernel, the following vulnerability has been resolved: media: atomisp: gc2235: fix UAF and memory leak gc2235_probe() handles its error paths incorrectly. If media_entity_pads_init() fails, gc2235_remove() is called, which tears down the subdev and frees dev, but then still falls through to atomisp_register_i2c_module(). This results in use-after-free. If atomisp_register_i2c_module() fails, the media entity and control handler are left initialized and dev is leaked. gc2235_remove() unconditionally calls media_entity_cleanup() and v4l2_ctrl_handler_free(), but these are not initialized at every error path in gc2235_probe(). Replace gc2235_remove() calls in the probe error paths with explicit unwind labels that free only the resources initialized at each point of failure, in reverse order of initialization.
In the Linux kernel, the following vulnerability has been resolved: pinctrl: spacemit: fix NULL check in spacemit_pin_set_config spacemit_pin_set_config() looks up the per-pin descriptor with spacemit_get_pin() then checks the wrong variable for failure: const struct spacemit_pin *spin = spacemit_get_pin(pctrl, pin); ... if (!pin) return -EINVAL; reg = spacemit_pin_to_reg(pctrl, spin->pin); pin is an unsigned int pin id, where 0 (GPIO_0 / gmac0_rxdv on K3) is a valid pin, so rejecting it here drops the PAD config write for the first pin of every group. On K3 Pico-ITX the GMAC RGMII group lists pin 0 as its first entry, so its drive-strength / bias configuration was silently ignored. The intended guard is against spacemit_get_pin() returning NULL when the pin id isn't in the SoC's pin table. Check spin instead, which both restores PAD setup for pin 0 and prevents a NULL deref on spin->pin.
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix warning in poll cq direct mode CQs allocated by ib_alloc_cq() always have a comp_handler. Though in direct mode this handler is never expected to be called, it is still called when the driver is reset, triggering the following WARN_ONCE(): Call trace: ib_cq_completion_direct+0x38/0x60 hns_roce_cq_completion+0x54/0x90 (hns_roce_hw_v2] hns_roce_handle_device_err+Ox1c8/0x340 [hns_roce_hw_v2] hns_roce_hw_v2_uninit_instance.constprop.0+0x34/0x70 [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify+0xc4/0xe0 [hns_roce_hw_v2] hclge_notify_roce_client+0x60/0xbc [hclge] hclge_reset_rebuild+0x48/0x34c [hclge] hclge_reset_subtask+0xcc/0xec [hclge] hclge_reset_service_task+0x80/0x160 [hclge] hclge_service_task+0x50/0x80 (hclge] process_one_work+0x1cc/0x4d0 worker_thread+0x154/0x414 kthread+0x104/0x144 ret_from_fork+0x10/0x18
In the Linux kernel, the following vulnerability has been resolved: EDAC/igen6: Fix call trace due to missing release() When unloading the igen6_edac driver, there is a call trace: Device '(null)' does not have a release() function, it is broken and must be fixed. See Documentation/core-api/kobject.rst. WARNING: drivers/base/core.c:2567 at device_release+0x84/0x90, CPU#5: rmmod/127209 ... RIP: 0010:device_release+0x84/0x90 Call Trace: <TASK> kobject_put+0x8c/0x220 put_device+0x17/0x30 igen6_unregister_mcis+0xa2/0xe0 [igen6_edac] igen6_remove+0x82/0xb0 [igen6_edac] ... Fix the call trace by providing empty release() functions for the memory controller devices.
In the Linux kernel, the following vulnerability has been resolved: liveupdate: Reference count incoming FLB data Increment the incoming FLB refcount in liveupdate_flb_get_incoming() so that the FLB structure cannot be freed while the caller is actively using it. Add an additional liveupdate_flb_put_incoming() function so the caller can explicitly indicate when it is done using the FLB data. During a Live Update, a subsystem might need to hold onto the incoming File-Lifecycle-Bound (FLB) data for an extended period, such as during device enumeration. Incrementing the reference count guarantees that the data remains valid and accessible until the subsystem releases it, preventing future use-after-free bugs.
In the Linux kernel, the following vulnerability has been resolved: wifi: wlcore: enable the right set of ciphers The firmware version number check for IGTK introduced in commit c34dbc5900b0 ("wifi: wlcore: Add support for IGTK key") lets the amount of ciphers decrease on every boot of a too old firmware and that is practically happening. It also does not take into account other chips than the wl18xx. On some wl128x, the following can be observed when connecting via nm to a common ap: [ 484.113311] wlcore: WARNING could not set keys [ 484.117828] wlcore: ERROR Could not add or replace key [ 484.123016] wlan0: failed to set key (5, ff:ff:ff:ff:ff:ff) to hardware (-5) [ 484.123046] wlcore: Hardware recovery in progress. FW ver: Rev 7.3.10.0.142 [ 484.139923] wlcore: pc: 0x0, hint_sts: 0x00000048 count: 1 [ 484.145721] wlcore: down [ 484.148986] ieee80211 phy0: Hardware restart was requested [ 484.610473] wlcore: firmware booted (Rev 7.3.10.0.142) [ 484.633758] wlcore: Association completed. [ 484.690490] wlcore: ERROR command execute failure 14 [ 484.690490] ------------[ cut here ]------------ [ 484.700195] WARNING: drivers/net/wireless/ti/wlcore/main.c:872 at wl12xx_queue_recovery_work+0x64/0x74 [wlcore], CPU#0: kworker/0:0/892 This repeats endlessly. Always disable IGTK on wl12xx and fix the decrementing mess.
In the Linux kernel, the following vulnerability has been resolved: powerpc/perf: fix preempt count underflow in fsl_emb_pmu_del fsl_emb_pmu_del() unconditionally calls put_cpu_var(cpu_hw_events) at the 'out:' label, but only calls the matching get_cpu_var() after the 'i < 0' early-return check. When event->hw.idx is negative the function jumps to 'out:' without having taken get_cpu_var(), and the trailing put_cpu_var() then issues an unmatched preempt_enable(), underflowing preempt_count. On a CONFIG_PREEMPT=y kernel preempt_count would underflow and eventually present as a 'scheduling while atomic' BUG. Move put_cpu_var() to pair with get_cpu_var() so the percpu access is correctly bracketed and the 'out:' label only handles perf_pmu_enable.
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix memory leak of bonding resources In a corner case of concurrent driver removal and driver reset, bonding resource is first released in hns_roce_hw_v2_exit() during driver removal, and then is allocated again in hns_roce_register_device() during driver reset. This leads to memory leak because the release timing has already passed. This may also lead to a kernel panic as below because of the leaked notifier callback: Call trace: 0xffffa20fccc04978 (P) raw_notifier_call_chain+0x20/0x38 call_netdevice_notifiers_info+0x60/0xb8 netdev_lower_state_changed+0x4c/0xb8 As Sashiko suggested, the teardown order of bonding resources should be inverted to make sure the resources are released when the driver is removed.
In the Linux kernel, the following vulnerability has been resolved: mfd: cs42l43: Sanity check firmware size Currently the code checks if a firmware was received, however it does not verify that the firmware size is larger than the firmware header. As the firmware pointer is dereferenced as a pointer to the header structure this could lead to an out of bounds memory access. Add the missing check.
In the Linux kernel, the following vulnerability has been resolved: coresight: ete: Always save state on power down System register ETMs and ETE are unlikely to be preserved on CPU power down. The ETE DT binding also never documented "arm,coresight-loses-context-with-cpu" so nobody would have legitimately been able to use that binding to fix it and ACPI has no such binding at all. Fix it by hard coding the setting for sysreg ETMs (ETE is always sysreg) or ACPI boots. Use a local variable when setting up save_state so that it's immune to concurrent probing when devices have different configurations which is an issue with modifying the global. This fixes the following error when using Coresight with ACPI on the FVP which supports CPU PM: coresight ete0: External agent took claim tag WARNING: drivers/hwtracing/coresight/coresight-core.c:248 at coresight_disclaim_device_unlocked+0xe0/0xe8, CPU#0: perf/117
In the Linux kernel, the following vulnerability has been resolved: PCI: dwc: Avoid dwc_pcie_rasdes_debugfs_deinit() NULL dereference when no RAS DES capability dwc_pcie_rasdes_debugfs_init() returns success when the controller has no RAS DES capability, leaving pci->debugfs->rasdes_info unset. The common debugfs teardown path still calls dwc_pcie_rasdes_debugfs_deinit(), which dereferences rasdes_info unconditionally. Return early when no RAS DES state was allocated. In that case no RAS DES mutex was initialized, so there is nothing to destroy. [mani: reworded subject]
In the Linux kernel, the following vulnerability has been resolved: Revert "PCI/MSI: Unmap MSI-X region on error" This reverts commit 1a8d4c6ecb4c81261bcdf13556abd4a958eca202. Commit 1a8d4c6ecb4c ("PCI/MSI: Unmap MSI-X region on error") added an iounmap(dev->msix_base) on the error path of msix_capability_init() to release the MSI-X region when msix_setup_interrupts() fails. When msix_setup_interrupts() fails, the call chain is: msix_setup_interrupts() -> __msix_setup_interrupts() struct pci_dev *dev __free(free_msi_irqs) = __dev; ... return ret; // __free cleanup fires on error The __free(free_msi_irqs) cleanup calls pci_free_msi_irqs(), which already handles the unmap: void pci_free_msi_irqs(struct pci_dev *dev) { pci_msi_teardown_msi_irqs(dev); if (dev->msix_base) { iounmap(dev->msix_base); // already unmapped here dev->msix_base = NULL; // and set to NULL } } So dev->msix_base is unmapped and set to NULL before msix_setup_interrupts() returns to msix_capability_init(). The "goto out_unmap" introduced by commit 1a8d4c6ecb4c ("PCI/MSI: Unmap MSI-X region on error") then calls iounmap() a second time on a NULL pointer. This was reproduced on Intel Emerald Rapids (192 CPUs) while running tools/testing/selftests/kexec/test_kexec_jump.sh: WARNING: CPU#44 at iounmap+0x2a/0xe0 RIP: 0010:iounmap+0x2a/0xe0 RDI: 0000000000000000 Call Trace: msix_capability_init+0x317/0x3f0 __pci_enable_msix_range+0x21d/0x2c0 pci_alloc_irq_vectors_affinity+0xa9/0x130 nvme_setup_io_queues+0x2a8/0x420 [nvme] nvme_reset_work+0x151/0x340 [nvme] ... RDI=0 confirms iounmap() is called with NULL. Restore the original "goto out_disable" and leave the unmap to the existing __free(free_msi_irqs) cleanup.
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Avoid double-unpin of DOORBELL/MMIO BOs on free amdgpu_amdkfd_gpuvm_free_memory_of_gpu() unpinned DOORBELL and MMIO remap BOs (which are pinned at allocation time) before checking whether the BO is still mapped to the GPU. When the BO is still mapped, the function returns -EBUSY and leaves the BO alive, but it has already been unpinned. The BO is then unpinned again when it is finally freed during process teardown, triggering a ttm_bo_unpin() underflow warning: WARNING: CPU: 18 PID: 15066 at ttm/ttm_bo.c:650 amdttm_bo_unpin+0x6d/0x80 [amdttm] Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu] RIP: 0010:amdttm_bo_unpin+0x6d/0x80 [amdttm] Call Trace: amdgpu_bo_unpin+0x1a/0x90 [amdgpu] amdgpu_amdkfd_gpuvm_unpin_bo+0x31/0xb0 [amdgpu] amdgpu_amdkfd_gpuvm_free_memory_of_gpu+0x3bf/0x460 [amdgpu] kfd_process_free_outstanding_kfd_bos+0xd4/0x170 [amdgpu] kfd_process_wq_release+0x109/0x1b0 [amdgpu] process_one_work+0x1e2/0x3b0 worker_thread+0x50/0x3a0 kthread+0xdd/0x100 ret_from_fork+0x29/0x50 Move the unpin after the mapped_to_gpu_memory check so it only happens once we are committed to freeing the BO. (cherry picked from commit 927c5b2defb9b09856444d94bebfd056a002bd75)
In the Linux kernel, the following vulnerability has been resolved: ACPI: processor_idle: Mark LPI enter functions as __cpuidle When function tracing or Kprobes is enabled, entering an ACPI Low Power Idle (LPI) state triggers the following RCU splat: RCU not on for: acpi_idle_lpi_enter+0x4/0xd8 WARNING: CPU: 8 PID: 0 at include/linux/trace_recursion.h:162 function_trace_call+0x1e8/0x228 The acpi_idle_lpi_enter() function is invoked within the cpuidle path after RCU has already been disabled for the current local CPU. Consequently, ftrace's function_trace_call() expects RCU to be actively watching before recording trace data, emitting a warning if it is not. Fix this by annotating acpi_idle_lpi_enter(), the generic __weak stub, and the RISC-V implementation of acpi_processor_ffh_lpi_enter() with __cpuidle. This moves these functions into the '.cpuidle.text' section, implicitly disabling ftrace instrumentation (notrace) along this sensitive path and preventing trace-induced RCU warnings during idle entry.
In the Linux kernel, the following vulnerability has been resolved: tracing/probes: Remove WARN_ON_ONCE from parse_btf_arg Sashiko found that user can cause this WARN_ON_ONCE() easily with adding a kprobe event based on a raw address with BTF parameter. Since this is not an unexpected condition, remove the WARN_ON_ONCE().
In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd/lbr: Fix kernel address leakage A user-only branch stack can contain branches that originate from the kernel. As a result, kernel addresses are exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. On AMD processors supporting X86_FEATURE_AMD_LBR_V2, perf can still report SYSRET/ERET entries for which the branch-from addresses are in the kernel. E.g. $ perf record -e cycles -o - -j any,save_type,u -- \ perf bench syscall basic --loop 1000 | \ perf script -i - -F brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' ... 0xffffffff81001268/0x717a90a38f1a/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a39157/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a2c628/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a41b60/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a260db/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a260db/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a8bef1c30/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a8e4d3c90/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH ... The reason is that the hardware filter only considers the privilege level applicable to the branch target. Extend software filtering to also validate the branch-from addresses against br_sel, so that any branch record whose branch-from address is in the kernel is dropped when PERF_SAMPLE_BRANCH_USER is requested.
In the Linux kernel, the following vulnerability has been resolved: samples/damon/mtier: fail early if address range parameters are invalid The comment on top of `struct damon_region` clearly says that For any use case, @ar should be non-zero positive size. which is now verified in damon_verify_new_region() if the kernel is built with DAMON_DEBUG_SANITY. The WARN_ONCE() can be triggered if the mtier sample module is enabled before node{0,1}_{start,end}_addr have been properly initialized, which is obviously not good. ------------[ cut here ]------------ start 0 >= end 0 WARNING: mm/damon/core.c:217 at damon_new_region+0xf4/0x118, CPU#59: bash/341468 Call trace: damon_new_region+0xf4/0x118 (P) damon_set_regions+0xfc/0x3c0 damon_sample_mtier_build_ctx+0xe8/0x3a8 damon_sample_mtier_start+0x1c/0x90 damon_sample_mtier_enable_store+0x98/0xb0 param_attr_store+0xb4/0x128 module_attr_store+0x2c/0x50 sysfs_kf_write+0x58/0x90 kernfs_fop_write_iter+0x16c/0x238 vfs_write+0x2c0/0x370 ksys_write+0x74/0x118 __arm64_sys_write+0x24/0x38 invoke_syscall+0xa8/0x118 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x54/0x370 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0 ---[ end trace 0000000000000000 ]--- Note that the same issue can happen if detect_node_addresses is true, and node 0 or 1 is memoryless. Fix it together by checking the validity of parameters right before damon_new_region() and fail early if they're invalid.
Unauthenticated mass PII enumeration in the User Frontend WordPress plugin (versions 4.3.0 through 4.3.10) exposes the email address and phone number of every registered user - including site administrators - via an unrestricted user directory search endpoint. The flaw requires no authentication, no special configuration, and is automatable per SSVC, making bulk harvesting trivial for any remote attacker. A publicly available proof-of-concept exploit exists, reported by WPScan, though active exploitation has not been confirmed by CISA KEV at time of analysis.
Memory exhaustion vulnerabilities in openNDS before 11.0.0 allow an unauthenticated attacker on the captive portal network to crash the portal daemon within minutes by triggering unfreed heap allocations in the authentication handler. The root cause is CWE-401 (missing memory release) in src/auth.c, where intermediate buffers allocated during gateway interface lookups in client_auth() are never freed on certain code paths. No confirmed active exploitation exists and no CISA KEV listing is present, but the attack surface is inherently broad in public hotspot deployments where any connected device can trigger the vulnerable authentication flow.
Guest Wi-Fi configuration exposure in TOTOLINK T6 firmware 4.1.5cu.748_B20211015 allows any adjacent-network attacker without credentials to retrieve the router's guest wireless settings by sending a crafted POST to /cgi-bin/cstecgi.cgi invoking the getWiFiGuestCfg function. The CGI dispatcher performs no session or privilege check before returning guest SSID and passphrase data, a pattern consistent with multiple other access-control deficiencies in the same firmware. No public exploit code or active exploitation has been identified; EPSS stands at 0.18% (7th percentile) and SSVC rates technical impact as partial.
Unauthenticated information disclosure in TOTOLINK T6 firmware 4.1.5cu.748_B20211015 exposes mesh neighbor table data to any attacker on the adjacent network. The getMeshNeighborTable function in the /cgi-bin/cstecgi.cgi CGI interface fails to enforce access control, allowing a crafted POST request to retrieve mesh network topology without credentials. No public exploit or active exploitation is confirmed; EPSS at 0.18% and SSVC exploitation status of 'none' indicate minimal real-world threat at present.
Cleartext cluster key disclosure in Wazuh 4.14.0-4.14.6 allows any low-privilege API user with the default readonly or cluster_readonly role to retrieve the shared secret that authenticates and encrypts all inter-node cluster traffic. The GET /cluster/local/config endpoint was missing the mask_sensitive_config decorator applied to every sibling config endpoint, causing the cluster.key field to be returned unredacted to accounts that are explicitly denied update-config permission. The severity of this information disclosure is amplified by prior Wazuh advisories that establish cluster-peer remote code execution chains contingent on possessing the cluster key, making this a practical stepping stone to full cluster compromise. No public exploit has been identified at time of analysis and the vulnerability is not in the CISA KEV catalog.
WatchGuard Dimension's web login endpoint permits unlimited automated password guessing against user accounts because rate-limiting and account lockout are both absent in the default product configuration. All versions of Dimension (CPE wildcard, no version boundary) are affected in default-configured deployments. An unauthenticated remote attacker can systematically guess credentials and gain unauthorized account access; the CWE-203 classification further indicates the endpoint may expose observable discrepancies that enable username enumeration, reducing the effort required for targeted credential attacks. No public exploit has been identified at time of analysis and no CISA KEV listing exists.
Plaintext administrative credential exposure in the Ebyte NE2-D11 firmware management interface allows anyone with physical access to directly observe device credentials without any authentication or tooling. Reported by ICS-CERT under advisory ICSA-26-237-06, the flaw (CWE-522) affects all known firmware versions per CPE data, with a physical attack vector (AV:P) confirming that exploitation requires proximity to the device. Credential capture could enable full administrative control over the device, with downstream risk to industrial operations where the NE2-D11 is deployed. No public exploit has been identified and the vulnerability is not listed in CISA KEV.
Cleartext transmission of OAuth credentials in RooCodeInc Roo-Code up to version 3.51.1 exposes sensitive OAuth tokens to interception via the OAuth callback handler in src/integrations/claude-code/oauth.ts. The vendor has officially archived the repository and explicitly discourages continued use, meaning no patch will be issued. A public proof-of-concept is available on GitHub, though high attack complexity (requiring a network interception position) constrains opportunistic exploitation.
Out-of-bounds read in Adobe DNG SDK 1.7.1 2502 and earlier exposes sensitive memory contents when a victim opens a maliciously crafted DNG file. The flaw resides in the SDK's file parser and affects any application built on top of the DNG SDK that processes untrusted DNG inputs. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV, limiting current urgency despite the High confidentiality impact.
Sensitive KMS provider credentials supplied for client-side field-level encryption (CSFLE) in the MongoDB C# Driver are reproduced in plaintext within the driver's diagnostic string representation of its client settings, rather than being masked like other secret fields. Any party with read access to application logs, diagnostic output, or process memory dumps can recover these credentials and independently invoke the key management service to unwrap data-encryption keys, compromising all data protected by those keys. No public exploit code or active exploitation in CISA KEV has been identified at time of analysis; exploitation is bounded by the requirement that CSFLE be configured and that the attacker have access to diagnostic output.
NoSQL injection in the MongoDB C# Driver's document-replacement code path allows network-accessible, low-privileged attackers to inject MongoDB query-language operators into database operations. The driver omits the element-name and shape validation applied by other write paths, so untrusted loosely-typed input (BsonDocument, Dictionary, dynamic) is forwarded to the MongoDB server unfiltered, enabling attacker-controlled data to be interpreted as update logic under the application's own database credentials. No public exploit or CISA KEV listing has been identified at time of analysis; exploitation is bounded to applications that use loosely-typed replacement patterns rather than strongly-typed C# document mappings.
Namespace injection in MongoDB C Driver (libmongoc) allows any caller-controlled database or collection name containing a '.' separator or NUL byte to redirect a MongoDB operation to an unintended resource. Applications that incorporate unsanitized user input into these name components are affected across all libmongoc versions prior to 2.5.1. No public exploit has been identified at time of analysis; the vendor released a validated fix in version 2.5.1.
Input injection in MongoDB libmongocrypt's automatic-encryption context setup permits caller-supplied database and collection name arguments containing '.' or NUL bytes to pass without sanitization, causing incorrect schema selection during Client-Side Field Level Encryption (CSFLE) operations. Affected callers - those with local access and low privileges - may obtain limited unauthorized disclosure or modification of data processed under the wrong encryption schema. No public exploit code exists and this vulnerability is not in CISA KEV; the CVSS 4.0 score of 2.0 reflects the constrained real-world impact.
Unsafe header deserialization in Spring Integration's EmbeddedHeadersJsonMessageMapper exposes applications to header injection across all active release trains (5.5.x through 7.1.0). The decodeNativeFormat method constructs GenericMessage objects with MutableMessageHeaders populated directly from attacker-controlled JSON-deserialized header maps, bypassing sanitization by default in the constructor. Low-privileged network attackers who can submit crafted byte payloads to an affected consumer channel can manipulate message headers, yielding partial confidentiality, integrity, and availability impacts. No public exploit has been identified at time of analysis and this CVE is not listed in CISA KEV.
Concurrent message processing in Spring Integration's script-backed channels causes shared ScriptEngine state corruption when using JSR-223 engines that declare THREADING=null, such as the Kotlin KTS engine. Affected Spring Integration versions from 5.5.21 and earlier through 7.1.0 are susceptible to cross-message data leakage, where one message's payload or header bindings can bleed into another message's script evaluation context under concurrent load. No public exploit has been identified at time of analysis, and the CVSS 4.2 Medium rating reflects the high attack complexity imposed by the required race condition, though the information disclosure and partial integrity impact are real concerns in multi-tenant or high-throughput deployments.
Link credit exhaustion in Spring AMQP 4.1.0 silently stalls AMQP listener containers when a container-level ErrorHandler is active. Each message delivery whose processing throws an exception permanently consumes one link credit without returning it to the broker; once the pool reaches zero (after the default 100 credits), the broker halts delivery while isRunning() continues to report true, masking the outage from standard health checks. No active exploitation has been confirmed (no CISA KEV listing, no public POC), but this is a realistic denial-of-service condition for any Spring-based messaging consumer running the affected version with an ErrorHandler configured.
Denial-of-service in Spring for Apache Kafka's `DeadLetterPublishingRecovererFactory` exposes consumer JVMs across all supported branches (2.8.x through 4.1.0) to crash or hang when processing messages with a crafted `retry_topic-original-timestamp` header. An authenticated Kafka producer can inject a ConsumerRecord carrying an oversized or malformed header byte array, which is passed without any length or format validation directly to Java's `BigInteger(byte[])` constructor, triggering heap memory exhaustion or an unhandled exception that disrupts message consumption. No public exploit code has been identified and the CVE does not appear in CISA KEV at time of analysis, but low attack complexity combined with broad version coverage makes this a credible availability threat for any Spring Kafka deployment using retry or dead-letter queue features.
Symlink redirection in Spring Integration's Zip/UnZip transformer allows a local unprivileged user sharing the same host to hijack transformer output by pre-creating /tmp/ziptransformer as a symlink before application startup. Affected versions span the 6.4, 6.5, 7.0, and 7.1 release lines, covering a wide range of enterprise Java deployments that use Spring Integration's file transformation capabilities. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in CISA KEV, though the integrity and availability impact is rated High by the vendor-assigned CVSS score.
Spring Cloud Stream's partition interceptor logic improperly inserts a partition interceptor during message sends under specific conditions, potentially routing messages to unintended partitions. Affected versions span three active release lines: 5.0.0-5.0.2, 4.3.0-4.3.3, and 4.2.0-4.2.6. An authenticated operator with high privileges who triggers a message send under the required conditions could cause limited information disclosure or message integrity degradation by routing data to an unintended partition consumer. No public exploit identified at time of analysis; CVSS score of 3.1 reflects the high access bar and narrow impact.
Improper content-type caching in the Avro component of Spring Cloud Stream can produce incorrect content-type metadata on processed messages, creating a low-severity information-disclosure and data-integrity risk. Affected versions span the 4.2.x, 4.3.x, and 5.0.x release trains. Exploitation requires network access, high privilege level, high attack complexity, and user interaction, making real-world impact minimal; no public exploit code or active exploitation has been identified at time of analysis.
Sensitive data exposure in Spring Cloud Stream versions 4.2.0-4.2.6, 4.3.0-4.3.3, and 5.0.0-5.0.2 allows logging of sensitive information - such as message payloads, headers, or configuration values - under specific conditions. The vulnerability is classified as information disclosure with a low CVSS base score of 3.1, reflecting the high attack complexity and privilege requirements. No public exploit code has been identified and this vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog.
Spring Cloud Function's Azure integration may inadvertently log sensitive data across three affected release lines (4.2.0-4.2.7, 4.3.0-4.3.4, 5.0.0-5.0.3), resulting in low-impact information disclosure. The vulnerability is constrained by a high-privilege, high-complexity, user-interaction-required exploitation profile (CVSS 3.1), making it a low-priority issue for most organizations. No public exploit code exists and the vulnerability has not been added to the CISA KEV catalog; the primary risk is credential or token leakage through application log aggregators accessible to operators or compromised log pipelines.
Spring Cloud Function's AWS adapter component may inadvertently write sensitive data to application logs, creating an information disclosure exposure across a wide range of maintained version branches (3.x through 5.x). The CVSS score of 3.1 reflects genuinely low severity - exploitation requires high privileges and high attack complexity - but the risk in regulated or multi-tenant environments is elevated if log stores are accessible to unauthorized parties or if sensitive data (credentials, payloads, tokens) persists in cloud-native logging services such as AWS CloudWatch. No public exploit code exists and no active exploitation has been identified at time of analysis.
Spring Cloud Function's composition lookup mechanism can be abused by a highly privileged attacker to poison the base function, potentially degrading the integrity and confidentiality of function execution across versions 3.2.16 and earlier through 5.0.3. The vendor-assigned CVSS base score of 3.1 reflects severely constrained exploitation prerequisites - high privilege level, high attack complexity, and required user interaction - substantially limiting realistic exposure. No public exploit code has been identified, and the vulnerability does not appear in the CISA KEV catalog at time of analysis.
HTTP header filtering deficiency in Spring Cloud Function versions 5.0.0-5.0.3, 4.3.0-4.3.4, 4.2.0-4.2.7, and 3.2.16 and earlier allows network-accessible authenticated attackers - under high-complexity conditions and requiring user interaction - to achieve limited confidentiality and integrity impacts via crafted HTTP headers. Reported by VMware, the flaw scores 3.1 (Low) under CVSS 3.1, with multiple compounding prerequisites that substantially restrict real-world exploitability. No public exploit code and no CISA KEV listing have been identified at time of analysis.
Spring Cloud Function's ServerlessHttpServletRequest.isSecure() method returns an unchecked result that does not reflect the actual HTTP transport scheme, enabling applications that gate security decisions on this call to behave incorrectly. Affected versions span three active release lines: 5.0.0-5.0.3, 4.3.0-4.3.4, and 4.2.0-4.2.7. No public exploit code exists and the vulnerability is not listed in CISA KEV; the vendor-assigned CVSS of 3.1 (Low) reflects constrained exploitation prerequisites including high privilege and user interaction.
Spring Integration's jCIFS-based SMB client silently negotiates down to legacy SMB1/CIFS when applications omit an explicit `smbMinVersion` setting, exposing file transfer sessions to NTLM relay attacks and in-transit content tampering by a network-positioned adversary. Affected versions span Spring Integration 6.4.0-6.4.12, 6.5.0-6.5.10, 7.0.0-7.0.5, and the standalone release 7.1.0 - covering all currently active Spring Integration release trains at time of disclosure. No CISA KEV listing or public exploit code specific to this CVE has been identified at time of analysis, though NTLM relay is a mature, extensively tooled attack class; EPSS data was not available in the sourced intelligence.
Spring Integration's default file-based metadata store writes persistent state to a world-readable file under java.io.tmpdir, exposing integration metadata to any local OS user on the affected host. All actively maintained branches are affected, spanning versions 5.5.21 and earlier through 7.1.0. No public exploit code or active exploitation has been identified at time of analysis; practical impact is limited to local confidentiality disclosure on shared or multi-user systems.
Spring Security 7.1.0's InetAddressMatchers utility contains a flaw in its IP address classification logic - the matchInternal() and matchExternal() builders may incorrectly categorize certain IP addresses as belonging to internal or external networks, enabling unauthenticated remote attackers to bypass IP-based access controls under high-complexity conditions. Applications that rely on InetAddressMatchers to enforce network-level access restrictions are exposed to limited information disclosure where restricted endpoints or data may become accessible to external parties. No public exploit code exists and no CISA KEV listing is present, indicating no confirmed active exploitation at time of analysis.
Timing side-channel exposure in Spring Security allows remote unauthenticated attackers to progressively infer security-sensitive string values - such as CSRF tokens, bearer tokens, or other secrets compared at the application layer - by statistically measuring the time differential between rejection responses. Multiple active Spring Security release trains are affected, spanning versions 5.7.x through 7.1.x, representing a broad swath of production Spring-based Java applications. No public exploit code has been identified at time of analysis, and CISA KEV status is absent; however, the confidentiality impact is rated High in the CVSS vector, reflecting that successful exploitation could fully compromise protected secrets under favorable network conditions.
Job deduplication in the cakephp/queue plugin can be bypassed by attackers who control job parameter data, causing legitimate unique jobs to be silently dropped. The flaw affects all applications using `shouldBeUnique = true` on job classes where user-supplied input is passed as job parameters - versions 0.1.10 through 2.3.0. No public exploit identified at time of analysis, and the CVSS score of 3.7 (AV:N/AC:H) reflects that exploitation requires knowledge of the target application's job parameter schema.
TLS certificate validation is absent by default in Spring AMQP's Log4j2 appender when shipping log events to a RabbitMQ broker, leaving all log traffic fully exposed to man-in-the-middle interception. Spring AMQP versions 2.4.18 and earlier, 3.2.0-3.2.12, 4.0.0-4.0.4, and 4.1.0 are affected when the Log4j2 appender is used with its documented default configuration. No public exploit has been identified at time of analysis, but the high confidentiality and integrity CVSS impact reflects that intercepted log streams may contain API keys, session tokens, and other sensitive application data.
TLS bypass in Grafana's ClickHouse Datasource plugin (versions 3.1.0 through 4.20.0) silently transmits database traffic in cleartext when the Native protocol is routed through a PDC or secure SOCKS proxy, despite TLS being configured. The underlying connection library ignores the TLS request without raising an error, exposing ClickHouse usernames, passwords, SQL queries, and query results to any attacker positioned on the network hop between the proxy and the database server. No public exploit has been identified at time of analysis and the vulnerability is not listed in the CISA KEV catalog.
MongoDB BI Connector's mongodrdl tool leaks TLS private-key passwords to standard error when the password is simultaneously supplied via both the connection URI and a corresponding command-line option. Affected versions span BI Connector 2.12.0 through 2.14.29; the fix is version 2.14.30. A local attacker who can read captured stderr output and also possesses the encrypted TLS client key file can combine those two artifacts to authenticate as the legitimate TLS client identity. No public exploit code or active exploitation has been identified at time of analysis.
Out-of-bounds heap read in the DHCPv4 packet capture code of wicked (all versions through 0.6.80) allows an unauthenticated attacker on the same Layer-2 network segment to send a crafted DHCP/UDP packet that causes wickedd-dhcp4 to read up to 68 bytes past the end of its 1500-byte receive buffer. Adjacent heap contents - including allocator metadata and pointer values - may be parsed as DHCP options and stored into lease fields, constituting limited information disclosure with a secondary low-integrity configuration impact. No public exploit code and no CISA KEV listing have been identified at time of analysis; an upstream fix exists in GitHub PR #1079, though a tagged release version has not been independently confirmed.
Integer underflow in the wicked DHCPv4 packet capture daemon (wickedd-dhcp4) on SUSE Linux systems allows an unauthenticated adjacent-network attacker to crash the daemon by sending a malformed DHCPv4 packet with an IP total length field smaller than the IP header length. The missing bounds check in ni_capture_inspect_udp_header() triggers an out-of-bounds read, causing a process crash depending on memory layout - resulting in a denial of service to network configuration. No information disclosure has been demonstrated, and no public exploit or CISA KEV listing exists at time of analysis.
Local information disclosure in the openssl-encrypt pip package (versions ≤ 1.4.8) exposes steganography passwords to all unprivileged users on the same Linux host. When the desktop GUI initiates an encrypt or decrypt operation involving the steganography feature, it spawns a CLI child process with the password supplied as the `--stego-password` command-line argument rather than via an environment variable, making it readable from `/proc/<pid>/cmdline` for the entire subprocess lifetime by any local user. The main encryption password is handled correctly via environment variable and is unaffected. A vendor-released patch is available in version 1.4.9; no public exploit has been identified at time of analysis.
Out-of-bounds read and write primitives in the hank-ai Darknet neural network framework (all versions through 6.0) are triggered by parsing a crafted configuration file, yielding a reliable crash and a single fixed-byte heap write at an attacker-controlled offset. The parser in src-lib/darknet_cfg.cpp consumes the `from` field of shortcut, scale_channels, and sam sections-and the `layers` field of route sections-as a direct array index into the layer heap allocation without validating it against the array's declared size. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV.
DNS rebinding in Dropbox's mcp-server-dash (network mode) allows a malicious web page to reach the local MCP listener and invoke Dropbox API tools - company-search and file-detail - under the victim's stored Dropbox credential. The server bound to the loopback interface but performed no Host header validation, letting a browser issue cross-origin requests via a rebound domain that resolves to 127.0.0.1. No public exploit has been identified at time of analysis; CVSS 4.0 scores this at 2.3, reflecting the attack's prerequisites of user interaction and a specific deployment mode.
Token exfiltration in airtable-mcp-cli before 0.2.5 allows an attacker who convinces a user to run the configure command with a malicious endpoint URL to receive the user's Airtable personal access token on every subsequent CLI invocation. The root cause is that ConfigureCommand.execute in src/cli.ts persisted the --endpoint option directly into the user profile, bypassing the createSafeUrl helper in src/config.ts that already enforced HTTPS and vendor-host restrictions for the environment-variable pathway. Because src/mcp.ts attaches the stored token as a bearer credential on every outbound request, the stolen token grants full API-level access to the victim's Airtable account. No public exploit or CISA KEV listing has been identified at time of analysis.
Account footprinting via observable discrepancy in Seres Software syWEB exposes valid user account existence to unauthenticated remote attackers. All versions through 27082026 are affected, and the vendor has confirmed the product is end-of-life with no support - meaning no patch will ever be released. No public exploit code or CISA KEV listing has been identified, but the permanently unpatched status elevates long-term risk for any remaining deployments.
Symlink following in Dool (versions up to and including 1.3.8) allows a local attacker to cause arbitrary file truncation and overwriting when the tool is run with the non-default '--devel' flag. The vulnerable code path opens a log file without the O_NOFOLLOW flag (CWE-59), allowing a pre-placed symlink to redirect the write to any file the dool process can access - an impact that escalates from trivial to severe if dool runs under elevated privileges such as root. No public exploit code or CISA KEV active exploitation is identified; the issue was reported by CERT-PL and addressed upstream via pull request #116.
Session invalidation failure in HCL IntelliOps Event Management (IEM) v1.3 and v1.4 allows session tokens to persist as valid after an admin explicitly logs out or an administrator deletes the session. An attacker who has previously captured a valid session token - through network interception, XSS, or other means - can replay that token post-logout to retain unauthorized access to admin-level functionality. No public exploit code has been identified at time of analysis, and EPSS/KEV data are not available for this CVE.
Session tokens in HCL IntelliOps Event Management (IEM) versions 1.3 and 1.4 persist as valid on the server after a user logs out or an account is deleted, allowing an attacker who has previously captured a legitimate session token to replay it and maintain unauthorized access beyond the intended session lifecycle. The root cause is CWE-613 (Insufficient Session Expiration), where server-side session records are not destroyed upon logout or account removal. No public exploit code or active exploitation has been identified at time of analysis, and the CVSS 6.4 Medium score reflects meaningful constraints on exploitation including high attack complexity and required user interaction.
Finale Lite WordPress plugin before 2.21.0 exposes sales campaign configuration and scheduling data to any subscriber-level authenticated user due to a missing capability check on a WordPress AJAX action. The unprotected endpoint accepts an arbitrary post ID and returns the associated campaign's settings without verifying that the requesting user holds appropriate privileges. No public exploit code has been identified and CISA has not listed this in the KEV catalog, though the low authentication barrier makes opportunistic reconnaissance straightforward.
LearnPress WordPress plugin versions up to and including 4.0.2 expose order payment status data through an unauthenticated REST endpoint that omits authorization checks entirely. The CVSS vector (PR:N/AC:L/AV:N) confirms remote unauthenticated exploitation with no preconditions, and SSVC flags the attack as automatable - meaning scripted enumeration of order identifiers at scale is trivially achievable. No public exploit has been identified at time of analysis, and EPSS at 0.14% (4th percentile) reflects negligible current exploitation interest, though the missing permission check pattern is well-understood by WordPress-focused threat actors.
Spring Integration's UnZipTransformer component fails to impose any limit on decompressed entry size or entry count, enabling a low-privileged remote attacker to trigger JVM heap exhaustion via a crafted zip bomb archive. Affected versions span 6.4.0-6.4.12, 6.5.0-6.5.10, and 7.0.0-7.1.0 across the widely-used Spring enterprise Java framework. The attack primitive is well-understood and trivially constructable, though exploitation requires access to an integration endpoint that routes payloads through UnZipTransformer; no public exploit code has been identified at time of analysis and this CVE is not listed in the CISA KEV catalog.
Arbitrary file write outside the worktree boundary in gix-worktree-state (part of gitoxide) before 0.33.0 on Windows enables an attacker-controlled repository to overwrite files at arbitrary paths on a victim's filesystem. The flaw manifests when gix_worktree_state::checkout() performs an incremental materialization: a malicious repo first places a symlink entry at path P pointing outside the worktree, then a subsequent incremental checkout of a regular-file entry at the same path follows the Windows reparse point and writes attacker-supplied blob content through the link. No public exploit code is identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.
Stale public share links in filebrowser through 2.63.23 can silently redirect to unrelated files uploaded after a rename operation, unexpectedly exposing new content to anyone holding the original link. The defect (CWE-459, Incomplete Cleanup) arises because share records are keyed by file path rather than a file identifier - deletion triggers cleanup, but rename does not, leaving the share dormant. No public exploit or CISA KEV listing exists at time of analysis, and the CVSS 4.0 score of 2.3 reflects the multi-step preconditions required, but the confidentiality risk is real for deployments where multiple users share create permissions on overlapping directories.
Stale public share links in File Browser 2.63.6-2.63.23 expose subsequently uploaded content to unauthenticated network access after a privileged user deletes another user's shared file without triggering proper link invalidation. Because the surviving share URL continues to resolve to whatever is later placed at the same storage path, an attacker who retains or discovers the original link can retrieve entirely unrelated files without authentication. No public exploit code is identified at time of analysis, and the CVSS 4.0 score of 2.3 reflects the constrained, multi-step preconditions required.
Unauthenticated information disclosure in WWBN AVideo through version 30.0 exposes user registration statistics via two unprotected PHP endpoints. The report4.json.php and report4.1.json.php files return daily and cumulative user-registration counts to any remote requester without authentication or session validation. No public exploit code has been identified at time of analysis and this vulnerability is not listed in the CISA KEV catalog; however, its trivial exploitation path and network accessibility make it easy for any actor who can reach the server to enumerate platform growth data.
Timing side-channel in OX Dovecot Pro and CE exposes the length of configured doveadm passwords and API keys to adjacent-network attackers who can send repeated unauthenticated requests and measure response latency with high precision. The secret value itself is never disclosed - only its length - which marginally reduces brute-force search space. No active exploitation is identified and no public exploit exists; the vendor-assigned CVSS score of 3.1 accurately reflects the constrained attack surface and limited practical impact.
Memory disclosure in OX Dovecot Pro and OX Dovecot CE exposes uninitialized server process memory to authenticated IMAP users who send a malformed URLFETCH command. The IMAP URLAUTH extension's error-handling path fails to sanitize its response buffer, returning raw memory contents to the requesting client that may include session tokens, cached credentials, or message data from co-resident sessions. No active exploitation has been identified and no public exploits are known, though the low attack complexity for authenticated users makes insider threats and compromised accounts realistic vectors.
IMAP compression in OX Dovecot Pro and CE enables a CRIME/BREACH-class side-channel attack where shared compression state across session responses leaks information about mailbox contents. An adversary who can both send mail to a target user and observe the byte sizes of that user's IMAP traffic can use response-size variations to confirm whether a small message body matches a guessed candidate text. No public exploits are known and the attack has not been confirmed as actively exploited; arbitrary content recovery was not demonstrated, bounding real-world impact to oracle-style guess confirmation against short messages.
Authenticated availability disruption in OX Dovecot Pro and OX Dovecot CE allows any valid credential holder to crash the imap-hibernate service by opening many concurrent connections and sending malformed IMAP commands, triggering an intermittent out-of-bounds read (CWE-125). The crash terminates the imap-hibernate process, dropping hibernated IMAP sessions for co-hosted users and degrading service availability. No public exploit code is known and the vulnerability is not listed in CISA KEV; however, the low attack complexity means any authenticated user on a shared mail platform could attempt disruption.
In the Linux kernel, the following vulnerability has been resolved: mm: mglru: fix stale batch updates after memcg reparenting The mglru page table walker batches per-generation size deltas in walk->nr_pages while walking page tables without holding the lruvec lock. The reset_batch_size() later folds those deltas into walk->lruvec under the lruvec lock. The page table walker can run concurrently with the memcg reparenting path as follows: CPU0 CPU1 ==== ==== walk_mm --> walk_page_range --> update_batch_size --> walk->nr_pages += delta mem_cgroup_css_offline --> memcg_reparent_objcgs --> lock lruvec lru_gen_reparent_memcg --> reparent child folios to parent unlock lruvec lock lruvec reset_batch_size --> child lrugen->nr_pages += delta This will trigger the following warning in lru_gen_exit_memcg(): VM_WARN_ON_ONCE(memchr_inv(lruvec->lrugen.nr_pages, 0, sizeof(lruvec->lrugen.nr_pages))); And the user-visible impact of underestimated nr_pages in MGLRU was premature OOMs because MGLRU does not try to reclaim memory when nr_pages reaches zero, but there are still more pages. To fix it, make reset_batch_size() check CSS_DYING under RCU before flushing the pending batch. A non-dying memcg keeps the original lruvec stable against RCU-delayed offlining; a dying memcg redirects the deltas to the first non-dying ancestor.
In the Linux kernel, the following vulnerability has been resolved: igc: remove napi_synchronize() in igc_down() When an AF_XDP zero-copy application is killed abruptly, the XSK pool is torn down but NAPI keeps polling. igc_clean_rx_irq_zc() then returns the full budget on every poll, so napi_complete_done() never clears NAPI_STATE_SCHED. igc_down() calls napi_synchronize() before napi_disable(), so it spins forever waiting for that bit and the interface never goes down. Drop the napi_synchronize() and let napi_disable() do the job -- it sets NAPI_STATE_DISABLE, which forces the stuck poll to complete. Reorder it ahead of igc_set_queue_napi() so the NAPI mapping is cleared only after polling has stopped, matching the recent igb fix b1e067240379.
In the Linux kernel, the following vulnerability has been resolved: power: supply: max17040: handle missing status supplier MAX17040 does not report charger state itself, so the driver forwards POWER_SUPPLY_PROP_STATUS to a supplier power supply. If no supplier is registered, power_supply_get_property_from_supplier() returns -ENODEV and leaves the output value untouched. max17040_get_property() currently ignores that error and returns success, so userspace can read an uninitialized status value from the battery power supply. This happens on systems that use the fuel gauge without a charger supplier relationship in firmware. Return POWER_SUPPLY_STATUS_UNKNOWN when no supplier provides STATUS, and propagate other supplier lookup errors.
In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Fix missing mem scrub at clear key import in cca_clr2cipherkey() The helper function _ip_cprb_helper() uses internal buffer memory for building and processing CPRBs. After use this buffer was never scrubbed which could lead to leaving for example clear key material in memory which could be exposed via tricky reuse of this same memory. Extend the _ip_cprb_helper() function with another parameter 'scrub' used to steer scrubbing of this buffer. So now the caller has the opportunity to decide if scrubbing is needed or not. Extend the clear key to secure key token import process in function cca_clr2cipherkey() to tell the helper function from above to scrub the cprb buffer when the clear key value is part of the request data. Add explicit scrubbing on return from function cca_clr2cipherkey() for the random EXOR buffer and the cprb buffer. Overall this cleans the internal used buffer in case of clear key import to prevent sensitive data to get exposed.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: check if dml21_add_phantom_plane() is successful Verify that the phantom plane was allocated to avoid a later segfault. (cherry picked from commit 5adb54abe5a8e82cbff7f8806db30a5f4924329f)
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Avoid double-deactivate of IRQs in the nested context In the nested state, the physical interrupt has already been deactivated through the HW bit in the LR. The extra deactivation would be harmless but can hit an errata case on AmpereOne, so avoid it here. On AmpereOne, deactivating a physical interrupt through ICC_DIR_EL1 or ICC_EOIR1_EL1 (depending on EOImode) which is not active, but is the highest priority pending interrupt causes the cpu to lose the interrupt pending state and also prevents the delivery of future interrupts.
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix double free of wq, engine, and group structs The release callbacks for wq, engine, and group devices (idxd_conf_wq_release, idxd_conf_engine_release, idxd_conf_group_release) each call kfree() on the enclosing struct. The setup error paths and cleanup functions also call kfree() explicitly after put_device(), producing a double free whenever put_device() drops the reference count to zero and fires the release. In the setup functions, device_initialize() is called before device_add(), so the reference count is exactly 1 at the error sites. put_device() unconditionally fires the release, which frees the struct; the subsequent explicit kfree() then operates on freed memory. For idxd_setup_wqs(), the wq release callback also owns opcap_bmap and wqcfg. The error unwind additionally freed those fields explicitly before calling put_device(), causing further double frees on both. Remove the redundant explicit kfree() calls from all setup error paths and cleanup functions for wq, engine, and group structs, delegating sole ownership of those allocations to the release callbacks.
In the Linux kernel, the following vulnerability has been resolved: hwmon: (sht3x) Fix unaligned accesses Sashiko reports: In sht3x_update_client(), the 16-bit temperature and humidity values are extracted from a stack-allocated byte array using be16_to_cpup(). The pointers passed to this function are calculated as buf and buf + 3. Since the difference between the two pointers is an odd number of bytes, at least one of them is guaranteed to be at an unaligned offset. This will trigger an alignment fault on strict-alignment architectures such as ARMv5 or SPARC, resulting in a kernel panic. Fix the problem by using get_unaligned_be16() instead of be16_to_cpup(), and put_unaligned_be16() instead of cpu_to_be16().
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Initialize hba->rpmbs list in ufshcd Initialize the hba->rpmbs list in ufshcd_alloc_host() to prevent NULL pointer dereference in the device teardown path if ufs_rpmb_probe() fails.
In the Linux kernel, the following vulnerability has been resolved: riscv: drop __init from vec_check_unaligned_access_speed_all_cpus This function runs within a kthread and need not necessarily finish before system finishes boot and free_initmem() unmaps the .init.text section. This function makes calls to SBI for probing unaligned access speed, and if this is slow for some reason (say some debug prints were added to SBI), the kthread can still be running at this point and result in an instruction page fault when trying to fetch from the freed region. [ 25.642087] Unable to handle kernel paging request at virtual address ffffffff80a04ef8 [ 25.646694] Current vec_check_unali pgtable: 4K pagesize, 48-bit VAs, pgdp=0x00004000316e9000 [ 25.653170] [ffffffff80a04ef8] pgd=000010004be7e401, p4d=000010004be7e401, pud=000010004be7e001, pmd=000010000c3000e3 [ 25.661244] Oops [#1] [ 25.662997] Modules linked in: [ 25.665357] CPU: 3 UID: 0 PID: 42 Comm: vec_check_unali Not tainted 7.0.0-tt-blackhole-asrinivasan-00007-g30ff73f18211 #570 PREEMPTLAZY [ 25.674669] Hardware name: Tenstorrent Blackhole (DT) [ 25.678545] epc : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.683458] ra : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.688372] epc : ffffffff80a04ef8 ra : ffffffff80a04ef8 sp : ffff8f8000203e20 [ 25.693874] gp : ffffffff814dc168 tp : ffffaf8001ad9900 t0 : 0000000000000000 [ 25.699401] t1 : fffffffffffffff0 t2 : ffffaf8001ad9a10 s0 : ffff8f8000203e30 [ 25.704912] s1 : ffffaf80018dc780 a0 : 0000000000000000 a1 : 0000000000000002 [ 25.710407] a2 : 00000000000001f0 a3 : 0000000000000018 a4 : 0000000000000000 [ 25.715917] a5 : 0000000000000000 a6 : ffffaf8001c03d98 a7 : ffffaf8001c03e30 [ 25.721419] s2 : ffff8f8000023c98 s3 : ffffaf8001aa1240 s4 : ffffffff80a04ee0 [ 25.726937] s5 : 0000000000000000 s6 : 0000000000000000 s7 : 0000000000000000 [ 25.732450] s8 : 0000000000000000 s9 : 0000000000000000 s10: 0000000000000000 [ 25.737944] s11: 0000000000000000 t3 : 0000000000000002 t4 : 0000000000000402 [ 25.743481] t5 : 0000000000000040 t6 : 0000000000000004 ssp : 0000000000000000 [ 25.749024] status: 0000000200000120 badaddr: ffffffff80a04ef8 cause: 000000000000000c [ 25.755060] [<ffffffff80a04ef8>] vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.760964] [<ffffffff80047a10>] kthread+0xd8/0xfc [ 25.764660] [<ffffffff80010c48>] ret_from_fork_kernel+0x18/0x1c4 [ 25.769220] [<ffffffff80895fe6>] ret_from_fork_kernel_asm+0x16/0x18 [ 25.774018] Code: cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc (cccc) cccc Drop __init from its signature so that this doesn't happen.
In the Linux kernel, the following vulnerability has been resolved: iommufd/viommu: Release the igroup lock on the vdevice_size error path iommufd_vdevice_alloc_ioctl() takes idev->igroup->lock, then validates the driver's vdevice_size against the core structure size with a WARN_ON_ONCE. On failure that guard jumps to out_put_idev, below out_unlock_igroup, so it skips the mutex_unlock(), leaving the igroup lock held and deadlocking the next vDEVICE operation on that group. Jump to out_unlock_igroup instead.
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1]
In the Linux kernel, the following vulnerability has been resolved: bpf: Disable xfrm_decode_session hook attachment BPF LSM programs can currently attach to xfrm_decode_session(). That hook may return an error, but security_skb_classify_flow() calls it from a void path and triggers BUG_ON() if an error is returned. Disable BPF attachment to the hook to prevent a BPF LSM program from turning packet classification into a full panic.
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: LAG, MPESW, Fix missing complete() on devcom error mlx5_mpesw_work() returned without calling complete() when mlx5_lag_get_devcom_comp() returned NULL. A caller that queued the work and waited on mpesww->comp would block indefinitely. Funnel the early-return path through a new "complete" label so the waiter is always woken.
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: sco: Fix a race condition in sco_sock_timeout() sco_sock_timeout() runs asynchronously and lock_sock(sk). If the socket is closing while the timer is running, it holds the same lock (lock_sock(sk)) twice, leading to a deadlock. CPU 0 CPU 1 ==================== ====================== sco_sock_close() sco_sock_timeout() lock_sock(sk) // <-- LOCK __sco_sock_close() sco_chan_del() sco_conn_put() sco_conn_free() disable_delayed_work_sync() lock(sk) // <-- SAME LOCK Fix this by moving disable_delayed_work_sync() outside of lock_sock(sk), ensuring that no lock_sock(sk) is held before sco_sock_timeout(). Lockdep splat: WARNING: possible circular locking dependency detected 6.13.0-rc4 #7 Not tainted syz-executor292/9514 is trying to acquire lock: ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_lock_acquire sect/v6.13-rc4/./include/linux/rcupdate.h:337 [inline] ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_read_lock sect/v6.13-rc4/./include/linux/rcupdate.h:849 [inline] ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4137 [inline] ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: __flush_work+0xd1/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195 but task is already holding lock: ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline] ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: sco_sock_close+0x25/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:524 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}: lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849 lock_sock_nested+0x48/0x130 sect/v6.13-rc4/net/core/sock.c:3622 lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline] sco_sock_timeout+0xbe/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:158 process_one_work sect/v6.13-rc4/kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa99/0x18f0 sect/v6.13-rc4/kernel/workqueue.c:3310 worker_thread+0x8a9/0xd80 sect/v6.13-rc4/kernel/workqueue.c:3391 kthread+0x2c6/0x360 sect/v6.13-rc4/kernel/kthread.c:389 ret_from_fork+0x4e/0x80 sect/v6.13-rc4/arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 sect/v6.13-rc4/arch/x86/entry/entry_64.S:244 -> #0 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}: check_prev_add sect/v6.13-rc4/kernel/locking/lockdep.c:3161 [inline] check_prevs_add sect/v6.13-rc4/kernel/locking/lockdep.c:3280 [inline] validate_chain+0x1888/0x5760 sect/v6.13-rc4/kernel/locking/lockdep.c:3904 __lock_acquire+0x13b4/0x2120 sect/v6.13-rc4/kernel/locking/lockdep.c:5226 lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849 touch_work_lockdep_map sect/v6.13-rc4/kernel/workqueue.c:3909 [inline] start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4163 [inline] __flush_work+0x70f/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195 __cancel_work_sync sect/v6.13-rc4/kernel/workqueue.c:4351 [inline] disable_delayed_work_sync+0xbb/0xf0 sect/v6.13-rc4/kernel/workqueue.c:4514 sco_conn_free sect/v6.13-rc4/net/bluetooth/sco.c:95 [inline] kref_put sect/v6.13-rc4/./include/linux/kref.h:65 [inline] sco_conn_put+0x18f/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:107 sco_chan_del+0xe2/0x210 sect/v6.13-rc4/net/bluetooth/sco.c:236 sco_sock_close+0x8f/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:526 sco_sock_release+0x62/0x2d0 sect/v6.13-rc4/net/blueto ---truncated---
In the Linux kernel, the following vulnerability has been resolved: hwmon: (occ) unregister sysfs devices outside occ lock occ_active(false) and occ_shutdown() unregister sysfs-backed devices while occ->lock is held. hwmon_device_unregister() and sysfs_remove_group() can wait for active sysfs callbacks to drain, and those callbacks can enter the OCC update path and try to take occ->lock again. That gives the unregister paths the lock ordering occ->lock -> sysfs callback drain, while a callback has the opposite edge sysfs callback -> occ->lock. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the real unregister and callback carrier: occ_shutdown() hwmon_device_unregister() occ_show_temp_1() occ_update_response() Lockdep reported the circular dependency with occ_shutdown() already holding the OCC mutex and hwmon_device_unregister() waiting on the sysfs side: WARNING: possible circular locking dependency detected ... (sysfs_lock) ... at: hwmon_device_unregister+0x12/0x30 [vuln_msv] ... (&test_occ.lock) ... at: occ_shutdown.constprop.0+0xe/0x40 [vuln_msv] occ_update_response.isra.0+0xb/0x20 [vuln_msv] occ_show_temp_1.constprop.0.isra.0+0x23/0x40 [vuln_msv] *** DEADLOCK *** Serialize hwmon registration and removal with a separate hwmon_lock. Under that lock, detach occ->hwmon and update occ->active while occ->lock is held so concurrent OCC state changes still see a stable state, then drop occ->lock before calling hwmon_device_unregister(). Remove the driver sysfs group before taking occ->lock in occ_shutdown(), so draining the driver attributes cannot wait while the OCC mutex is held. Also make OCC update callbacks return -ENODEV after deactivation, so callbacks that already passed sysfs active protection do not poll the hardware after teardown has detached the hwmon device.
In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: defer reset until cmd_mutex is unlocked vub300_cmndwork_thread() holds cmd_mutex while it sends a command and waits for the command response. If the response wait times out, __vub300_command_response() kills the command URBs and then synchronously resets the USB device through usb_reset_device(). That reset path re-enters the driver through vub300_pre_reset(), which also takes cmd_mutex. The worker therefore tries to acquire the same mutex recursively while it is still holding it from the command path. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the real worker and timeout/reset carrier: vub300_cmndwork_thread() __vub300_command_response() usb_lock_device_for_reset() usb_reset_device() vub300_pre_reset() Lockdep reported the same-task recursive acquisition on cmd_mutex: WARNING: possible recursive locking detected ... (&test_vub300.cmd_mutex) ... at: usb_reset_device... [vuln_msv] ... (&test_vub300.cmd_mutex) ... at: vub300_cmndwork_thread+0x12/0x20 [vuln_msv] Workqueue: vub300_cmd_wq vub300_cmndwork_thread [vuln_msv] *** DEADLOCK *** Return a flag from __vub300_command_response() when the timeout path needs a device reset, then perform the reset after vub300_cmndwork_thread() has cleared the in-flight command state and dropped cmd_mutex. The reset is still attempted before mmc_request_done(), preserving the existing request completion ordering while avoiding the recursive lock.
In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Treat zero-length cert chain as query for blob lengths When handling a PDH export, treat a zero-length userspace cert chain buffer as a request to query the length of the relevant blobs. Failure to account for the zero-length buffer trips a BUG_ON() when running with CONFIG_DEBUG_VIRTUAL=y due to trying to get the physical address of the ZERO_SIZE_PTR (returned by kzalloc() on the bogus allocation). kernel BUG at arch/x86/mm/physaddr.c:28 ! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 30 UID: 0 PID: 28580 Comm: syz.2.18 Kdump: loaded Tainted: G W 6.18.16-smp-DEV #1 NONE Tainted: [W]=WARN Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 RIP: 0010:__phys_addr+0x16a/0x180 arch/x86/mm/physaddr.c:28 RSP: 0018:ffffc9008329fc80 EFLAGS: 00010293 RAX: ffffffff8179110a RBX: 0000778000000010 RCX: ffff8884e6992600 RDX: 0000000000000000 RSI: 0000000080000010 RDI: 0000778000000010 RBP: ffffc9008329fdf0 R08: 0000000000000dc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff126d297 R12: dffffc0000000000 R13: 1ffff92010653fc8 R14: 0000000080000010 R15: dffffc0000000000 FS: 0000555556bec9c0(0000) GS:ffff88aa4ce1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd3159e7000 CR3: 00000004fbc44000 CR4: 0000000000350ef0 Call Trace: <TASK> [<ffffffff853d3869>] sev_ioctl_do_pdh_export+0x559/0x7a0 drivers/crypto/ccp/sev-dev.c:2308 [<ffffffff853d1fdd>] sev_ioctl+0x2cd/0x480 drivers/crypto/ccp/sev-dev.c:2556 [<ffffffff82549ebc>] vfs_ioctl fs/ioctl.c:52 [inline] [<ffffffff82549ebc>] __do_sys_ioctl fs/ioctl.c:598 [inline] [<ffffffff82549ebc>] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:584 [<ffffffff8630115f>] do_syscall_x64 arch/x86/entry/syscall_64.c:64 [inline] [<ffffffff8630115f>] do_syscall_64+0x9f/0xf40 arch/x86/entry/syscall_64.c:98 [<ffffffff81000136>] entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fd3158eac39 </TASK> Thankfully, the bug is benign outside of CONFIG_DEBUG_VIRTUAL=y as getting the physical address is just arithmetic, and the PSP errors out before trying to write to the garbage address (which it must, otherwise querying the blob lengths would clobber memory at pfn=0).
In the Linux kernel, the following vulnerability has been resolved: media: atomisp: gc2235: fix UAF and memory leak gc2235_probe() handles its error paths incorrectly. If media_entity_pads_init() fails, gc2235_remove() is called, which tears down the subdev and frees dev, but then still falls through to atomisp_register_i2c_module(). This results in use-after-free. If atomisp_register_i2c_module() fails, the media entity and control handler are left initialized and dev is leaked. gc2235_remove() unconditionally calls media_entity_cleanup() and v4l2_ctrl_handler_free(), but these are not initialized at every error path in gc2235_probe(). Replace gc2235_remove() calls in the probe error paths with explicit unwind labels that free only the resources initialized at each point of failure, in reverse order of initialization.
In the Linux kernel, the following vulnerability has been resolved: pinctrl: spacemit: fix NULL check in spacemit_pin_set_config spacemit_pin_set_config() looks up the per-pin descriptor with spacemit_get_pin() then checks the wrong variable for failure: const struct spacemit_pin *spin = spacemit_get_pin(pctrl, pin); ... if (!pin) return -EINVAL; reg = spacemit_pin_to_reg(pctrl, spin->pin); pin is an unsigned int pin id, where 0 (GPIO_0 / gmac0_rxdv on K3) is a valid pin, so rejecting it here drops the PAD config write for the first pin of every group. On K3 Pico-ITX the GMAC RGMII group lists pin 0 as its first entry, so its drive-strength / bias configuration was silently ignored. The intended guard is against spacemit_get_pin() returning NULL when the pin id isn't in the SoC's pin table. Check spin instead, which both restores PAD setup for pin 0 and prevents a NULL deref on spin->pin.
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix warning in poll cq direct mode CQs allocated by ib_alloc_cq() always have a comp_handler. Though in direct mode this handler is never expected to be called, it is still called when the driver is reset, triggering the following WARN_ONCE(): Call trace: ib_cq_completion_direct+0x38/0x60 hns_roce_cq_completion+0x54/0x90 (hns_roce_hw_v2] hns_roce_handle_device_err+Ox1c8/0x340 [hns_roce_hw_v2] hns_roce_hw_v2_uninit_instance.constprop.0+0x34/0x70 [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify+0xc4/0xe0 [hns_roce_hw_v2] hclge_notify_roce_client+0x60/0xbc [hclge] hclge_reset_rebuild+0x48/0x34c [hclge] hclge_reset_subtask+0xcc/0xec [hclge] hclge_reset_service_task+0x80/0x160 [hclge] hclge_service_task+0x50/0x80 (hclge] process_one_work+0x1cc/0x4d0 worker_thread+0x154/0x414 kthread+0x104/0x144 ret_from_fork+0x10/0x18
In the Linux kernel, the following vulnerability has been resolved: EDAC/igen6: Fix call trace due to missing release() When unloading the igen6_edac driver, there is a call trace: Device '(null)' does not have a release() function, it is broken and must be fixed. See Documentation/core-api/kobject.rst. WARNING: drivers/base/core.c:2567 at device_release+0x84/0x90, CPU#5: rmmod/127209 ... RIP: 0010:device_release+0x84/0x90 Call Trace: <TASK> kobject_put+0x8c/0x220 put_device+0x17/0x30 igen6_unregister_mcis+0xa2/0xe0 [igen6_edac] igen6_remove+0x82/0xb0 [igen6_edac] ... Fix the call trace by providing empty release() functions for the memory controller devices.
In the Linux kernel, the following vulnerability has been resolved: liveupdate: Reference count incoming FLB data Increment the incoming FLB refcount in liveupdate_flb_get_incoming() so that the FLB structure cannot be freed while the caller is actively using it. Add an additional liveupdate_flb_put_incoming() function so the caller can explicitly indicate when it is done using the FLB data. During a Live Update, a subsystem might need to hold onto the incoming File-Lifecycle-Bound (FLB) data for an extended period, such as during device enumeration. Incrementing the reference count guarantees that the data remains valid and accessible until the subsystem releases it, preventing future use-after-free bugs.
In the Linux kernel, the following vulnerability has been resolved: wifi: wlcore: enable the right set of ciphers The firmware version number check for IGTK introduced in commit c34dbc5900b0 ("wifi: wlcore: Add support for IGTK key") lets the amount of ciphers decrease on every boot of a too old firmware and that is practically happening. It also does not take into account other chips than the wl18xx. On some wl128x, the following can be observed when connecting via nm to a common ap: [ 484.113311] wlcore: WARNING could not set keys [ 484.117828] wlcore: ERROR Could not add or replace key [ 484.123016] wlan0: failed to set key (5, ff:ff:ff:ff:ff:ff) to hardware (-5) [ 484.123046] wlcore: Hardware recovery in progress. FW ver: Rev 7.3.10.0.142 [ 484.139923] wlcore: pc: 0x0, hint_sts: 0x00000048 count: 1 [ 484.145721] wlcore: down [ 484.148986] ieee80211 phy0: Hardware restart was requested [ 484.610473] wlcore: firmware booted (Rev 7.3.10.0.142) [ 484.633758] wlcore: Association completed. [ 484.690490] wlcore: ERROR command execute failure 14 [ 484.690490] ------------[ cut here ]------------ [ 484.700195] WARNING: drivers/net/wireless/ti/wlcore/main.c:872 at wl12xx_queue_recovery_work+0x64/0x74 [wlcore], CPU#0: kworker/0:0/892 This repeats endlessly. Always disable IGTK on wl12xx and fix the decrementing mess.
In the Linux kernel, the following vulnerability has been resolved: powerpc/perf: fix preempt count underflow in fsl_emb_pmu_del fsl_emb_pmu_del() unconditionally calls put_cpu_var(cpu_hw_events) at the 'out:' label, but only calls the matching get_cpu_var() after the 'i < 0' early-return check. When event->hw.idx is negative the function jumps to 'out:' without having taken get_cpu_var(), and the trailing put_cpu_var() then issues an unmatched preempt_enable(), underflowing preempt_count. On a CONFIG_PREEMPT=y kernel preempt_count would underflow and eventually present as a 'scheduling while atomic' BUG. Move put_cpu_var() to pair with get_cpu_var() so the percpu access is correctly bracketed and the 'out:' label only handles perf_pmu_enable.
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix memory leak of bonding resources In a corner case of concurrent driver removal and driver reset, bonding resource is first released in hns_roce_hw_v2_exit() during driver removal, and then is allocated again in hns_roce_register_device() during driver reset. This leads to memory leak because the release timing has already passed. This may also lead to a kernel panic as below because of the leaked notifier callback: Call trace: 0xffffa20fccc04978 (P) raw_notifier_call_chain+0x20/0x38 call_netdevice_notifiers_info+0x60/0xb8 netdev_lower_state_changed+0x4c/0xb8 As Sashiko suggested, the teardown order of bonding resources should be inverted to make sure the resources are released when the driver is removed.
In the Linux kernel, the following vulnerability has been resolved: mfd: cs42l43: Sanity check firmware size Currently the code checks if a firmware was received, however it does not verify that the firmware size is larger than the firmware header. As the firmware pointer is dereferenced as a pointer to the header structure this could lead to an out of bounds memory access. Add the missing check.
In the Linux kernel, the following vulnerability has been resolved: coresight: ete: Always save state on power down System register ETMs and ETE are unlikely to be preserved on CPU power down. The ETE DT binding also never documented "arm,coresight-loses-context-with-cpu" so nobody would have legitimately been able to use that binding to fix it and ACPI has no such binding at all. Fix it by hard coding the setting for sysreg ETMs (ETE is always sysreg) or ACPI boots. Use a local variable when setting up save_state so that it's immune to concurrent probing when devices have different configurations which is an issue with modifying the global. This fixes the following error when using Coresight with ACPI on the FVP which supports CPU PM: coresight ete0: External agent took claim tag WARNING: drivers/hwtracing/coresight/coresight-core.c:248 at coresight_disclaim_device_unlocked+0xe0/0xe8, CPU#0: perf/117
In the Linux kernel, the following vulnerability has been resolved: PCI: dwc: Avoid dwc_pcie_rasdes_debugfs_deinit() NULL dereference when no RAS DES capability dwc_pcie_rasdes_debugfs_init() returns success when the controller has no RAS DES capability, leaving pci->debugfs->rasdes_info unset. The common debugfs teardown path still calls dwc_pcie_rasdes_debugfs_deinit(), which dereferences rasdes_info unconditionally. Return early when no RAS DES state was allocated. In that case no RAS DES mutex was initialized, so there is nothing to destroy. [mani: reworded subject]
In the Linux kernel, the following vulnerability has been resolved: Revert "PCI/MSI: Unmap MSI-X region on error" This reverts commit 1a8d4c6ecb4c81261bcdf13556abd4a958eca202. Commit 1a8d4c6ecb4c ("PCI/MSI: Unmap MSI-X region on error") added an iounmap(dev->msix_base) on the error path of msix_capability_init() to release the MSI-X region when msix_setup_interrupts() fails. When msix_setup_interrupts() fails, the call chain is: msix_setup_interrupts() -> __msix_setup_interrupts() struct pci_dev *dev __free(free_msi_irqs) = __dev; ... return ret; // __free cleanup fires on error The __free(free_msi_irqs) cleanup calls pci_free_msi_irqs(), which already handles the unmap: void pci_free_msi_irqs(struct pci_dev *dev) { pci_msi_teardown_msi_irqs(dev); if (dev->msix_base) { iounmap(dev->msix_base); // already unmapped here dev->msix_base = NULL; // and set to NULL } } So dev->msix_base is unmapped and set to NULL before msix_setup_interrupts() returns to msix_capability_init(). The "goto out_unmap" introduced by commit 1a8d4c6ecb4c ("PCI/MSI: Unmap MSI-X region on error") then calls iounmap() a second time on a NULL pointer. This was reproduced on Intel Emerald Rapids (192 CPUs) while running tools/testing/selftests/kexec/test_kexec_jump.sh: WARNING: CPU#44 at iounmap+0x2a/0xe0 RIP: 0010:iounmap+0x2a/0xe0 RDI: 0000000000000000 Call Trace: msix_capability_init+0x317/0x3f0 __pci_enable_msix_range+0x21d/0x2c0 pci_alloc_irq_vectors_affinity+0xa9/0x130 nvme_setup_io_queues+0x2a8/0x420 [nvme] nvme_reset_work+0x151/0x340 [nvme] ... RDI=0 confirms iounmap() is called with NULL. Restore the original "goto out_disable" and leave the unmap to the existing __free(free_msi_irqs) cleanup.
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Avoid double-unpin of DOORBELL/MMIO BOs on free amdgpu_amdkfd_gpuvm_free_memory_of_gpu() unpinned DOORBELL and MMIO remap BOs (which are pinned at allocation time) before checking whether the BO is still mapped to the GPU. When the BO is still mapped, the function returns -EBUSY and leaves the BO alive, but it has already been unpinned. The BO is then unpinned again when it is finally freed during process teardown, triggering a ttm_bo_unpin() underflow warning: WARNING: CPU: 18 PID: 15066 at ttm/ttm_bo.c:650 amdttm_bo_unpin+0x6d/0x80 [amdttm] Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu] RIP: 0010:amdttm_bo_unpin+0x6d/0x80 [amdttm] Call Trace: amdgpu_bo_unpin+0x1a/0x90 [amdgpu] amdgpu_amdkfd_gpuvm_unpin_bo+0x31/0xb0 [amdgpu] amdgpu_amdkfd_gpuvm_free_memory_of_gpu+0x3bf/0x460 [amdgpu] kfd_process_free_outstanding_kfd_bos+0xd4/0x170 [amdgpu] kfd_process_wq_release+0x109/0x1b0 [amdgpu] process_one_work+0x1e2/0x3b0 worker_thread+0x50/0x3a0 kthread+0xdd/0x100 ret_from_fork+0x29/0x50 Move the unpin after the mapped_to_gpu_memory check so it only happens once we are committed to freeing the BO. (cherry picked from commit 927c5b2defb9b09856444d94bebfd056a002bd75)
In the Linux kernel, the following vulnerability has been resolved: ACPI: processor_idle: Mark LPI enter functions as __cpuidle When function tracing or Kprobes is enabled, entering an ACPI Low Power Idle (LPI) state triggers the following RCU splat: RCU not on for: acpi_idle_lpi_enter+0x4/0xd8 WARNING: CPU: 8 PID: 0 at include/linux/trace_recursion.h:162 function_trace_call+0x1e8/0x228 The acpi_idle_lpi_enter() function is invoked within the cpuidle path after RCU has already been disabled for the current local CPU. Consequently, ftrace's function_trace_call() expects RCU to be actively watching before recording trace data, emitting a warning if it is not. Fix this by annotating acpi_idle_lpi_enter(), the generic __weak stub, and the RISC-V implementation of acpi_processor_ffh_lpi_enter() with __cpuidle. This moves these functions into the '.cpuidle.text' section, implicitly disabling ftrace instrumentation (notrace) along this sensitive path and preventing trace-induced RCU warnings during idle entry.
In the Linux kernel, the following vulnerability has been resolved: tracing/probes: Remove WARN_ON_ONCE from parse_btf_arg Sashiko found that user can cause this WARN_ON_ONCE() easily with adding a kprobe event based on a raw address with BTF parameter. Since this is not an unexpected condition, remove the WARN_ON_ONCE().
In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd/lbr: Fix kernel address leakage A user-only branch stack can contain branches that originate from the kernel. As a result, kernel addresses are exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. On AMD processors supporting X86_FEATURE_AMD_LBR_V2, perf can still report SYSRET/ERET entries for which the branch-from addresses are in the kernel. E.g. $ perf record -e cycles -o - -j any,save_type,u -- \ perf bench syscall basic --loop 1000 | \ perf script -i - -F brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' ... 0xffffffff81001268/0x717a90a38f1a/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a39157/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a2c628/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a41b60/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a260db/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a260db/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a8bef1c30/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a8e4d3c90/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH ... The reason is that the hardware filter only considers the privilege level applicable to the branch target. Extend software filtering to also validate the branch-from addresses against br_sel, so that any branch record whose branch-from address is in the kernel is dropped when PERF_SAMPLE_BRANCH_USER is requested.
In the Linux kernel, the following vulnerability has been resolved: samples/damon/mtier: fail early if address range parameters are invalid The comment on top of `struct damon_region` clearly says that For any use case, @ar should be non-zero positive size. which is now verified in damon_verify_new_region() if the kernel is built with DAMON_DEBUG_SANITY. The WARN_ONCE() can be triggered if the mtier sample module is enabled before node{0,1}_{start,end}_addr have been properly initialized, which is obviously not good. ------------[ cut here ]------------ start 0 >= end 0 WARNING: mm/damon/core.c:217 at damon_new_region+0xf4/0x118, CPU#59: bash/341468 Call trace: damon_new_region+0xf4/0x118 (P) damon_set_regions+0xfc/0x3c0 damon_sample_mtier_build_ctx+0xe8/0x3a8 damon_sample_mtier_start+0x1c/0x90 damon_sample_mtier_enable_store+0x98/0xb0 param_attr_store+0xb4/0x128 module_attr_store+0x2c/0x50 sysfs_kf_write+0x58/0x90 kernfs_fop_write_iter+0x16c/0x238 vfs_write+0x2c0/0x370 ksys_write+0x74/0x118 __arm64_sys_write+0x24/0x38 invoke_syscall+0xa8/0x118 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x54/0x370 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0 ---[ end trace 0000000000000000 ]--- Note that the same issue can happen if detect_node_addresses is true, and node 0 or 1 is memoryless. Fix it together by checking the validity of parameters right before damon_new_region() and fail early if they're invalid.
Unauthenticated mass PII enumeration in the User Frontend WordPress plugin (versions 4.3.0 through 4.3.10) exposes the email address and phone number of every registered user - including site administrators - via an unrestricted user directory search endpoint. The flaw requires no authentication, no special configuration, and is automatable per SSVC, making bulk harvesting trivial for any remote attacker. A publicly available proof-of-concept exploit exists, reported by WPScan, though active exploitation has not been confirmed by CISA KEV at time of analysis.
Memory exhaustion vulnerabilities in openNDS before 11.0.0 allow an unauthenticated attacker on the captive portal network to crash the portal daemon within minutes by triggering unfreed heap allocations in the authentication handler. The root cause is CWE-401 (missing memory release) in src/auth.c, where intermediate buffers allocated during gateway interface lookups in client_auth() are never freed on certain code paths. No confirmed active exploitation exists and no CISA KEV listing is present, but the attack surface is inherently broad in public hotspot deployments where any connected device can trigger the vulnerable authentication flow.
Guest Wi-Fi configuration exposure in TOTOLINK T6 firmware 4.1.5cu.748_B20211015 allows any adjacent-network attacker without credentials to retrieve the router's guest wireless settings by sending a crafted POST to /cgi-bin/cstecgi.cgi invoking the getWiFiGuestCfg function. The CGI dispatcher performs no session or privilege check before returning guest SSID and passphrase data, a pattern consistent with multiple other access-control deficiencies in the same firmware. No public exploit code or active exploitation has been identified; EPSS stands at 0.18% (7th percentile) and SSVC rates technical impact as partial.
Unauthenticated information disclosure in TOTOLINK T6 firmware 4.1.5cu.748_B20211015 exposes mesh neighbor table data to any attacker on the adjacent network. The getMeshNeighborTable function in the /cgi-bin/cstecgi.cgi CGI interface fails to enforce access control, allowing a crafted POST request to retrieve mesh network topology without credentials. No public exploit or active exploitation is confirmed; EPSS at 0.18% and SSVC exploitation status of 'none' indicate minimal real-world threat at present.
Cleartext cluster key disclosure in Wazuh 4.14.0-4.14.6 allows any low-privilege API user with the default readonly or cluster_readonly role to retrieve the shared secret that authenticates and encrypts all inter-node cluster traffic. The GET /cluster/local/config endpoint was missing the mask_sensitive_config decorator applied to every sibling config endpoint, causing the cluster.key field to be returned unredacted to accounts that are explicitly denied update-config permission. The severity of this information disclosure is amplified by prior Wazuh advisories that establish cluster-peer remote code execution chains contingent on possessing the cluster key, making this a practical stepping stone to full cluster compromise. No public exploit has been identified at time of analysis and the vulnerability is not in the CISA KEV catalog.
WatchGuard Dimension's web login endpoint permits unlimited automated password guessing against user accounts because rate-limiting and account lockout are both absent in the default product configuration. All versions of Dimension (CPE wildcard, no version boundary) are affected in default-configured deployments. An unauthenticated remote attacker can systematically guess credentials and gain unauthorized account access; the CWE-203 classification further indicates the endpoint may expose observable discrepancies that enable username enumeration, reducing the effort required for targeted credential attacks. No public exploit has been identified at time of analysis and no CISA KEV listing exists.
Plaintext administrative credential exposure in the Ebyte NE2-D11 firmware management interface allows anyone with physical access to directly observe device credentials without any authentication or tooling. Reported by ICS-CERT under advisory ICSA-26-237-06, the flaw (CWE-522) affects all known firmware versions per CPE data, with a physical attack vector (AV:P) confirming that exploitation requires proximity to the device. Credential capture could enable full administrative control over the device, with downstream risk to industrial operations where the NE2-D11 is deployed. No public exploit has been identified and the vulnerability is not listed in CISA KEV.
Cleartext transmission of OAuth credentials in RooCodeInc Roo-Code up to version 3.51.1 exposes sensitive OAuth tokens to interception via the OAuth callback handler in src/integrations/claude-code/oauth.ts. The vendor has officially archived the repository and explicitly discourages continued use, meaning no patch will be issued. A public proof-of-concept is available on GitHub, though high attack complexity (requiring a network interception position) constrains opportunistic exploitation.
Out-of-bounds read in Adobe DNG SDK 1.7.1 2502 and earlier exposes sensitive memory contents when a victim opens a maliciously crafted DNG file. The flaw resides in the SDK's file parser and affects any application built on top of the DNG SDK that processes untrusted DNG inputs. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV, limiting current urgency despite the High confidentiality impact.
Sensitive KMS provider credentials supplied for client-side field-level encryption (CSFLE) in the MongoDB C# Driver are reproduced in plaintext within the driver's diagnostic string representation of its client settings, rather than being masked like other secret fields. Any party with read access to application logs, diagnostic output, or process memory dumps can recover these credentials and independently invoke the key management service to unwrap data-encryption keys, compromising all data protected by those keys. No public exploit code or active exploitation in CISA KEV has been identified at time of analysis; exploitation is bounded by the requirement that CSFLE be configured and that the attacker have access to diagnostic output.
NoSQL injection in the MongoDB C# Driver's document-replacement code path allows network-accessible, low-privileged attackers to inject MongoDB query-language operators into database operations. The driver omits the element-name and shape validation applied by other write paths, so untrusted loosely-typed input (BsonDocument, Dictionary, dynamic) is forwarded to the MongoDB server unfiltered, enabling attacker-controlled data to be interpreted as update logic under the application's own database credentials. No public exploit or CISA KEV listing has been identified at time of analysis; exploitation is bounded to applications that use loosely-typed replacement patterns rather than strongly-typed C# document mappings.
Namespace injection in MongoDB C Driver (libmongoc) allows any caller-controlled database or collection name containing a '.' separator or NUL byte to redirect a MongoDB operation to an unintended resource. Applications that incorporate unsanitized user input into these name components are affected across all libmongoc versions prior to 2.5.1. No public exploit has been identified at time of analysis; the vendor released a validated fix in version 2.5.1.
Input injection in MongoDB libmongocrypt's automatic-encryption context setup permits caller-supplied database and collection name arguments containing '.' or NUL bytes to pass without sanitization, causing incorrect schema selection during Client-Side Field Level Encryption (CSFLE) operations. Affected callers - those with local access and low privileges - may obtain limited unauthorized disclosure or modification of data processed under the wrong encryption schema. No public exploit code exists and this vulnerability is not in CISA KEV; the CVSS 4.0 score of 2.0 reflects the constrained real-world impact.
Unsafe header deserialization in Spring Integration's EmbeddedHeadersJsonMessageMapper exposes applications to header injection across all active release trains (5.5.x through 7.1.0). The decodeNativeFormat method constructs GenericMessage objects with MutableMessageHeaders populated directly from attacker-controlled JSON-deserialized header maps, bypassing sanitization by default in the constructor. Low-privileged network attackers who can submit crafted byte payloads to an affected consumer channel can manipulate message headers, yielding partial confidentiality, integrity, and availability impacts. No public exploit has been identified at time of analysis and this CVE is not listed in CISA KEV.
Concurrent message processing in Spring Integration's script-backed channels causes shared ScriptEngine state corruption when using JSR-223 engines that declare THREADING=null, such as the Kotlin KTS engine. Affected Spring Integration versions from 5.5.21 and earlier through 7.1.0 are susceptible to cross-message data leakage, where one message's payload or header bindings can bleed into another message's script evaluation context under concurrent load. No public exploit has been identified at time of analysis, and the CVSS 4.2 Medium rating reflects the high attack complexity imposed by the required race condition, though the information disclosure and partial integrity impact are real concerns in multi-tenant or high-throughput deployments.
Link credit exhaustion in Spring AMQP 4.1.0 silently stalls AMQP listener containers when a container-level ErrorHandler is active. Each message delivery whose processing throws an exception permanently consumes one link credit without returning it to the broker; once the pool reaches zero (after the default 100 credits), the broker halts delivery while isRunning() continues to report true, masking the outage from standard health checks. No active exploitation has been confirmed (no CISA KEV listing, no public POC), but this is a realistic denial-of-service condition for any Spring-based messaging consumer running the affected version with an ErrorHandler configured.
Denial-of-service in Spring for Apache Kafka's `DeadLetterPublishingRecovererFactory` exposes consumer JVMs across all supported branches (2.8.x through 4.1.0) to crash or hang when processing messages with a crafted `retry_topic-original-timestamp` header. An authenticated Kafka producer can inject a ConsumerRecord carrying an oversized or malformed header byte array, which is passed without any length or format validation directly to Java's `BigInteger(byte[])` constructor, triggering heap memory exhaustion or an unhandled exception that disrupts message consumption. No public exploit code has been identified and the CVE does not appear in CISA KEV at time of analysis, but low attack complexity combined with broad version coverage makes this a credible availability threat for any Spring Kafka deployment using retry or dead-letter queue features.
Symlink redirection in Spring Integration's Zip/UnZip transformer allows a local unprivileged user sharing the same host to hijack transformer output by pre-creating /tmp/ziptransformer as a symlink before application startup. Affected versions span the 6.4, 6.5, 7.0, and 7.1 release lines, covering a wide range of enterprise Java deployments that use Spring Integration's file transformation capabilities. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in CISA KEV, though the integrity and availability impact is rated High by the vendor-assigned CVSS score.
Spring Cloud Stream's partition interceptor logic improperly inserts a partition interceptor during message sends under specific conditions, potentially routing messages to unintended partitions. Affected versions span three active release lines: 5.0.0-5.0.2, 4.3.0-4.3.3, and 4.2.0-4.2.6. An authenticated operator with high privileges who triggers a message send under the required conditions could cause limited information disclosure or message integrity degradation by routing data to an unintended partition consumer. No public exploit identified at time of analysis; CVSS score of 3.1 reflects the high access bar and narrow impact.
Improper content-type caching in the Avro component of Spring Cloud Stream can produce incorrect content-type metadata on processed messages, creating a low-severity information-disclosure and data-integrity risk. Affected versions span the 4.2.x, 4.3.x, and 5.0.x release trains. Exploitation requires network access, high privilege level, high attack complexity, and user interaction, making real-world impact minimal; no public exploit code or active exploitation has been identified at time of analysis.
Sensitive data exposure in Spring Cloud Stream versions 4.2.0-4.2.6, 4.3.0-4.3.3, and 5.0.0-5.0.2 allows logging of sensitive information - such as message payloads, headers, or configuration values - under specific conditions. The vulnerability is classified as information disclosure with a low CVSS base score of 3.1, reflecting the high attack complexity and privilege requirements. No public exploit code has been identified and this vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog.
Spring Cloud Function's Azure integration may inadvertently log sensitive data across three affected release lines (4.2.0-4.2.7, 4.3.0-4.3.4, 5.0.0-5.0.3), resulting in low-impact information disclosure. The vulnerability is constrained by a high-privilege, high-complexity, user-interaction-required exploitation profile (CVSS 3.1), making it a low-priority issue for most organizations. No public exploit code exists and the vulnerability has not been added to the CISA KEV catalog; the primary risk is credential or token leakage through application log aggregators accessible to operators or compromised log pipelines.
Spring Cloud Function's AWS adapter component may inadvertently write sensitive data to application logs, creating an information disclosure exposure across a wide range of maintained version branches (3.x through 5.x). The CVSS score of 3.1 reflects genuinely low severity - exploitation requires high privileges and high attack complexity - but the risk in regulated or multi-tenant environments is elevated if log stores are accessible to unauthorized parties or if sensitive data (credentials, payloads, tokens) persists in cloud-native logging services such as AWS CloudWatch. No public exploit code exists and no active exploitation has been identified at time of analysis.
Spring Cloud Function's composition lookup mechanism can be abused by a highly privileged attacker to poison the base function, potentially degrading the integrity and confidentiality of function execution across versions 3.2.16 and earlier through 5.0.3. The vendor-assigned CVSS base score of 3.1 reflects severely constrained exploitation prerequisites - high privilege level, high attack complexity, and required user interaction - substantially limiting realistic exposure. No public exploit code has been identified, and the vulnerability does not appear in the CISA KEV catalog at time of analysis.
HTTP header filtering deficiency in Spring Cloud Function versions 5.0.0-5.0.3, 4.3.0-4.3.4, 4.2.0-4.2.7, and 3.2.16 and earlier allows network-accessible authenticated attackers - under high-complexity conditions and requiring user interaction - to achieve limited confidentiality and integrity impacts via crafted HTTP headers. Reported by VMware, the flaw scores 3.1 (Low) under CVSS 3.1, with multiple compounding prerequisites that substantially restrict real-world exploitability. No public exploit code and no CISA KEV listing have been identified at time of analysis.
Spring Cloud Function's ServerlessHttpServletRequest.isSecure() method returns an unchecked result that does not reflect the actual HTTP transport scheme, enabling applications that gate security decisions on this call to behave incorrectly. Affected versions span three active release lines: 5.0.0-5.0.3, 4.3.0-4.3.4, and 4.2.0-4.2.7. No public exploit code exists and the vulnerability is not listed in CISA KEV; the vendor-assigned CVSS of 3.1 (Low) reflects constrained exploitation prerequisites including high privilege and user interaction.
Spring Integration's jCIFS-based SMB client silently negotiates down to legacy SMB1/CIFS when applications omit an explicit `smbMinVersion` setting, exposing file transfer sessions to NTLM relay attacks and in-transit content tampering by a network-positioned adversary. Affected versions span Spring Integration 6.4.0-6.4.12, 6.5.0-6.5.10, 7.0.0-7.0.5, and the standalone release 7.1.0 - covering all currently active Spring Integration release trains at time of disclosure. No CISA KEV listing or public exploit code specific to this CVE has been identified at time of analysis, though NTLM relay is a mature, extensively tooled attack class; EPSS data was not available in the sourced intelligence.
Spring Integration's default file-based metadata store writes persistent state to a world-readable file under java.io.tmpdir, exposing integration metadata to any local OS user on the affected host. All actively maintained branches are affected, spanning versions 5.5.21 and earlier through 7.1.0. No public exploit code or active exploitation has been identified at time of analysis; practical impact is limited to local confidentiality disclosure on shared or multi-user systems.
Spring Security 7.1.0's InetAddressMatchers utility contains a flaw in its IP address classification logic - the matchInternal() and matchExternal() builders may incorrectly categorize certain IP addresses as belonging to internal or external networks, enabling unauthenticated remote attackers to bypass IP-based access controls under high-complexity conditions. Applications that rely on InetAddressMatchers to enforce network-level access restrictions are exposed to limited information disclosure where restricted endpoints or data may become accessible to external parties. No public exploit code exists and no CISA KEV listing is present, indicating no confirmed active exploitation at time of analysis.
Timing side-channel exposure in Spring Security allows remote unauthenticated attackers to progressively infer security-sensitive string values - such as CSRF tokens, bearer tokens, or other secrets compared at the application layer - by statistically measuring the time differential between rejection responses. Multiple active Spring Security release trains are affected, spanning versions 5.7.x through 7.1.x, representing a broad swath of production Spring-based Java applications. No public exploit code has been identified at time of analysis, and CISA KEV status is absent; however, the confidentiality impact is rated High in the CVSS vector, reflecting that successful exploitation could fully compromise protected secrets under favorable network conditions.
Job deduplication in the cakephp/queue plugin can be bypassed by attackers who control job parameter data, causing legitimate unique jobs to be silently dropped. The flaw affects all applications using `shouldBeUnique = true` on job classes where user-supplied input is passed as job parameters - versions 0.1.10 through 2.3.0. No public exploit identified at time of analysis, and the CVSS score of 3.7 (AV:N/AC:H) reflects that exploitation requires knowledge of the target application's job parameter schema.
TLS certificate validation is absent by default in Spring AMQP's Log4j2 appender when shipping log events to a RabbitMQ broker, leaving all log traffic fully exposed to man-in-the-middle interception. Spring AMQP versions 2.4.18 and earlier, 3.2.0-3.2.12, 4.0.0-4.0.4, and 4.1.0 are affected when the Log4j2 appender is used with its documented default configuration. No public exploit has been identified at time of analysis, but the high confidentiality and integrity CVSS impact reflects that intercepted log streams may contain API keys, session tokens, and other sensitive application data.
TLS bypass in Grafana's ClickHouse Datasource plugin (versions 3.1.0 through 4.20.0) silently transmits database traffic in cleartext when the Native protocol is routed through a PDC or secure SOCKS proxy, despite TLS being configured. The underlying connection library ignores the TLS request without raising an error, exposing ClickHouse usernames, passwords, SQL queries, and query results to any attacker positioned on the network hop between the proxy and the database server. No public exploit has been identified at time of analysis and the vulnerability is not listed in the CISA KEV catalog.
MongoDB BI Connector's mongodrdl tool leaks TLS private-key passwords to standard error when the password is simultaneously supplied via both the connection URI and a corresponding command-line option. Affected versions span BI Connector 2.12.0 through 2.14.29; the fix is version 2.14.30. A local attacker who can read captured stderr output and also possesses the encrypted TLS client key file can combine those two artifacts to authenticate as the legitimate TLS client identity. No public exploit code or active exploitation has been identified at time of analysis.
Out-of-bounds heap read in the DHCPv4 packet capture code of wicked (all versions through 0.6.80) allows an unauthenticated attacker on the same Layer-2 network segment to send a crafted DHCP/UDP packet that causes wickedd-dhcp4 to read up to 68 bytes past the end of its 1500-byte receive buffer. Adjacent heap contents - including allocator metadata and pointer values - may be parsed as DHCP options and stored into lease fields, constituting limited information disclosure with a secondary low-integrity configuration impact. No public exploit code and no CISA KEV listing have been identified at time of analysis; an upstream fix exists in GitHub PR #1079, though a tagged release version has not been independently confirmed.
Integer underflow in the wicked DHCPv4 packet capture daemon (wickedd-dhcp4) on SUSE Linux systems allows an unauthenticated adjacent-network attacker to crash the daemon by sending a malformed DHCPv4 packet with an IP total length field smaller than the IP header length. The missing bounds check in ni_capture_inspect_udp_header() triggers an out-of-bounds read, causing a process crash depending on memory layout - resulting in a denial of service to network configuration. No information disclosure has been demonstrated, and no public exploit or CISA KEV listing exists at time of analysis.
Local information disclosure in the openssl-encrypt pip package (versions ≤ 1.4.8) exposes steganography passwords to all unprivileged users on the same Linux host. When the desktop GUI initiates an encrypt or decrypt operation involving the steganography feature, it spawns a CLI child process with the password supplied as the `--stego-password` command-line argument rather than via an environment variable, making it readable from `/proc/<pid>/cmdline` for the entire subprocess lifetime by any local user. The main encryption password is handled correctly via environment variable and is unaffected. A vendor-released patch is available in version 1.4.9; no public exploit has been identified at time of analysis.
Out-of-bounds read and write primitives in the hank-ai Darknet neural network framework (all versions through 6.0) are triggered by parsing a crafted configuration file, yielding a reliable crash and a single fixed-byte heap write at an attacker-controlled offset. The parser in src-lib/darknet_cfg.cpp consumes the `from` field of shortcut, scale_channels, and sam sections-and the `layers` field of route sections-as a direct array index into the layer heap allocation without validating it against the array's declared size. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV.
DNS rebinding in Dropbox's mcp-server-dash (network mode) allows a malicious web page to reach the local MCP listener and invoke Dropbox API tools - company-search and file-detail - under the victim's stored Dropbox credential. The server bound to the loopback interface but performed no Host header validation, letting a browser issue cross-origin requests via a rebound domain that resolves to 127.0.0.1. No public exploit has been identified at time of analysis; CVSS 4.0 scores this at 2.3, reflecting the attack's prerequisites of user interaction and a specific deployment mode.
Token exfiltration in airtable-mcp-cli before 0.2.5 allows an attacker who convinces a user to run the configure command with a malicious endpoint URL to receive the user's Airtable personal access token on every subsequent CLI invocation. The root cause is that ConfigureCommand.execute in src/cli.ts persisted the --endpoint option directly into the user profile, bypassing the createSafeUrl helper in src/config.ts that already enforced HTTPS and vendor-host restrictions for the environment-variable pathway. Because src/mcp.ts attaches the stored token as a bearer credential on every outbound request, the stolen token grants full API-level access to the victim's Airtable account. No public exploit or CISA KEV listing has been identified at time of analysis.
Account footprinting via observable discrepancy in Seres Software syWEB exposes valid user account existence to unauthenticated remote attackers. All versions through 27082026 are affected, and the vendor has confirmed the product is end-of-life with no support - meaning no patch will ever be released. No public exploit code or CISA KEV listing has been identified, but the permanently unpatched status elevates long-term risk for any remaining deployments.
Symlink following in Dool (versions up to and including 1.3.8) allows a local attacker to cause arbitrary file truncation and overwriting when the tool is run with the non-default '--devel' flag. The vulnerable code path opens a log file without the O_NOFOLLOW flag (CWE-59), allowing a pre-placed symlink to redirect the write to any file the dool process can access - an impact that escalates from trivial to severe if dool runs under elevated privileges such as root. No public exploit code or CISA KEV active exploitation is identified; the issue was reported by CERT-PL and addressed upstream via pull request #116.
Session invalidation failure in HCL IntelliOps Event Management (IEM) v1.3 and v1.4 allows session tokens to persist as valid after an admin explicitly logs out or an administrator deletes the session. An attacker who has previously captured a valid session token - through network interception, XSS, or other means - can replay that token post-logout to retain unauthorized access to admin-level functionality. No public exploit code has been identified at time of analysis, and EPSS/KEV data are not available for this CVE.
Session tokens in HCL IntelliOps Event Management (IEM) versions 1.3 and 1.4 persist as valid on the server after a user logs out or an account is deleted, allowing an attacker who has previously captured a legitimate session token to replay it and maintain unauthorized access beyond the intended session lifecycle. The root cause is CWE-613 (Insufficient Session Expiration), where server-side session records are not destroyed upon logout or account removal. No public exploit code or active exploitation has been identified at time of analysis, and the CVSS 6.4 Medium score reflects meaningful constraints on exploitation including high attack complexity and required user interaction.
Finale Lite WordPress plugin before 2.21.0 exposes sales campaign configuration and scheduling data to any subscriber-level authenticated user due to a missing capability check on a WordPress AJAX action. The unprotected endpoint accepts an arbitrary post ID and returns the associated campaign's settings without verifying that the requesting user holds appropriate privileges. No public exploit code has been identified and CISA has not listed this in the KEV catalog, though the low authentication barrier makes opportunistic reconnaissance straightforward.
LearnPress WordPress plugin versions up to and including 4.0.2 expose order payment status data through an unauthenticated REST endpoint that omits authorization checks entirely. The CVSS vector (PR:N/AC:L/AV:N) confirms remote unauthenticated exploitation with no preconditions, and SSVC flags the attack as automatable - meaning scripted enumeration of order identifiers at scale is trivially achievable. No public exploit has been identified at time of analysis, and EPSS at 0.14% (4th percentile) reflects negligible current exploitation interest, though the missing permission check pattern is well-understood by WordPress-focused threat actors.
Spring Integration's UnZipTransformer component fails to impose any limit on decompressed entry size or entry count, enabling a low-privileged remote attacker to trigger JVM heap exhaustion via a crafted zip bomb archive. Affected versions span 6.4.0-6.4.12, 6.5.0-6.5.10, and 7.0.0-7.1.0 across the widely-used Spring enterprise Java framework. The attack primitive is well-understood and trivially constructable, though exploitation requires access to an integration endpoint that routes payloads through UnZipTransformer; no public exploit code has been identified at time of analysis and this CVE is not listed in the CISA KEV catalog.