Information Disclosure
Monthly
ReQuest Serious Play F3 Media Server versions 7.0.3.4968 (Pro), 7.0.2.4954, 6.5.2.4954, 6.4.2.4681, 6.3.2.4203, and 2.0.1.823 allows unauthenticated attackers to disclose the webserver's Python debug log file containing system information, credentials, paths, processes and command arguments running on the device. Attackers can access sensitive information by visiting the message_log page.
A security vulnerability in Nextcloud Server and Enterprise Server (CVSS 4.3). Remediation should follow standard vulnerability management procedures. Vendor patch is available.
A security vulnerability in Nextcloud Calendar (CVSS 5.7). Risk factors: public PoC available. Vendor patch is available.
Nextcloud Calendar is a calendar app for Nextcloud. Prior to 6.0.3, the Calendar app generates participant tokens for meeting proposals using a hash function, allowing an attacker to compute valid participant tokens, which allowed them to request details and submit dates in meeting proposals. The tokens are not purely random generated. This vulnerability is fixed in 6.0.3.
A security vulnerability in Nextcloud Server (CVSS 4.5) that allows an authenticated user. Remediation should follow standard vulnerability management procedures. Vendor patch is available.
A flaw was found in util-linux.
A security vulnerability in GitLab CE/EE affecting all (CVSS 7.7). High severity vulnerability requiring prompt remediation.
A security vulnerability in Himool ERP (CVSS 6.3). Remediation should follow standard vulnerability management procedures.
A security vulnerability in ketr JEPaaS (CVSS 6.3). Remediation should follow standard vulnerability management procedures.
CVE-2025-58098 is a security vulnerability (CVSS 8.3). High severity vulnerability requiring prompt remediation.
A security vulnerability in A vulnerability (CVSS 6.3). Risk factors: public PoC available.
In youlai-mall 1.0.0 and 2.0.0, authenticated users with low privileges can manipulate the orderId parameter in the /app-api/v1/orders/ endpoint due to improper control of dynamically-identified variables, leading to unauthorized access or modification of other users' order data. The vulnerability is remotely exploitable and a public proof-of-concept is available, though no vendor patch has been confirmed. EPSS indicates very low exploitation probability (0.06%), and the vulnerability is not listed in CISA KEV.
A security vulnerability in Apache HTTP Server (CVSS 6.5). Remediation should follow standard vulnerability management procedures.
The My auctions allegro plugin for WordPress is vulnerable to Local File Inclusion in all versions up to, and including, 3.6.32 via the 'controller' parameter. This makes it possible for unauthenticated attackers to include and execute arbitrary files on the server, allowing the execution of any PHP code in those files. This can be used to bypass access controls, obtain sensitive data, or achieve code execution in cases where images and other “safe” file types can be uploaded and included.
A security vulnerability in the KDE Connect information-exchange protocol (CVSS 4.3). Remediation should follow standard vulnerability management procedures.
A remote code execution vulnerability in CKSource CKFinder (CVSS 5.0). Remediation should follow standard vulnerability management procedures.
A security vulnerability in KDE Connect (CVSS 4.3). Remediation should follow standard vulnerability management procedures.
A remote code execution vulnerability (CVSS 4.7). Remediation should follow standard vulnerability management procedures.
The SSP Debug plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 1.0.0. This is due to the plugin storing PHP error logs in a predictable, web-accessible location (wp-content/uploads/ssp-debug/ssp-debug.log) without any access controls. This makes it possible for unauthenticated attackers to view sensitive debugging information including full URLs, client IP addresses, User-Agent strings, WordPress user IDs, and internal filesystem paths.
The SurveyFunnel - Survey Plugin for WordPress plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 1.1.5 via several unprotected /wp-json/surveyfunnel/v2/ REST API endpoints. This makes it possible for unauthenticated attackers to extract sensitive data from survey responses.
Rejected reason: Not used. No vendor patch available.
Rejected reason: Not used. No vendor patch available.
Rejected reason: Not used. No vendor patch available.
Rejected reason: Not used. No vendor patch available.
Rejected reason: Not used. No vendor patch available.
Rejected reason: Not used. No vendor patch available.
Rejected reason: Not used. No vendor patch available.
Rejected reason: Not used. No vendor patch available.
Rejected reason: Not used. No vendor patch available.
A security vulnerability in A vulnerability (CVSS 6.3). Risk factors: public PoC available.
Sigstore Timestamp Authority is a service for issuing RFC 3161 timestamps.
A security vulnerability in Taiko Alethia (CVSS 8.0). High severity vulnerability requiring prompt remediation.
Improper control of dynamically-identified variables in youlai-mall 1.0.0/2.0.0 allows authenticated low-privilege users to read or modify other users’ address data via the /mall-ums/app-api/v1/addresses/ endpoint. Public exploit code is available, though no evidence of active exploitation exists at this time. The vendor was notified but did not respond.
A security vulnerability in Fulcio (CVSS 7.5). High severity vulnerability requiring prompt remediation. Vendor patch is available.
A security vulnerability in DCIM dcTrack (CVSS 7.2) that allows an attacker. High severity vulnerability requiring prompt remediation.
Kalmia CMS version 0.2.0 contains an Incorrect Access Control vulnerability in the /kal-api/auth/users API endpoint. Due to insufficient permission validation and excessive data exposure in the backend, an authenticated user with basic read permissions can retrieve sensitive information for all platform users.
A security vulnerability in its authentication mechanism (CVSS 5.3) that allows unauthenticated attackers. Risk factors: public PoC available.
A security vulnerability in password reset mechanism for the Pivot client application (CVSS 7.5) that allows an attacker. High severity vulnerability requiring prompt remediation.
XPath Injection in WatchGuard Fireware OS exposes sensitive Firebox configuration data to remote unauthenticated attackers via the authentication or management web interface. Affected systems span four major version branches from 11.11 through 2025.1.2, covering a wide range of deployed Firebox hardware appliances. Exploitation is conditioned on the authentication hotspot feature being enabled; no public exploit code exists and EPSS sits at 0.11% (30th percentile), indicating low observed exploitation activity despite the high CVSS 4.0 score of 8.2.
When a WF200/WGM160P device is configured to operate as an Access Point, it may be vulnerable to a denial of service triggered by a malformed packet. The device may recover automatically or require a hard reset.
The web interface of the Silicon Labs Simplicity Device Manager is exposed publicly and can be used to extract the NTLMv2 hash which an attacker could use to crack the user's domain password.
Solstice Pod API (version 5.5, 6.2) contains an unauthenticated API endpoint (`/api/config`) that exposes sensitive information such as the session key, server version, product details, and display name. Unauthorized users can extract live session information by accessing this endpoint without authentication.
This vulnerability fundamentally arises from yzcheng90 X-SpringBoot 6.0's implementation of role-based access control (RBAC) through dual dependency on frontend menu systems and backend permission tables, without enforcing atomic synchronization between these components. The critical flaw manifests when frontend menu updates (such as privilege revocation) fail to propagate to the backend permission table in real-time, creating a dangerous desynchronization. While users lose access to restricted functions through the web interface (as UI elements properly disappear), the stale permission records still validate unauthorized API requests when accessed directly through tools like Postman. Attackers exploiting this inconsistency can perform privileged operations including but not limited to: creating high-permission user accounts, accessing sensitive data beyond their clearance level, and executing admin-level commands.
Medtronic CareLink Network allows a local attacker with access to log files on an internal API server to view plaintext passwords from errors logged under certain circumstances. This issue affects CareLink Network: before December 4, 2025.
Unauthenticated brute-force attacks against the Medtronic CareLink Network API authentication endpoint can allow remote attackers to determine a valid account password under certain circumstances, because the endpoint lacks adequate anti-automation controls such as rate limiting or account lockout (CWE-307). The vendor assigned CVSS 3.1 AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H (9.8 Critical), while independent analysis assesses the practical risk as materially lower - AV:N/AC:H/PR:N/UI:N/C:H/I:N/A:N (approximately 5.9, Medium) - because the advisory itself limits success to 'certain circumstances' and no integrity or availability impact has been demonstrated. Risk signals are currently muted: EPSS is 0.13% (32nd percentile), there is no public exploit identified at time of analysis, and the issue is not listed in CISA KEV; all CareLink Network instances running code from before December 4, 2025 are affected, with no user interaction or prior authentication required (PR:N in both vectors).
A security vulnerability in Medtronic CareLink Network (CVSS 5.3) that allows an unauthenticated remote attacker. Remediation should follow standard vulnerability management procedures.
There is a relative path traversal vulnerability in the NI System Web Server that may result in information disclosure. Successful exploitation requires an attacker to send a specially crafted request to the NI System Web Server, allowing the attacker to read arbitrary files. This vulnerability existed in the NI System Web Server 2012 and prior versions. It was fixed in 2013.
Waveshare RS232/485 TO WIFI ETH (B) Serial to Ethernet/Wi-Fi Gateway Firmware V3.1.1.0: HW 4.3.2.1: Webpage V7.04T.07.002880.0301 was discovered to render the Administrator password in plaintext.
A security vulnerability in macrozheng mall-swarm (CVSS 5.4). Risk factors: public PoC available.
A vulnerability exists in PX Enterprise whereby sensitive information may be logged under specific conditions.
Akamai Ghost on Akamai CDN edge servers before 2025-11-17 has a chunked request body processing error that can result in HTTP request smuggling. When Akamai Ghost receives an invalid chunked body that includes a chunk size different from the actual size of the following chunk data, under certain circumstances, Akamai Ghost erroneously forwards the invalid request and subsequent superfluous bytes to the origin server. An attacker could hide a smuggled request in these superfluous bytes. Whether this is exploitable depends on the origin server's behavior and how it processes the invalid request it receives from Akamai Ghost.
Waveshare RS232/485 TO WIFI ETH (B) Serial to Ethernet/Wi-Fi Gateway Firmware V3.1.1.0: HW 4.3.2.1: Webpage V7.04T.07.002880.0301 was discovered to transmit Administrator credentials in plaintext.
Origin validation error vulnerability in BeeDrive in Synology BeeDrive for desktop before 1.4.3-13973 allows local users to write arbitrary files with non-sensitive information via unspecified vectors.
Directory Traversal vulnerability in ComposioHQ v.0.7.20 allows a remote attacker to obtain sensitive information via the _download_file_or_dir function.
Out-of-bounds memory access in the Linux kernel's arm64 protected-KVM (pKVM) hypervisor allows a compromised or malicious host kernel to read beyond the bounds of the hypervisor's FF-A (Arm Firmware Framework) shared-memory buffer by supplying an unvalidated composite-memory-region offset in the range [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX]. Because the host is normally treated as untrusted relative to the hypervisor in the pKVM confidential-compute model, this breaks the host/hypervisor isolation boundary (CVSS scope change) and can disclose hypervisor memory or crash it. There is no public exploit identified at time of analysis, and the EPSS score is very low (0.03%), consistent with a hard-to-reach, config-specific hypervisor bug rather than mass exploitation.
In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] <TASK> [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---
In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site. This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb ("be2net: fix a Tx stall bug caused by a specific ipv6 packet") states. The correct way would be to pass the wrb_params from be_xmit().
In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.
Kernel crash and use-after-free list corruption in the Linux kernel's NVMe-over-Fibre-Channel (nvme-fc) transport driver occurs when tearing down a controller: nvme_fc_delete_ctrl() calls cancel_work_sync() on ->ioerr_work before nvme_fc_delete_association() completes, so a late I/O error can re-queue ->ioerr_work after cancellation and let it run against a freed nvme_fc_ctrl object. The result is a kworker hitting kernel BUG at lib/list_debug.c (list_del corruption) and an oops, affecting hosts using NVMe/FC attached storage. There is no public exploit identified at time of analysis, and EPSS is very low (0.05%), consistent with a local, hardware-conditional stability bug rather than a broadly weaponizable flaw.
In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.
Use-after-free in the Linux kernel's MPTCP subsystem stems from a race in mptcp_schedule_work() (net/mptcp/protocol.c), where the socket refcount was taken only after the work item was queued, allowing mptcp_worker() to run and free the socket before sock_hold() executes. Reachable via the MPTCP timeout timer (mptcp_tout_timer), it was found by syzbot and produces a refcount 'addition on 0' warning that signals kernel memory corruption. No public exploit identified at time of analysis and EPSS is very low (0.05%), consistent with a hard-to-time race rather than a readily weaponized flaw despite the auto-generated 9.8 score.
Denial-of-service via a use-after-free in the Linux kernel's MPTCP path-manager allows the add-address timer (mptcp_pm_del_add_timer()) to call sk_stop_timer_sync() on an announcement-list entry that another context has already freed, corrupting kernel memory. The flaw affects the mptcp subsystem across multiple long-lived stable branches and was found by syzbot via a KASAN slab-use-after-free report; the upstream fix adds RCU protection. No public exploit is identified at time of analysis, EPSS is 0.05%, and it is not listed in CISA KEV.
In the Linux kernel, the following vulnerability has been resolved: xfrm: also call xfrm_state_delete_tunnel at destroy time for states that were never added In commit b441cf3f8c4b ("xfrm: delete x->tunnel as we delete x"), I missed the case where state creation fails between full initialization (->init_state has been called) and being inserted on the lists. In this situation, ->init_state has been called, so for IPcomp tunnels, the fallback tunnel has been created and added onto the lists, but the user state never gets added, because we fail before that. The user state doesn't go through __xfrm_state_delete, so we don't call xfrm_state_delete_tunnel for those states, and we end up leaking the FB tunnel. There are several codepaths affected by this: the add/update paths, in both net/key and xfrm, and the migrate code (xfrm_migrate, xfrm_state_migrate). A "proper" rollback of the init_state work would probably be doable in the add/update code, but for migrate it gets more complicated as multiple states may be involved. At some point, the new (not-inserted) state will be destroyed, so call xfrm_state_delete_tunnel during xfrm_state_gc_destroy. Most states will have their fallback tunnel cleaned up during __xfrm_state_delete, which solves the issue that b441cf3f8c4b (and other patches before it) aimed at. All states (including FB tunnels) will be removed from the lists once xfrm_state_fini has called flush_work(&xfrm_state_gc_work).
Memory corruption in the Linux kernel's s390/ctcm mainframe network driver stems from a double-kfree: mpc_rcvd_sweep_req() frees the mpcginfo structure, then ctcmpc_unpack_skb() frees the same pointer again after the conditional call returns. Discovered via clang static analysis, it affects IBM Z (s390) systems using the CTCM MPC networking driver and could lead to kernel memory corruption, denial of service, or potentially escalation when a crafted MPC sweep-request frame is processed. There is no public exploit identified at time of analysis, EPSS risk is negligible (0.05%), and it is not listed in CISA KEV; the fix has shipped in stable kernel releases.
Local privilege-context memory corruption in the Linux kernel's GPIO character device (gpio cdev) subsystem allows a use-after-free on the file structure backing an open GPIO chardev descriptor. When a GPIO line-change event fires after the final fput() has dropped the fd's reference count to zero but before the deferred .release() callback unregisters the notifier, the kernel calls get_file() on a file with a zero refcount, triggering a use-after-free (warned as 'f_count incremented from zero; use-after-free condition present'). No public exploit has been identified at time of analysis and the EPSS score is negligible (0.03%), consistent with a hard-to-win local race rather than a widely exploited flaw.
Local privilege-escalation-grade memory corruption in the Linux kernel's AF_VSOCK (virtio/vhost vsock) stack allows a local user to trigger a use-after-free or NULL-pointer dereference by racing a signal or timeout against an in-progress connect() on an already-established socket. Aborting the connect could tear down a connected socket while a concurrent sendmsg() or sockmap operation runs, corrupting credit accounting (bytes_unsent), breaking sockmap invariants, and enabling a transport change/drop after TCP_ESTABLISHED. No public exploit is identified at time of analysis and EPSS is 0.05%, but the flaw is patched across many stable branches and tracked by Ubuntu, Debian, and Siemens.
Memory-map miscalculation in the Linux kernel's nios2 architecture code allows local low-privileged users to trigger kernel paging failures and denial of service on affected nios2 (soft-core) systems built with CONFIG_FLATMEM. Because memblock.current_limit is left at its default MEMBLOCK_ALLOC_ANYWHERE when pfn limits are computed, max_low_pfn can exceed max_pfn and push mem_map beyond valid DRAM, producing 'Unable to handle kernel paging request' oopses and kernel panics. No public exploit identified at time of analysis; EPSS is 0.04% (11th percentile) and the flaw is not in CISA KEV.
Uninitialized-memory read in the Linux kernel's HFS+ filesystem driver (__hfsplus_ext_cache_extent) allows a local actor who can write to a mounted HFS+ volume to trigger use of uninitialized heap data, leading to information disclosure or a kernel crash. The flaw, found by syzbot via KMSAN on kernel 6.12-rc5, is fixed across multiple stable trees; there is no public exploit identified at time of analysis and EPSS exploitation probability is very low (0.04%, 11th percentile). Distributions including Ubuntu (USN-8029/8030/8033/8034) and Debian (DLA-4404-1) have shipped patches.
Uninitialized-memory (KMSAN uninit-value) defect in the Linux kernel HFS filesystem driver allows a local attacker who can mount or operate on a crafted HFS volume to corrupt on-disk allocation state and destabilize the filesystem. The bitmap buffer in hfs_mdb_get() was allocated with kmalloc() (leaving residual heap garbage) and later consumed by hfs_find_set_zero_bits() during block allocation, so non-zero uninitialized bits can drive incorrect bitmap decisions leading to volume corruption and driver misbehavior. Discovered by syzbot fuzzing; there is no public exploit identified at time of analysis and EPSS risk is very low (0.04%).
Kernel memory corruption in the Linux kernel's GFS2 clustered filesystem stems from a use-after-free race in gdlm_put_lock(), where a small window exists after the DFL_UNMOUNT flag is set but before the DLM lockspace is released. During that window the DLM callbacks gdlm_ast() and gdlm_bast() can still fire and dereference already-freed glock objects, potentially crashing the kernel or corrupting memory on systems using GFS2. The issue carries a CVSS 3.1 base score of 7.0 (AV:L/AC:H/PR:L), has an EPSS of only 0.03%, is not in CISA KEV, and has no public exploit identified at time of analysis; it is patched upstream and shipped by Ubuntu and Debian.
Denial of service in the Linux kernel SCTP subsystem allows remote attackers to crash affected systems via a NULL pointer dereference triggered when an SCTP chunk arrives without a data buffer. The flaw stems from dereferencing chunk->skb inside a code path that assumes it is NULL, and is fixed across multiple stable trees (5.4.301, 5.10.246, 5.15.196, 6.1.158, 6.6.115, 6.12.56, 6.17.6, 6.18). No public exploit identified at time of analysis, and EPSS probability is very low (0.04%, 11th percentile), indicating minimal real-world exploitation likelihood despite the network-reachable vector.
In the Linux kernel, the following vulnerability has been resolved: fs/notify: call exportfs_encode_fid with s_umount Calling intotify_show_fdinfo() on fd watching an overlayfs inode, while the overlayfs is being unmounted, can lead to dereferencing NULL ptr. This issue was found by syzkaller. Race Condition Diagram: Thread 1 Thread 2 -------- -------- generic_shutdown_super() shrink_dcache_for_umount sb->s_root = NULL | | vfs_read() | inotify_fdinfo() | * inode get from mark * | show_mark_fhandle(m, inode) | exportfs_encode_fid(inode, ..) | ovl_encode_fh(inode, ..) | ovl_check_encode_origin(inode) | * deref i_sb->s_root * | | v fsnotify_sb_delete(sb) Which then leads to: [ 32.133461] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 32.134438] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 32.135032] CPU: 1 UID: 0 PID: 4468 Comm: systemd-coredum Not tainted 6.17.0-rc6 #22 PREEMPT(none) <snip registers, unreliable trace> [ 32.143353] Call Trace: [ 32.143732] ovl_encode_fh+0xd5/0x170 [ 32.144031] exportfs_encode_inode_fh+0x12f/0x300 [ 32.144425] show_mark_fhandle+0xbe/0x1f0 [ 32.145805] inotify_fdinfo+0x226/0x2d0 [ 32.146442] inotify_show_fdinfo+0x1c5/0x350 [ 32.147168] seq_show+0x530/0x6f0 [ 32.147449] seq_read_iter+0x503/0x12a0 [ 32.148419] seq_read+0x31f/0x410 [ 32.150714] vfs_read+0x1f0/0x9e0 [ 32.152297] ksys_read+0x125/0x240 IOW ovl_check_encode_origin derefs inode->i_sb->s_root, after it was set to NULL in the unmount path. Fix it by protecting calling exportfs_encode_fid() from show_mark_fhandle() with s_umount lock. This form of fix was suggested by Amir in [1]. [1]: https://lore.kernel.org/all/CAOQ4uxhbDwhb+2Brs1UdkoF0a3NSdBAOQPNfEHjahrgoKJpLEw@mail.gmail.com/
In the Linux kernel, the following vulnerability has been resolved: virtio-net: zero unused hash fields When GSO tunnel is negotiated virtio_net_hdr_tnl_from_skb() tries to initialize the tunnel metadata but forget to zero unused rxhash fields. This may leak information to another side. Fixing this by zeroing the unused hash fields.
Stale extent-map cache handling in the Linux kernel's OCFS2 clustered filesystem lets a local, low-privileged user with access to an OCFS2 mount crash the kernel and read or corrupt on-disk extent data. After a reflinked (OCFS2_EXT_REFCOUNTED) extent is moved or defragmented, the in-memory extent cache retains stale flags while the disk holds updated ones; a subsequent write hits a BUG_ON in ocfs2_refcount_cal_cow_clusters(), producing a panic (denial of service) and potential data/integrity impact. There is no public exploit identified at time of analysis, and EPSS is very low (0.05%, 16th percentile), consistent with a niche, non-KEV local kernel bug rather than a mass-exploited flaw.
In the Linux kernel, the following vulnerability has been resolved: vsock: fix lock inversion in vsock_assign_transport() Syzbot reported a potential lock inversion deadlock between vsock_register_mutex and sk_lock-AF_VSOCK when vsock_linger() is called. The issue was introduced by commit 687aa0c5581b ("vsock: Fix transport_* TOCTOU") which added vsock_register_mutex locking in vsock_assign_transport() around the transport->release() call, that can call vsock_linger(). vsock_assign_transport() can be called with sk_lock held. vsock_linger() calls sk_wait_event() that temporarily releases and re-acquires sk_lock. During this window, if another thread hold vsock_register_mutex while trying to acquire sk_lock, a circular dependency is created. Fix this by releasing vsock_register_mutex before calling transport->release() and vsock_deassign_transport(). This is safe because we don't need to hold vsock_register_mutex while releasing the old transport, and we ensure the new transport won't disappear by obtaining a module reference first via try_module_get().
In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: fix potential memory leak by cleaning ops_filter in damon_destroy_scheme Currently, damon_destroy_scheme() only cleans up the filter list but leaves ops_filter untouched, which could lead to memory leaks when a scheme is destroyed. This patch ensures both filter and ops_filter are properly freed in damon_destroy_scheme(), preventing potential memory leaks.
In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs: catch commit test ctx alloc failure Patch series "mm/damon/sysfs: fix commit test damon_ctx [de]allocation". DAMON sysfs interface dynamically allocates and uses a damon_ctx object for testing if given inputs for online DAMON parameters update is valid. The object is being used without an allocation failure check, and leaked when the test succeeds. Fix the two bugs. This patch (of 2): The damon_ctx for testing online DAMON parameters commit inputs is used without its allocation failure check. This could result in an invalid memory access. Fix it by directly returning an error when the allocation failed.
In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs: dealloc commit test ctx always The damon_ctx for testing online DAMON parameters commit inputs is deallocated only when the test fails. This means memory is leaked for every successful online DAMON parameters commit. Fix the leak by always deallocating it.
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Account for failed debug initialization When the SCMI debug subsystem fails to initialize, the related debug root will be missing, and the underlying descriptor will be NULL. Handle this fault condition in the SCMI debug helpers that maintain metrics counters.
In the Linux kernel, the following vulnerability has been resolved: most: usb: Fix use-after-free in hdm_disconnect hdm_disconnect() calls most_deregister_interface(), which eventually unregisters the MOST interface device with device_unregister(iface->dev). If that drops the last reference, the device core may call release_mdev() immediately while hdm_disconnect() is still executing. The old code also freed several mdev-owned allocations in hdm_disconnect() and then performed additional put_device() calls. Depending on refcount order, this could lead to use-after-free or double-free when release_mdev() ran (or when unregister paths also performed puts). Fix by moving the frees of mdev-owned allocations into release_mdev(), so they happen exactly once when the device is truly released, and by dropping the extra put_device() calls in hdm_disconnect() that are redundant after device_unregister() and most_deregister_interface(). This addresses the KASAN slab-use-after-free reported by syzbot in hdm_disconnect(). See report and stack traces in the bug link below.
In the Linux kernel, the following vulnerability has been resolved: tty: serial: sh-sci: fix RSCI FIFO overrun handling The receive error handling code is shared between RSCI and all other SCIF port types, but the RSCI overrun_reg is specified as a memory offset, while for other SCIF types it is an enum value used to index into the sci_port_params->regs array, as mentioned above the sci_serial_in() function. For RSCI, the overrun_reg is CSR (0x48), causing the sci_getreg() call inside the sci_handle_fifo_overrun() function to index outside the bounds of the regs array, which currently has a size of 20, as specified by SCI_NR_REGS. Because of this, we end up accessing memory outside of RSCI's rsci_port_params structure, which, when interpreted as a plat_sci_reg, happens to have a non-zero size, causing the following WARN when sci_serial_in() is called, as the accidental size does not match the supported register sizes. The existence of the overrun_reg needs to be checked because SCIx_SH3_SCIF_REGTYPE has overrun_reg set to SCLSR, but SCLSR is not present in the regs array. Avoid calling sci_getreg() for port types which don't use standard register handling. Use the ops->read_reg() and ops->write_reg() functions to properly read and write registers for RSCI, and change the type of the status variable to accommodate the 32-bit CSR register. sci_getreg() and sci_serial_in() are also called with overrun_reg in the sci_mpxed_interrupt() interrupt handler, but that code path is not used for RSCI, as it does not have a muxed interrupt. ------------[ cut here ]------------ Invalid register access WARNING: CPU: 0 PID: 0 at drivers/tty/serial/sh-sci.c:522 sci_serial_in+0x38/0xac Modules linked in: renesas_usbhs at24 rzt2h_adc industrialio_adc sha256 cfg80211 bluetooth ecdh_generic ecc rfkill fuse drm backlight ipv6 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.17.0-rc1+ #30 PREEMPT Hardware name: Renesas RZ/T2H EVK Board based on r9a09g077m44 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : sci_serial_in+0x38/0xac lr : sci_serial_in+0x38/0xac sp : ffff800080003e80 x29: ffff800080003e80 x28: ffff800082195b80 x27: 000000000000000d x26: ffff8000821956d0 x25: 0000000000000000 x24: ffff800082195b80 x23: ffff000180e0d800 x22: 0000000000000010 x21: 0000000000000000 x20: 0000000000000010 x19: ffff000180e72000 x18: 000000000000000a x17: ffff8002bcee7000 x16: ffff800080000000 x15: 0720072007200720 x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720 x11: 0000000000000058 x10: 0000000000000018 x9 : ffff8000821a6a48 x8 : 0000000000057fa8 x7 : 0000000000000406 x6 : ffff8000821fea48 x5 : ffff00033ef88408 x4 : ffff8002bcee7000 x3 : ffff800082195b80 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800082195b80 Call trace: sci_serial_in+0x38/0xac (P) sci_handle_fifo_overrun.isra.0+0x70/0x134 sci_er_interrupt+0x50/0x39c __handle_irq_event_percpu+0x48/0x140 handle_irq_event+0x44/0xb0 handle_fasteoi_irq+0xf4/0x1a0 handle_irq_desc+0x34/0x58 generic_handle_domain_irq+0x1c/0x28 gic_handle_irq+0x4c/0x140 call_on_irq_stack+0x30/0x48 do_interrupt_handler+0x80/0x84 el1_interrupt+0x34/0x68 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 default_idle_call+0x28/0x58 (P) do_idle+0x1f8/0x250 cpu_startup_entry+0x34/0x3c rest_init+0xd8/0xe0 console_on_rootfs+0x0/0x6c __primary_switched+0x88/0x90 ---[ end trace 0000000000000000 ]---
Rejected reason: ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. No vendor patch available.
An issue was discovered on Thermo Fisher Ion Torrent OneTouch 2 INS1005527 devices. When they are powered on, an X11 display server is started. The display server listens on all network interfaces and is accessible over port 6000. The X11 access control list, by default, allows connections from 127.0.0.1 and 192.168.2.15. If a device is powered on and later connected to a network with DHCP, the device may not be assigned the 192.168.2.15 IP address, leaving the display server accessible by other devices on the network. The exposed X11 display server can then be used to gain root privileges and the ability to execute code remotely by interacting with matchbox-desktop and spawning a terminal. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.
A remote code execution vulnerability in Thermo Fisher Torrent Suite Django application 5.18.1 (CVSS 9.8). Critical severity with potential for significant impact on affected systems.
In the Linux kernel, the following vulnerability has been resolved: media: pci: mg4b: fix uninitialized iio scan data Fix potential leak of uninitialized stack data to userspace by ensuring that the `scan` structure is zeroed before use.
In the Linux kernel, the following vulnerability has been resolved: fuse: fix livelock in synchronous file put from fuseblk workers I observed a hang when running generic/323 against a fuseblk server. This test opens a file, initiates a lot of AIO writes to that file descriptor, and closes the file descriptor before the writes complete. Unsurprisingly, the AIO exerciser threads are mostly stuck waiting for responses from the fuseblk server: # cat /proc/372265/task/372313/stack [<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_do_getattr+0xfc/0x1f0 [fuse] [<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse] [<0>] aio_read+0x130/0x1e0 [<0>] io_submit_one+0x542/0x860 [<0>] __x64_sys_io_submit+0x98/0x1a0 [<0>] do_syscall_64+0x37/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 But the /weird/ part is that the fuseblk server threads are waiting for responses from itself: # cat /proc/372210/task/372232/stack [<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_file_put+0x9a/0xd0 [fuse] [<0>] fuse_release+0x36/0x50 [fuse] [<0>] __fput+0xec/0x2b0 [<0>] task_work_run+0x55/0x90 [<0>] syscall_exit_to_user_mode+0xe9/0x100 [<0>] do_syscall_64+0x43/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 The fuseblk server is fuse2fs so there's nothing all that exciting in the server itself. So why is the fuse server calling fuse_file_put? The commit message for the fstest sheds some light on that: "By closing the file descriptor before calling io_destroy, you pretty much guarantee that the last put on the ioctx will be done in interrupt context (during I/O completion). Aha. AIO fgets a new struct file from the fd when it queues the ioctx. The completion of the FUSE_WRITE command from userspace causes the fuse server to call the AIO completion function. The completion puts the struct file, queuing a delayed fput to the fuse server task. When the fuse server task returns to userspace, it has to run the delayed fput, which in the case of a fuseblk server, it does synchronously. Sending the FUSE_RELEASE command sychronously from fuse server threads is a bad idea because a client program can initiate enough simultaneous AIOs such that all the fuse server threads end up in delayed_fput, and now there aren't any threads left to handle the queued fuse commands. Fix this by only using asynchronous fputs when closing files, and leave a comment explaining why.
In the Linux kernel, the following vulnerability has been resolved: PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV Before disabling SR-IOV via config space accesses to the parent PF, sriov_disable() first removes the PCI devices representing the VFs. Since commit 9d16947b7583 ("PCI: Add global pci_lock_rescan_remove()") such removal operations are serialized against concurrent remove and rescan using the pci_rescan_remove_lock. No such locking was ever added in sriov_disable() however. In particular when commit 18f9e9d150fc ("PCI/IOV: Factor out sriov_add_vfs()") factored out the PCI device removal into sriov_del_vfs() there was still no locking around the pci_iov_remove_virtfn() calls. On s390 the lack of serialization in sriov_disable() may cause double remove and list corruption with the below (amended) trace being observed: PSW: 0704c00180000000 0000000c914e4b38 (klist_put+56) GPRS: 000003800313fb48 0000000000000000 0000000100000001 0000000000000001 00000000f9b520a8 0000000000000000 0000000000002fbd 00000000f4cc9480 0000000000000001 0000000000000000 0000000000000000 0000000180692828 00000000818e8000 000003800313fe2c 000003800313fb20 000003800313fad8 #0 [3800313fb20] device_del at c9158ad5c #1 [3800313fb88] pci_remove_bus_device at c915105ba #2 [3800313fbd0] pci_iov_remove_virtfn at c9152f198 #3 [3800313fc28] zpci_iov_remove_virtfn at c90fb67c0 #4 [3800313fc60] zpci_bus_remove_device at c90fb6104 #5 [3800313fca0] __zpci_event_availability at c90fb3dca #6 [3800313fd08] chsc_process_sei_nt0 at c918fe4a2 #7 [3800313fd60] crw_collect_info at c91905822 #8 [3800313fe10] kthread at c90feb390 #9 [3800313fe68] __ret_from_fork at c90f6aa64 #10 [3800313fe98] ret_from_fork at c9194f3f2. This is because in addition to sriov_disable() removing the VFs, the platform also generates hot-unplug events for the VFs. This being the reverse operation to the hotplug events generated by sriov_enable() and handled via pdev->no_vf_scan. And while the event processing takes pci_rescan_remove_lock and checks whether the struct pci_dev still exists, the lack of synchronization makes this checking racy. Other races may also be possible of course though given that this lack of locking persisted so long observable races seem very rare. Even on s390 the list corruption was only observed with certain devices since the platform events are only triggered by config accesses after the removal, so as long as the removal finished synchronously they would not race. Either way the locking is missing so fix this by adding it to the sriov_del_vfs() helper. Just like PCI rescan-remove, locking is also missing in sriov_add_vfs() including for the error case where pci_stop_and_remove_bus_device() is called without the PCI rescan-remove lock being held. Even in the non-error case, adding new PCI devices and buses should be serialized via the PCI rescan-remove lock. Add the necessary locking.
In the Linux kernel, the following vulnerability has been resolved: pidfs: validate extensible ioctls Validate extensible ioctls stricter than we do now.
Local privilege-relevant memory corruption in the Linux kernel's io_uring resource (rsrc) subsystem stems from faulty offset arithmetic when computing the first page of a coalesced folio from an unaligned user virtual address, allowing a local low-privileged user submitting io_uring requests to trigger out-of-bounds access with high confidentiality, integrity, and availability impact. Fixed upstream and backported to stable trees (6.12.36, 6.15.5, 6.16); no public exploit identified at time of analysis and EPSS exploitation probability is very low (0.03%, 6th percentile). Not listed in CISA KEV.
Improper control of dynamically-managed code resources vulnerability in WebAPI component in Synology DiskStation Manager (DSM) before 7.1.1-42962-8 and 7.2.1-69057-2 and 7.2.2-72806 and Synology Unified Controller (DSMUC) before 3.1.4-23079 allows remote authenticated users to obtain privileges without consent via unspecified vectors.
ReQuest Serious Play F3 Media Server versions 7.0.3.4968 (Pro), 7.0.2.4954, 6.5.2.4954, 6.4.2.4681, 6.3.2.4203, and 2.0.1.823 allows unauthenticated attackers to disclose the webserver's Python debug log file containing system information, credentials, paths, processes and command arguments running on the device. Attackers can access sensitive information by visiting the message_log page.
A security vulnerability in Nextcloud Server and Enterprise Server (CVSS 4.3). Remediation should follow standard vulnerability management procedures. Vendor patch is available.
A security vulnerability in Nextcloud Calendar (CVSS 5.7). Risk factors: public PoC available. Vendor patch is available.
Nextcloud Calendar is a calendar app for Nextcloud. Prior to 6.0.3, the Calendar app generates participant tokens for meeting proposals using a hash function, allowing an attacker to compute valid participant tokens, which allowed them to request details and submit dates in meeting proposals. The tokens are not purely random generated. This vulnerability is fixed in 6.0.3.
A security vulnerability in Nextcloud Server (CVSS 4.5) that allows an authenticated user. Remediation should follow standard vulnerability management procedures. Vendor patch is available.
A flaw was found in util-linux.
A security vulnerability in GitLab CE/EE affecting all (CVSS 7.7). High severity vulnerability requiring prompt remediation.
A security vulnerability in Himool ERP (CVSS 6.3). Remediation should follow standard vulnerability management procedures.
A security vulnerability in ketr JEPaaS (CVSS 6.3). Remediation should follow standard vulnerability management procedures.
CVE-2025-58098 is a security vulnerability (CVSS 8.3). High severity vulnerability requiring prompt remediation.
A security vulnerability in A vulnerability (CVSS 6.3). Risk factors: public PoC available.
In youlai-mall 1.0.0 and 2.0.0, authenticated users with low privileges can manipulate the orderId parameter in the /app-api/v1/orders/ endpoint due to improper control of dynamically-identified variables, leading to unauthorized access or modification of other users' order data. The vulnerability is remotely exploitable and a public proof-of-concept is available, though no vendor patch has been confirmed. EPSS indicates very low exploitation probability (0.06%), and the vulnerability is not listed in CISA KEV.
A security vulnerability in Apache HTTP Server (CVSS 6.5). Remediation should follow standard vulnerability management procedures.
The My auctions allegro plugin for WordPress is vulnerable to Local File Inclusion in all versions up to, and including, 3.6.32 via the 'controller' parameter. This makes it possible for unauthenticated attackers to include and execute arbitrary files on the server, allowing the execution of any PHP code in those files. This can be used to bypass access controls, obtain sensitive data, or achieve code execution in cases where images and other “safe” file types can be uploaded and included.
A security vulnerability in the KDE Connect information-exchange protocol (CVSS 4.3). Remediation should follow standard vulnerability management procedures.
A remote code execution vulnerability in CKSource CKFinder (CVSS 5.0). Remediation should follow standard vulnerability management procedures.
A security vulnerability in KDE Connect (CVSS 4.3). Remediation should follow standard vulnerability management procedures.
A remote code execution vulnerability (CVSS 4.7). Remediation should follow standard vulnerability management procedures.
The SSP Debug plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 1.0.0. This is due to the plugin storing PHP error logs in a predictable, web-accessible location (wp-content/uploads/ssp-debug/ssp-debug.log) without any access controls. This makes it possible for unauthenticated attackers to view sensitive debugging information including full URLs, client IP addresses, User-Agent strings, WordPress user IDs, and internal filesystem paths.
The SurveyFunnel - Survey Plugin for WordPress plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 1.1.5 via several unprotected /wp-json/surveyfunnel/v2/ REST API endpoints. This makes it possible for unauthenticated attackers to extract sensitive data from survey responses.
Rejected reason: Not used. No vendor patch available.
Rejected reason: Not used. No vendor patch available.
Rejected reason: Not used. No vendor patch available.
Rejected reason: Not used. No vendor patch available.
Rejected reason: Not used. No vendor patch available.
Rejected reason: Not used. No vendor patch available.
Rejected reason: Not used. No vendor patch available.
Rejected reason: Not used. No vendor patch available.
Rejected reason: Not used. No vendor patch available.
A security vulnerability in A vulnerability (CVSS 6.3). Risk factors: public PoC available.
Sigstore Timestamp Authority is a service for issuing RFC 3161 timestamps.
A security vulnerability in Taiko Alethia (CVSS 8.0). High severity vulnerability requiring prompt remediation.
Improper control of dynamically-identified variables in youlai-mall 1.0.0/2.0.0 allows authenticated low-privilege users to read or modify other users’ address data via the /mall-ums/app-api/v1/addresses/ endpoint. Public exploit code is available, though no evidence of active exploitation exists at this time. The vendor was notified but did not respond.
A security vulnerability in Fulcio (CVSS 7.5). High severity vulnerability requiring prompt remediation. Vendor patch is available.
A security vulnerability in DCIM dcTrack (CVSS 7.2) that allows an attacker. High severity vulnerability requiring prompt remediation.
Kalmia CMS version 0.2.0 contains an Incorrect Access Control vulnerability in the /kal-api/auth/users API endpoint. Due to insufficient permission validation and excessive data exposure in the backend, an authenticated user with basic read permissions can retrieve sensitive information for all platform users.
A security vulnerability in its authentication mechanism (CVSS 5.3) that allows unauthenticated attackers. Risk factors: public PoC available.
A security vulnerability in password reset mechanism for the Pivot client application (CVSS 7.5) that allows an attacker. High severity vulnerability requiring prompt remediation.
XPath Injection in WatchGuard Fireware OS exposes sensitive Firebox configuration data to remote unauthenticated attackers via the authentication or management web interface. Affected systems span four major version branches from 11.11 through 2025.1.2, covering a wide range of deployed Firebox hardware appliances. Exploitation is conditioned on the authentication hotspot feature being enabled; no public exploit code exists and EPSS sits at 0.11% (30th percentile), indicating low observed exploitation activity despite the high CVSS 4.0 score of 8.2.
When a WF200/WGM160P device is configured to operate as an Access Point, it may be vulnerable to a denial of service triggered by a malformed packet. The device may recover automatically or require a hard reset.
The web interface of the Silicon Labs Simplicity Device Manager is exposed publicly and can be used to extract the NTLMv2 hash which an attacker could use to crack the user's domain password.
Solstice Pod API (version 5.5, 6.2) contains an unauthenticated API endpoint (`/api/config`) that exposes sensitive information such as the session key, server version, product details, and display name. Unauthorized users can extract live session information by accessing this endpoint without authentication.
This vulnerability fundamentally arises from yzcheng90 X-SpringBoot 6.0's implementation of role-based access control (RBAC) through dual dependency on frontend menu systems and backend permission tables, without enforcing atomic synchronization between these components. The critical flaw manifests when frontend menu updates (such as privilege revocation) fail to propagate to the backend permission table in real-time, creating a dangerous desynchronization. While users lose access to restricted functions through the web interface (as UI elements properly disappear), the stale permission records still validate unauthorized API requests when accessed directly through tools like Postman. Attackers exploiting this inconsistency can perform privileged operations including but not limited to: creating high-permission user accounts, accessing sensitive data beyond their clearance level, and executing admin-level commands.
Medtronic CareLink Network allows a local attacker with access to log files on an internal API server to view plaintext passwords from errors logged under certain circumstances. This issue affects CareLink Network: before December 4, 2025.
Unauthenticated brute-force attacks against the Medtronic CareLink Network API authentication endpoint can allow remote attackers to determine a valid account password under certain circumstances, because the endpoint lacks adequate anti-automation controls such as rate limiting or account lockout (CWE-307). The vendor assigned CVSS 3.1 AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H (9.8 Critical), while independent analysis assesses the practical risk as materially lower - AV:N/AC:H/PR:N/UI:N/C:H/I:N/A:N (approximately 5.9, Medium) - because the advisory itself limits success to 'certain circumstances' and no integrity or availability impact has been demonstrated. Risk signals are currently muted: EPSS is 0.13% (32nd percentile), there is no public exploit identified at time of analysis, and the issue is not listed in CISA KEV; all CareLink Network instances running code from before December 4, 2025 are affected, with no user interaction or prior authentication required (PR:N in both vectors).
A security vulnerability in Medtronic CareLink Network (CVSS 5.3) that allows an unauthenticated remote attacker. Remediation should follow standard vulnerability management procedures.
There is a relative path traversal vulnerability in the NI System Web Server that may result in information disclosure. Successful exploitation requires an attacker to send a specially crafted request to the NI System Web Server, allowing the attacker to read arbitrary files. This vulnerability existed in the NI System Web Server 2012 and prior versions. It was fixed in 2013.
Waveshare RS232/485 TO WIFI ETH (B) Serial to Ethernet/Wi-Fi Gateway Firmware V3.1.1.0: HW 4.3.2.1: Webpage V7.04T.07.002880.0301 was discovered to render the Administrator password in plaintext.
A security vulnerability in macrozheng mall-swarm (CVSS 5.4). Risk factors: public PoC available.
A vulnerability exists in PX Enterprise whereby sensitive information may be logged under specific conditions.
Akamai Ghost on Akamai CDN edge servers before 2025-11-17 has a chunked request body processing error that can result in HTTP request smuggling. When Akamai Ghost receives an invalid chunked body that includes a chunk size different from the actual size of the following chunk data, under certain circumstances, Akamai Ghost erroneously forwards the invalid request and subsequent superfluous bytes to the origin server. An attacker could hide a smuggled request in these superfluous bytes. Whether this is exploitable depends on the origin server's behavior and how it processes the invalid request it receives from Akamai Ghost.
Waveshare RS232/485 TO WIFI ETH (B) Serial to Ethernet/Wi-Fi Gateway Firmware V3.1.1.0: HW 4.3.2.1: Webpage V7.04T.07.002880.0301 was discovered to transmit Administrator credentials in plaintext.
Origin validation error vulnerability in BeeDrive in Synology BeeDrive for desktop before 1.4.3-13973 allows local users to write arbitrary files with non-sensitive information via unspecified vectors.
Directory Traversal vulnerability in ComposioHQ v.0.7.20 allows a remote attacker to obtain sensitive information via the _download_file_or_dir function.
Out-of-bounds memory access in the Linux kernel's arm64 protected-KVM (pKVM) hypervisor allows a compromised or malicious host kernel to read beyond the bounds of the hypervisor's FF-A (Arm Firmware Framework) shared-memory buffer by supplying an unvalidated composite-memory-region offset in the range [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX]. Because the host is normally treated as untrusted relative to the hypervisor in the pKVM confidential-compute model, this breaks the host/hypervisor isolation boundary (CVSS scope change) and can disclose hypervisor memory or crash it. There is no public exploit identified at time of analysis, and the EPSS score is very low (0.03%), consistent with a hard-to-reach, config-specific hypervisor bug rather than mass exploitation.
In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] <TASK> [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---
In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site. This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb ("be2net: fix a Tx stall bug caused by a specific ipv6 packet") states. The correct way would be to pass the wrb_params from be_xmit().
In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.
Kernel crash and use-after-free list corruption in the Linux kernel's NVMe-over-Fibre-Channel (nvme-fc) transport driver occurs when tearing down a controller: nvme_fc_delete_ctrl() calls cancel_work_sync() on ->ioerr_work before nvme_fc_delete_association() completes, so a late I/O error can re-queue ->ioerr_work after cancellation and let it run against a freed nvme_fc_ctrl object. The result is a kworker hitting kernel BUG at lib/list_debug.c (list_del corruption) and an oops, affecting hosts using NVMe/FC attached storage. There is no public exploit identified at time of analysis, and EPSS is very low (0.05%), consistent with a local, hardware-conditional stability bug rather than a broadly weaponizable flaw.
In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.
Use-after-free in the Linux kernel's MPTCP subsystem stems from a race in mptcp_schedule_work() (net/mptcp/protocol.c), where the socket refcount was taken only after the work item was queued, allowing mptcp_worker() to run and free the socket before sock_hold() executes. Reachable via the MPTCP timeout timer (mptcp_tout_timer), it was found by syzbot and produces a refcount 'addition on 0' warning that signals kernel memory corruption. No public exploit identified at time of analysis and EPSS is very low (0.05%), consistent with a hard-to-time race rather than a readily weaponized flaw despite the auto-generated 9.8 score.
Denial-of-service via a use-after-free in the Linux kernel's MPTCP path-manager allows the add-address timer (mptcp_pm_del_add_timer()) to call sk_stop_timer_sync() on an announcement-list entry that another context has already freed, corrupting kernel memory. The flaw affects the mptcp subsystem across multiple long-lived stable branches and was found by syzbot via a KASAN slab-use-after-free report; the upstream fix adds RCU protection. No public exploit is identified at time of analysis, EPSS is 0.05%, and it is not listed in CISA KEV.
In the Linux kernel, the following vulnerability has been resolved: xfrm: also call xfrm_state_delete_tunnel at destroy time for states that were never added In commit b441cf3f8c4b ("xfrm: delete x->tunnel as we delete x"), I missed the case where state creation fails between full initialization (->init_state has been called) and being inserted on the lists. In this situation, ->init_state has been called, so for IPcomp tunnels, the fallback tunnel has been created and added onto the lists, but the user state never gets added, because we fail before that. The user state doesn't go through __xfrm_state_delete, so we don't call xfrm_state_delete_tunnel for those states, and we end up leaking the FB tunnel. There are several codepaths affected by this: the add/update paths, in both net/key and xfrm, and the migrate code (xfrm_migrate, xfrm_state_migrate). A "proper" rollback of the init_state work would probably be doable in the add/update code, but for migrate it gets more complicated as multiple states may be involved. At some point, the new (not-inserted) state will be destroyed, so call xfrm_state_delete_tunnel during xfrm_state_gc_destroy. Most states will have their fallback tunnel cleaned up during __xfrm_state_delete, which solves the issue that b441cf3f8c4b (and other patches before it) aimed at. All states (including FB tunnels) will be removed from the lists once xfrm_state_fini has called flush_work(&xfrm_state_gc_work).
Memory corruption in the Linux kernel's s390/ctcm mainframe network driver stems from a double-kfree: mpc_rcvd_sweep_req() frees the mpcginfo structure, then ctcmpc_unpack_skb() frees the same pointer again after the conditional call returns. Discovered via clang static analysis, it affects IBM Z (s390) systems using the CTCM MPC networking driver and could lead to kernel memory corruption, denial of service, or potentially escalation when a crafted MPC sweep-request frame is processed. There is no public exploit identified at time of analysis, EPSS risk is negligible (0.05%), and it is not listed in CISA KEV; the fix has shipped in stable kernel releases.
Local privilege-context memory corruption in the Linux kernel's GPIO character device (gpio cdev) subsystem allows a use-after-free on the file structure backing an open GPIO chardev descriptor. When a GPIO line-change event fires after the final fput() has dropped the fd's reference count to zero but before the deferred .release() callback unregisters the notifier, the kernel calls get_file() on a file with a zero refcount, triggering a use-after-free (warned as 'f_count incremented from zero; use-after-free condition present'). No public exploit has been identified at time of analysis and the EPSS score is negligible (0.03%), consistent with a hard-to-win local race rather than a widely exploited flaw.
Local privilege-escalation-grade memory corruption in the Linux kernel's AF_VSOCK (virtio/vhost vsock) stack allows a local user to trigger a use-after-free or NULL-pointer dereference by racing a signal or timeout against an in-progress connect() on an already-established socket. Aborting the connect could tear down a connected socket while a concurrent sendmsg() or sockmap operation runs, corrupting credit accounting (bytes_unsent), breaking sockmap invariants, and enabling a transport change/drop after TCP_ESTABLISHED. No public exploit is identified at time of analysis and EPSS is 0.05%, but the flaw is patched across many stable branches and tracked by Ubuntu, Debian, and Siemens.
Memory-map miscalculation in the Linux kernel's nios2 architecture code allows local low-privileged users to trigger kernel paging failures and denial of service on affected nios2 (soft-core) systems built with CONFIG_FLATMEM. Because memblock.current_limit is left at its default MEMBLOCK_ALLOC_ANYWHERE when pfn limits are computed, max_low_pfn can exceed max_pfn and push mem_map beyond valid DRAM, producing 'Unable to handle kernel paging request' oopses and kernel panics. No public exploit identified at time of analysis; EPSS is 0.04% (11th percentile) and the flaw is not in CISA KEV.
Uninitialized-memory read in the Linux kernel's HFS+ filesystem driver (__hfsplus_ext_cache_extent) allows a local actor who can write to a mounted HFS+ volume to trigger use of uninitialized heap data, leading to information disclosure or a kernel crash. The flaw, found by syzbot via KMSAN on kernel 6.12-rc5, is fixed across multiple stable trees; there is no public exploit identified at time of analysis and EPSS exploitation probability is very low (0.04%, 11th percentile). Distributions including Ubuntu (USN-8029/8030/8033/8034) and Debian (DLA-4404-1) have shipped patches.
Uninitialized-memory (KMSAN uninit-value) defect in the Linux kernel HFS filesystem driver allows a local attacker who can mount or operate on a crafted HFS volume to corrupt on-disk allocation state and destabilize the filesystem. The bitmap buffer in hfs_mdb_get() was allocated with kmalloc() (leaving residual heap garbage) and later consumed by hfs_find_set_zero_bits() during block allocation, so non-zero uninitialized bits can drive incorrect bitmap decisions leading to volume corruption and driver misbehavior. Discovered by syzbot fuzzing; there is no public exploit identified at time of analysis and EPSS risk is very low (0.04%).
Kernel memory corruption in the Linux kernel's GFS2 clustered filesystem stems from a use-after-free race in gdlm_put_lock(), where a small window exists after the DFL_UNMOUNT flag is set but before the DLM lockspace is released. During that window the DLM callbacks gdlm_ast() and gdlm_bast() can still fire and dereference already-freed glock objects, potentially crashing the kernel or corrupting memory on systems using GFS2. The issue carries a CVSS 3.1 base score of 7.0 (AV:L/AC:H/PR:L), has an EPSS of only 0.03%, is not in CISA KEV, and has no public exploit identified at time of analysis; it is patched upstream and shipped by Ubuntu and Debian.
Denial of service in the Linux kernel SCTP subsystem allows remote attackers to crash affected systems via a NULL pointer dereference triggered when an SCTP chunk arrives without a data buffer. The flaw stems from dereferencing chunk->skb inside a code path that assumes it is NULL, and is fixed across multiple stable trees (5.4.301, 5.10.246, 5.15.196, 6.1.158, 6.6.115, 6.12.56, 6.17.6, 6.18). No public exploit identified at time of analysis, and EPSS probability is very low (0.04%, 11th percentile), indicating minimal real-world exploitation likelihood despite the network-reachable vector.
In the Linux kernel, the following vulnerability has been resolved: fs/notify: call exportfs_encode_fid with s_umount Calling intotify_show_fdinfo() on fd watching an overlayfs inode, while the overlayfs is being unmounted, can lead to dereferencing NULL ptr. This issue was found by syzkaller. Race Condition Diagram: Thread 1 Thread 2 -------- -------- generic_shutdown_super() shrink_dcache_for_umount sb->s_root = NULL | | vfs_read() | inotify_fdinfo() | * inode get from mark * | show_mark_fhandle(m, inode) | exportfs_encode_fid(inode, ..) | ovl_encode_fh(inode, ..) | ovl_check_encode_origin(inode) | * deref i_sb->s_root * | | v fsnotify_sb_delete(sb) Which then leads to: [ 32.133461] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 32.134438] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 32.135032] CPU: 1 UID: 0 PID: 4468 Comm: systemd-coredum Not tainted 6.17.0-rc6 #22 PREEMPT(none) <snip registers, unreliable trace> [ 32.143353] Call Trace: [ 32.143732] ovl_encode_fh+0xd5/0x170 [ 32.144031] exportfs_encode_inode_fh+0x12f/0x300 [ 32.144425] show_mark_fhandle+0xbe/0x1f0 [ 32.145805] inotify_fdinfo+0x226/0x2d0 [ 32.146442] inotify_show_fdinfo+0x1c5/0x350 [ 32.147168] seq_show+0x530/0x6f0 [ 32.147449] seq_read_iter+0x503/0x12a0 [ 32.148419] seq_read+0x31f/0x410 [ 32.150714] vfs_read+0x1f0/0x9e0 [ 32.152297] ksys_read+0x125/0x240 IOW ovl_check_encode_origin derefs inode->i_sb->s_root, after it was set to NULL in the unmount path. Fix it by protecting calling exportfs_encode_fid() from show_mark_fhandle() with s_umount lock. This form of fix was suggested by Amir in [1]. [1]: https://lore.kernel.org/all/CAOQ4uxhbDwhb+2Brs1UdkoF0a3NSdBAOQPNfEHjahrgoKJpLEw@mail.gmail.com/
In the Linux kernel, the following vulnerability has been resolved: virtio-net: zero unused hash fields When GSO tunnel is negotiated virtio_net_hdr_tnl_from_skb() tries to initialize the tunnel metadata but forget to zero unused rxhash fields. This may leak information to another side. Fixing this by zeroing the unused hash fields.
Stale extent-map cache handling in the Linux kernel's OCFS2 clustered filesystem lets a local, low-privileged user with access to an OCFS2 mount crash the kernel and read or corrupt on-disk extent data. After a reflinked (OCFS2_EXT_REFCOUNTED) extent is moved or defragmented, the in-memory extent cache retains stale flags while the disk holds updated ones; a subsequent write hits a BUG_ON in ocfs2_refcount_cal_cow_clusters(), producing a panic (denial of service) and potential data/integrity impact. There is no public exploit identified at time of analysis, and EPSS is very low (0.05%, 16th percentile), consistent with a niche, non-KEV local kernel bug rather than a mass-exploited flaw.
In the Linux kernel, the following vulnerability has been resolved: vsock: fix lock inversion in vsock_assign_transport() Syzbot reported a potential lock inversion deadlock between vsock_register_mutex and sk_lock-AF_VSOCK when vsock_linger() is called. The issue was introduced by commit 687aa0c5581b ("vsock: Fix transport_* TOCTOU") which added vsock_register_mutex locking in vsock_assign_transport() around the transport->release() call, that can call vsock_linger(). vsock_assign_transport() can be called with sk_lock held. vsock_linger() calls sk_wait_event() that temporarily releases and re-acquires sk_lock. During this window, if another thread hold vsock_register_mutex while trying to acquire sk_lock, a circular dependency is created. Fix this by releasing vsock_register_mutex before calling transport->release() and vsock_deassign_transport(). This is safe because we don't need to hold vsock_register_mutex while releasing the old transport, and we ensure the new transport won't disappear by obtaining a module reference first via try_module_get().
In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: fix potential memory leak by cleaning ops_filter in damon_destroy_scheme Currently, damon_destroy_scheme() only cleans up the filter list but leaves ops_filter untouched, which could lead to memory leaks when a scheme is destroyed. This patch ensures both filter and ops_filter are properly freed in damon_destroy_scheme(), preventing potential memory leaks.
In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs: catch commit test ctx alloc failure Patch series "mm/damon/sysfs: fix commit test damon_ctx [de]allocation". DAMON sysfs interface dynamically allocates and uses a damon_ctx object for testing if given inputs for online DAMON parameters update is valid. The object is being used without an allocation failure check, and leaked when the test succeeds. Fix the two bugs. This patch (of 2): The damon_ctx for testing online DAMON parameters commit inputs is used without its allocation failure check. This could result in an invalid memory access. Fix it by directly returning an error when the allocation failed.
In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs: dealloc commit test ctx always The damon_ctx for testing online DAMON parameters commit inputs is deallocated only when the test fails. This means memory is leaked for every successful online DAMON parameters commit. Fix the leak by always deallocating it.
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Account for failed debug initialization When the SCMI debug subsystem fails to initialize, the related debug root will be missing, and the underlying descriptor will be NULL. Handle this fault condition in the SCMI debug helpers that maintain metrics counters.
In the Linux kernel, the following vulnerability has been resolved: most: usb: Fix use-after-free in hdm_disconnect hdm_disconnect() calls most_deregister_interface(), which eventually unregisters the MOST interface device with device_unregister(iface->dev). If that drops the last reference, the device core may call release_mdev() immediately while hdm_disconnect() is still executing. The old code also freed several mdev-owned allocations in hdm_disconnect() and then performed additional put_device() calls. Depending on refcount order, this could lead to use-after-free or double-free when release_mdev() ran (or when unregister paths also performed puts). Fix by moving the frees of mdev-owned allocations into release_mdev(), so they happen exactly once when the device is truly released, and by dropping the extra put_device() calls in hdm_disconnect() that are redundant after device_unregister() and most_deregister_interface(). This addresses the KASAN slab-use-after-free reported by syzbot in hdm_disconnect(). See report and stack traces in the bug link below.
In the Linux kernel, the following vulnerability has been resolved: tty: serial: sh-sci: fix RSCI FIFO overrun handling The receive error handling code is shared between RSCI and all other SCIF port types, but the RSCI overrun_reg is specified as a memory offset, while for other SCIF types it is an enum value used to index into the sci_port_params->regs array, as mentioned above the sci_serial_in() function. For RSCI, the overrun_reg is CSR (0x48), causing the sci_getreg() call inside the sci_handle_fifo_overrun() function to index outside the bounds of the regs array, which currently has a size of 20, as specified by SCI_NR_REGS. Because of this, we end up accessing memory outside of RSCI's rsci_port_params structure, which, when interpreted as a plat_sci_reg, happens to have a non-zero size, causing the following WARN when sci_serial_in() is called, as the accidental size does not match the supported register sizes. The existence of the overrun_reg needs to be checked because SCIx_SH3_SCIF_REGTYPE has overrun_reg set to SCLSR, but SCLSR is not present in the regs array. Avoid calling sci_getreg() for port types which don't use standard register handling. Use the ops->read_reg() and ops->write_reg() functions to properly read and write registers for RSCI, and change the type of the status variable to accommodate the 32-bit CSR register. sci_getreg() and sci_serial_in() are also called with overrun_reg in the sci_mpxed_interrupt() interrupt handler, but that code path is not used for RSCI, as it does not have a muxed interrupt. ------------[ cut here ]------------ Invalid register access WARNING: CPU: 0 PID: 0 at drivers/tty/serial/sh-sci.c:522 sci_serial_in+0x38/0xac Modules linked in: renesas_usbhs at24 rzt2h_adc industrialio_adc sha256 cfg80211 bluetooth ecdh_generic ecc rfkill fuse drm backlight ipv6 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.17.0-rc1+ #30 PREEMPT Hardware name: Renesas RZ/T2H EVK Board based on r9a09g077m44 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : sci_serial_in+0x38/0xac lr : sci_serial_in+0x38/0xac sp : ffff800080003e80 x29: ffff800080003e80 x28: ffff800082195b80 x27: 000000000000000d x26: ffff8000821956d0 x25: 0000000000000000 x24: ffff800082195b80 x23: ffff000180e0d800 x22: 0000000000000010 x21: 0000000000000000 x20: 0000000000000010 x19: ffff000180e72000 x18: 000000000000000a x17: ffff8002bcee7000 x16: ffff800080000000 x15: 0720072007200720 x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720 x11: 0000000000000058 x10: 0000000000000018 x9 : ffff8000821a6a48 x8 : 0000000000057fa8 x7 : 0000000000000406 x6 : ffff8000821fea48 x5 : ffff00033ef88408 x4 : ffff8002bcee7000 x3 : ffff800082195b80 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800082195b80 Call trace: sci_serial_in+0x38/0xac (P) sci_handle_fifo_overrun.isra.0+0x70/0x134 sci_er_interrupt+0x50/0x39c __handle_irq_event_percpu+0x48/0x140 handle_irq_event+0x44/0xb0 handle_fasteoi_irq+0xf4/0x1a0 handle_irq_desc+0x34/0x58 generic_handle_domain_irq+0x1c/0x28 gic_handle_irq+0x4c/0x140 call_on_irq_stack+0x30/0x48 do_interrupt_handler+0x80/0x84 el1_interrupt+0x34/0x68 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 default_idle_call+0x28/0x58 (P) do_idle+0x1f8/0x250 cpu_startup_entry+0x34/0x3c rest_init+0xd8/0xe0 console_on_rootfs+0x0/0x6c __primary_switched+0x88/0x90 ---[ end trace 0000000000000000 ]---
Rejected reason: ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. No vendor patch available.
An issue was discovered on Thermo Fisher Ion Torrent OneTouch 2 INS1005527 devices. When they are powered on, an X11 display server is started. The display server listens on all network interfaces and is accessible over port 6000. The X11 access control list, by default, allows connections from 127.0.0.1 and 192.168.2.15. If a device is powered on and later connected to a network with DHCP, the device may not be assigned the 192.168.2.15 IP address, leaving the display server accessible by other devices on the network. The exposed X11 display server can then be used to gain root privileges and the ability to execute code remotely by interacting with matchbox-desktop and spawning a terminal. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.
A remote code execution vulnerability in Thermo Fisher Torrent Suite Django application 5.18.1 (CVSS 9.8). Critical severity with potential for significant impact on affected systems.
In the Linux kernel, the following vulnerability has been resolved: media: pci: mg4b: fix uninitialized iio scan data Fix potential leak of uninitialized stack data to userspace by ensuring that the `scan` structure is zeroed before use.
In the Linux kernel, the following vulnerability has been resolved: fuse: fix livelock in synchronous file put from fuseblk workers I observed a hang when running generic/323 against a fuseblk server. This test opens a file, initiates a lot of AIO writes to that file descriptor, and closes the file descriptor before the writes complete. Unsurprisingly, the AIO exerciser threads are mostly stuck waiting for responses from the fuseblk server: # cat /proc/372265/task/372313/stack [<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_do_getattr+0xfc/0x1f0 [fuse] [<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse] [<0>] aio_read+0x130/0x1e0 [<0>] io_submit_one+0x542/0x860 [<0>] __x64_sys_io_submit+0x98/0x1a0 [<0>] do_syscall_64+0x37/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 But the /weird/ part is that the fuseblk server threads are waiting for responses from itself: # cat /proc/372210/task/372232/stack [<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_file_put+0x9a/0xd0 [fuse] [<0>] fuse_release+0x36/0x50 [fuse] [<0>] __fput+0xec/0x2b0 [<0>] task_work_run+0x55/0x90 [<0>] syscall_exit_to_user_mode+0xe9/0x100 [<0>] do_syscall_64+0x43/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 The fuseblk server is fuse2fs so there's nothing all that exciting in the server itself. So why is the fuse server calling fuse_file_put? The commit message for the fstest sheds some light on that: "By closing the file descriptor before calling io_destroy, you pretty much guarantee that the last put on the ioctx will be done in interrupt context (during I/O completion). Aha. AIO fgets a new struct file from the fd when it queues the ioctx. The completion of the FUSE_WRITE command from userspace causes the fuse server to call the AIO completion function. The completion puts the struct file, queuing a delayed fput to the fuse server task. When the fuse server task returns to userspace, it has to run the delayed fput, which in the case of a fuseblk server, it does synchronously. Sending the FUSE_RELEASE command sychronously from fuse server threads is a bad idea because a client program can initiate enough simultaneous AIOs such that all the fuse server threads end up in delayed_fput, and now there aren't any threads left to handle the queued fuse commands. Fix this by only using asynchronous fputs when closing files, and leave a comment explaining why.
In the Linux kernel, the following vulnerability has been resolved: PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV Before disabling SR-IOV via config space accesses to the parent PF, sriov_disable() first removes the PCI devices representing the VFs. Since commit 9d16947b7583 ("PCI: Add global pci_lock_rescan_remove()") such removal operations are serialized against concurrent remove and rescan using the pci_rescan_remove_lock. No such locking was ever added in sriov_disable() however. In particular when commit 18f9e9d150fc ("PCI/IOV: Factor out sriov_add_vfs()") factored out the PCI device removal into sriov_del_vfs() there was still no locking around the pci_iov_remove_virtfn() calls. On s390 the lack of serialization in sriov_disable() may cause double remove and list corruption with the below (amended) trace being observed: PSW: 0704c00180000000 0000000c914e4b38 (klist_put+56) GPRS: 000003800313fb48 0000000000000000 0000000100000001 0000000000000001 00000000f9b520a8 0000000000000000 0000000000002fbd 00000000f4cc9480 0000000000000001 0000000000000000 0000000000000000 0000000180692828 00000000818e8000 000003800313fe2c 000003800313fb20 000003800313fad8 #0 [3800313fb20] device_del at c9158ad5c #1 [3800313fb88] pci_remove_bus_device at c915105ba #2 [3800313fbd0] pci_iov_remove_virtfn at c9152f198 #3 [3800313fc28] zpci_iov_remove_virtfn at c90fb67c0 #4 [3800313fc60] zpci_bus_remove_device at c90fb6104 #5 [3800313fca0] __zpci_event_availability at c90fb3dca #6 [3800313fd08] chsc_process_sei_nt0 at c918fe4a2 #7 [3800313fd60] crw_collect_info at c91905822 #8 [3800313fe10] kthread at c90feb390 #9 [3800313fe68] __ret_from_fork at c90f6aa64 #10 [3800313fe98] ret_from_fork at c9194f3f2. This is because in addition to sriov_disable() removing the VFs, the platform also generates hot-unplug events for the VFs. This being the reverse operation to the hotplug events generated by sriov_enable() and handled via pdev->no_vf_scan. And while the event processing takes pci_rescan_remove_lock and checks whether the struct pci_dev still exists, the lack of synchronization makes this checking racy. Other races may also be possible of course though given that this lack of locking persisted so long observable races seem very rare. Even on s390 the list corruption was only observed with certain devices since the platform events are only triggered by config accesses after the removal, so as long as the removal finished synchronously they would not race. Either way the locking is missing so fix this by adding it to the sriov_del_vfs() helper. Just like PCI rescan-remove, locking is also missing in sriov_add_vfs() including for the error case where pci_stop_and_remove_bus_device() is called without the PCI rescan-remove lock being held. Even in the non-error case, adding new PCI devices and buses should be serialized via the PCI rescan-remove lock. Add the necessary locking.
In the Linux kernel, the following vulnerability has been resolved: pidfs: validate extensible ioctls Validate extensible ioctls stricter than we do now.
Local privilege-relevant memory corruption in the Linux kernel's io_uring resource (rsrc) subsystem stems from faulty offset arithmetic when computing the first page of a coalesced folio from an unaligned user virtual address, allowing a local low-privileged user submitting io_uring requests to trigger out-of-bounds access with high confidentiality, integrity, and availability impact. Fixed upstream and backported to stable trees (6.12.36, 6.15.5, 6.16); no public exploit identified at time of analysis and EPSS exploitation probability is very low (0.03%, 6th percentile). Not listed in CISA KEV.
Improper control of dynamically-managed code resources vulnerability in WebAPI component in Synology DiskStation Manager (DSM) before 7.1.1-42962-8 and 7.2.1-69057-2 and 7.2.2-72806 and Synology Unified Controller (DSMUC) before 3.1.4-23079 allows remote authenticated users to obtain privileges without consent via unspecified vectors.