Information Disclosure

OAuth token refresh in hex.pm (Elixir's package registry) fails to re-validate organizational membership when issuing new access tokens, allowing users removed from a private organization to retain read access to its packages. Affected are hex.pm deployments from 2025-10-10 through 2026-08-24. An authenticated former member can repeatedly refresh a token carrying an explicit repository:<org> or docs:<org> scope - bypassing revocation entirely for up to 30 days - because CDN edges authorize access from token claims without querying the database. No public exploit exists and this is not in CISA KEV.

Arbitrary file write in Dell Client BIOS affects multiple Alienware, Inspiron, and XPS systems through a link-following flaw (CWE-379) exploitable by a low-privileged local attacker. The vulnerability allows the BIOS update or management process to follow attacker-planted symlinks in temporary directories, redirecting privileged file writes to arbitrary filesystem locations - enabling integrity compromise or availability impact at the OS level. No public exploit identified at time of analysis and no CISA KEV listing; however, patch versions are confirmed via Dell advisory DSA-2026-280.

Intercepted VNC sessions in Devolutions Remote Desktop Manager are possible because the IronVNC client automatically accepts the server's RSA key without verification during RSA-AES authentication, leaving an on-path attacker able to substitute their own key and relay tampered traffic. Both the 2026.2.x branch (up to 2026.2.17.0) and the 2026.1.x branch (up to 2026.1.24.0) are affected. No public exploit exists and EPSS sits at 0.11% (1st percentile), but the attack requires only network positioning and a user-initiated VNC session, making it a realistic threat on untrusted or adversary-adjacent networks.

Stack exhaustion and a bounded memory over-read in GIMP's file-pix (ESM) plugin allow a crafted PIX image to crash the application and leak 21 bytes of stack memory into an intermediate file. Users running GIMP on Red Hat Enterprise Linux 6 through 9 are affected when opening untrusted PIX format images. No public exploit code and no active exploitation (CISA KEV) have been identified at time of analysis, though the DoS impact is reliable and the delivery vector - a malicious image file - is realistic for desktop users.

Zephyr RTOS's Hearing Access Service (HAS) GATT peripheral crashes when a previously bonded Bluetooth peer reconnects during a boot-time race window before bt_has_register() completes service initialization. The security_changed() callback - registered unconditionally via BT_CONN_CB_DEFINE - fires against NULL attribute pointers, triggering either a kernel assertion or a NULL dereference in bt_gatt_is_subscribed(). With CVSS AV:A/AC:H and confirmed DoS-only impact, this represents a medium-severity availability risk against embedded hearing-aid devices running Zephyr 3.6.0 through 4.4.1; no public exploit code has been identified, and a vendor patch is confirmed at 4.4.2.

Unauthenticated REST API disclosure in Apache Allura through version 1.19.1 exposes certain content items to unauthorized actors without any credentials. The vulnerability stems from insufficient access control on REST endpoints, allowing any network-accessible client to retrieve content that should require authentication. No public exploit or CISA KEV listing has been identified at time of analysis, but the low exploitation barrier (unauthenticated, network-accessible) makes this a straightforward information leakage risk for any publicly exposed Allura instance.

Stored cross-site scripting in the contacts component of NethServer's WebTop groupware module allows an authenticated attacker to inject persistent JavaScript into shared address book fields, which executes silently in any victim's browser upon viewing the poisoned contact record. All WebTop installations on version 1.5.6 and earlier are at risk; successful exploitation can cascade into session hijacking, credential theft, and unauthorized access across all integrated groupware services including email and file storage. No public exploit has been identified at time of analysis, though the stored XSS class requires minimal technical sophistication once an attacker holds a low-privilege account.

Zephyr RTOS versions 4.3.0 through 4.4.1 leak 8 bytes of uninitialised kernel stack memory per MIDI 2.0 discovery request through the UMP Stream responder library. Two reply-packet builder functions declare their result struct without zero-initialisation, causing stale stack contents in the trailing two 32-bit words to be transmitted verbatim over the wire. The default unauthenticated Network MIDI 2.0 UDP endpoint exposes this to any remote peer; the request is freely repeatable, enabling accumulation of stack disclosures. No public exploit has been identified at time of analysis, and KEV status is absent.

Redis glob pattern injection in Ransomlook versions up to and including 2.0.0 allows unauthenticated remote attackers to enumerate health data for all tracked groups and markets - including those flagged as private - by supplying glob metacharacters to the /api/health/<name> and /api/crypto/chain/<chain> endpoints. The vulnerability stems from unsanitized caller-supplied values being interpolated directly into Redis SCAN MATCH patterns, expanding scan scope beyond the intended target entity. No public exploit has been identified at time of analysis; a vendor-released fix is available via an upstream GitHub commit that introduces centralized glob escaping across all affected code paths.

Symlink-following during ZIP extraction in adm-zip 0.5.9 through 0.6.0 allows a local attacker who can plant a symlink inside the extraction directory to overwrite arbitrary files accessible by the extracting process. Utils.writeFileTo calls fs.openSync without O_NOFOLLOW and performs no pre-write lstat check, so a pre-positioned symlink transparently redirects the write - and a subsequent chmod - to any target outside the extraction root without any path-traversal sequence appearing in the archive. No public exploit is identified at time of analysis and the vulnerability is not listed in CISA KEV, but the impact is high in shared or predictable extraction environments such as CI pipelines and multi-tenant temp directories.

HCL Hive exposes its Swagger API documentation publicly to unauthenticated users, revealing API endpoint structures, HTTP methods, request/response schemas, and operational surface without access controls. While no credentials or PII are directly disclosed per the vendor's assessment, the exposed documentation materially reduces the reconnaissance effort required for follow-on attacks against the API. No public exploit code exists and this vulnerability is not listed in the CISA KEV catalog, placing it in the lower-priority tier despite its network-accessible nature.

Improper certificate validation in JSS (Java Security Services) allows the JSSTrustManager class to accept CA certificates from the NSS database that lack TRUSTED_CA trust flags, meaning certificates never explicitly designated as trust anchors can still be used to anchor TLS chains. In non-default deployments where certificate revocation checking has been disabled, this creates a viable path for a man-in-the-middle attacker to forge certificates accepted by PKI client connections, with high confidentiality and low integrity impact. No public exploit has been identified at time of analysis, and the AC:H CVSS rating reflects the meaningful attack complexity - MITM positioning plus a specific non-default configuration must both be present.

Information disclosure in Murrelektronik Xelity industrial Ethernet switches allows unauthenticated network attackers to retrieve MAC addresses from the device when an administrator uses the 'Copy learned MAC Addresses' function. The application improperly exposes logged MAC address data via browser developer tools (CVSS 4.0: 5.3). No public exploit code has been identified, but the trivial attack path (opening developer tools) and network accessibility present a moderate risk to industrial facilities.

Prototype pollution in ractivejs/ractive through version 1.4.4 allows remote attackers to modify JavaScript Object.prototype attributes via the Ractive#set function's Keypath Handler component. A publicly available proof-of-concept exists (GitHub issue #3448), and the maintainers have not yet responded to the coordinated disclosure. No vendor-released patch is available at time of analysis, leaving all users of the 1.4.x branch exposed with no official remediation path.

Prototype pollution in alibaba-fusion/next (all versions through 1.27.34) allows remote unauthenticated attackers to inject arbitrary properties into Object.prototype by supplying crafted values to the locale argument processed by the deepMerge function inside ConfigProvider.getContextProps within the Dialog component. The attack is network-reachable with no authentication or user interaction required per the CVSS 4.0 vector, though real-world exploitation depends on attacker-controlled data reaching the locale prop. No patch has been released and the upstream GitHub issue was closed due to inactivity; no public exploit code or CISA KEV listing has been identified at time of analysis.

Prototype pollution in rexrainbow/phaser3-rex-notes up to version 1.80.17 allows remote authenticated attackers with low privileges to manipulate JavaScript object prototype attributes via a crafted key argument to the SetValue function in the BehaviorTree Blackboard Data Interface. Exploitation can result in low-level confidentiality disclosure, integrity modification, and availability disruption, consistent with classic prototype pollution impact on downstream object behavior. No public exploit code has been confirmed at time of analysis, and this vulnerability is not listed in the CISA KEV catalog.

Prototype pollution in jQWidgets up to version 24.0.1 allows remote unauthenticated attackers to manipulate JavaScript object prototypes via the `JQXLite.extend` and `jqxBaseFramework.extend` functions in `jqwidgets/jqx-all.js`. Successful exploitation can affect the confidentiality, integrity, and availability of any web application embedding this library. Critically, the vendor closed the tracking GitHub issue as 'not planned,' meaning no official patch exists or is expected, leaving all consumers permanently exposed without mitigation.

Out-of-bounds read in Open5GS 2.8.0 PCRF Rx AA-Request handler allows remote low-privileged attackers with Diameter Rx interface access to send crafted AA-Request messages containing null or incorrectly-sized Framed-IP-Address or Framed-IPv6-Prefix AVPs, triggering memory reads beyond allocated boundaries. The patch commit c18dc6938bf63cc7374315d3dca303d92066e746 adds missing null and length validation for both AVP types; a tagged release incorporating it has not been independently confirmed. No active exploitation is recorded in CISA KEV, though the CVSS 4.0 E:P flag indicates proof-of-concept code is known to exist.

Out-of-bounds memory corruption in SpaceDot AcubeSAT On-Board Computer software's CAN message parsing crashes the system when processing malformed ECSS telecommand packet headers. The vulnerable component MessageParser::parseECSSTCHeader at commit eaf90ec performs insufficient bounds checking, enabling denial-of-service against the spacecraft's onboard computer via a crafted CAN message. No active exploitation has been confirmed; an EPSS of 0.15% (4th percentile) is consistent with the highly specialized and niche deployment context of this aerospace platform.

Server-side template injection (SSTI) via the FreeMarker engine in Dromara UJCMS 10.1.0 through 10.1.3 allows authenticated backend administrators to inject malicious template directives through the web-file-template update API endpoint. Exploitation requires high-privilege backend credentials but is network-reachable with no user interaction, and a public proof-of-concept exploit has been published on GitHub demonstrating the attack path. The vendor-scored CVSS 4.0 impact is rated low across confidentiality, integrity, and availability, though the FreeMarker SSTI class is capable of full JVM-level code execution if template sandboxing is absent or misconfigured - defenders should not assume the impact ceiling matches the reported score.

HTTP request smuggling in the Perl CPAN module Reverse::Proxy (versions before 0.04) allows unauthenticated remote attackers to inject arbitrary HTTP requests to upstream servers by embedding CRLF sequences in percent-encoded URL paths. The PSGI specification requires servers to percent-decode PATH_INFO before handing it to the application, meaning %0d%0a has already become a literal carriage return and line feed by the time the proxy appends it to the upstream request line - terminating that line early and promoting everything that follows to a second, attacker-controlled request. The injected request is attributed to the proxy by the upstream and can reach internal paths the proxy's own routing never exposes; on pooled keep-alive connections it may be delivered in the context of another client's session. No public exploit code and no CISA KEV listing exist at time of analysis.

Unauthenticated remote access to the cookies.txt file in MeTube (versions up to 2026.06.10) exposes yt-dlp session cookies via a direct HTTP request to the predictable path /download/.metube/cookies.txt. Any remote actor who can reach the MeTube instance can retrieve cookies potentially authenticating to YouTube or other streaming platforms, enabling session hijacking on those services. A public exploit has been disclosed; upgrading to version 2026.06.20 resolves the issue.

Out-of-bounds read in S2OPC's AddNodes service allows remote attackers to trigger memory read violations via a crafted UserAccessLevel argument, causing low-severity availability impact on vulnerable server instances running version 1.7.3 and earlier. The flaw resides in SOPC_NodeMgtHelperInternal_AddVariableNodeAttributes within the address space management layer of this OPC UA stack, which is deployed primarily in industrial automation and ICS/SCADA environments. A public proof-of-concept exploit has been disclosed, though high attack complexity (AC:H) limits opportunistic exploitation; no public exploit identified at time of analysis as a KEV-confirmed active threat.

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix memory leak in btrfs_do_encoded_write() Local fuzzing of 6.12.94 has found the following memory leak: Unreferenced object 0xffff888018050a80 (size 64): comm "syz.0.17", pid 10297, jiffies 4294953601 hex dump (first 32 bytes): 00 10 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ 10 0a 05 18 80 88 ff ff 10 0a 05 18 80 88 ff ff ................ backtrace (crc a8a6fc29): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] extent_changeset_alloc fs/btrfs/extent_io.h:207 [inline] qgroup_reserve_data+0x1c5/0x7d0 fs/btrfs/qgroup.c:4305 btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c:4355 btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c:9746 btrfs_encoded_write fs/btrfs/file.c:1482 [inline] btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c:1507 btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c:4738 btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c:-1 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:47 [inline] do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Unreferenced object 0xffff888018050a00 (size 64): comm "syz.0.17", pid 10297, jiffies 4294953601 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 ff 0f 00 00 00 00 00 00 ................ 90 0a 05 18 80 88 ff ff 90 0a 05 18 80 88 ff ff ................ backtrace (crc cb5c9580): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] ulist_prealloc+0x9c/0x110 fs/btrfs/ulist.c:114 extent_changeset_prealloc fs/btrfs/extent_io.h:217 [inline] __set_extent_bit+0x16b/0x1a70 fs/btrfs/extent-io-tree.c:1086 set_record_extent_bits+0x50/0x90 fs/btrfs/extent-io-tree.c:1821 qgroup_reserve_data+0x274/0x7d0 fs/btrfs/qgroup.c:4312 btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c:4355 btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c:9746 btrfs_encoded_write fs/btrfs/file.c:1482 [inline] btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c:1507 btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c:4738 btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c:-1 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:47 [inline] do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by freeing an extent changeset before returning from btrfs_do_encoded_write().

In the Linux kernel, the following vulnerability has been resolved: net/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in smc_llc_event_handler() The SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT branch in smc_llc_event_handler() stores an incoming qentry into the local LLC flow without first checking whether a qentry is already pending. If a malicious or buggy peer sends a second CONFIRM_LINK or ADD_LINK_CONT request while a flow is active and flow->qentry is already set, smc_llc_flow_qentry_set() overwrites the pointer without freeing the previous allocation, leaking one kmalloc-96 object per spurious message. The sibling SMC_LLC_DELETE_LINK branch already has the correct !flow->qentry guard. Apply the same guard to the CONFIRM_LINK/ADD_LINK_CONT branch so that a duplicate message when qentry is already occupied falls through to break and is freed by the kfree(qentry) at the out: label, rather than silently leaking the existing allocation. The response direction (smc_llc_rx_response()) is unaffected: it already guards with flow->qentry at the equivalent site and drops duplicate responses correctly.

In the Linux kernel, the following vulnerability has been resolved: devlink: fix net namespace reference leak in reload devlink_nl_reload_doit() calls devlink_netns_get(), which returns a net with a held reference. When the requested namespace differs from the current one and the reload action is not DRIVER_REINIT, the function returns -EOPNOTSUPP without releasing the reference. Add the missing put_net() on this error path.

In the Linux kernel, the following vulnerability has been resolved: xsk: clear metadata pointer when no timestamp is requested User space can change metadata flags after request processing. Rereading them during completion can therefore make the kernel write a timestamp that was not requested when the packet was submitted. Clear the metadata pointer during request processing unless timestamp completion is requested. Completion handling can then use the pointer itself instead of rereading the flags. On the mlx5 multi-packet WQE path metadata is evaluated per batch: xsk_tx_metadata_request() runs only for the descriptor that starts a session, just like the checksum offload that is applied once through the shared WQE. Only that descriptor's pointer is reset, so completion handling can record a timestamp for the other descriptors of the session regardless of their own XDP_TXMD_FLAGS_TIMESTAMP bit. The write stays inside the metadata area; the single-WQE, other zero-copy, and generic paths reset the pointer per descriptor and are unaffected.

In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix memory leak in exec_queue_set_hang_replay_state() The q->replay_state is blindly overwritten, which can potentially leak memory that was previously allocated by vmemdup_user(). Return an error if q->replay_state is not empty. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit f6b6cc1118bdbc4265fa8b3bdf8565b26f13e56e)

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: fix BQL reset on SQ re-activation mlx5e_queue_start() deactivates and re-activates all channels but closes only the queue being restarted. mlx5e_activate_txqsq() then unconditionally calls netdev_tx_reset_queue(), zeroing the BQL counters of channels that kept their in-flight TX WQEs. The next completion then over-charges and trips the BUG_ON() in dql_completed(): kernel BUG at lib/dynamic_queue_limits.c:99! RIP: 0010:dql_completed+0x23d/0x280 Call Trace: <IRQ> mlx5e_poll_tx_cq+0x668/0xa60 mlx5e_napi_poll+0x5b/0x7b0 net_rx_action+0x15a/0x580 Reset BQL only when the SQ has no bytes in flight (sq->cc == sq->pc). In the case that reset is skipped, the outstanding WQEs will eventually complete and rebalance the dql. The dql->limit is carried across the reset.

In the Linux kernel, the following vulnerability has been resolved: net/ncsi: fix heap OOB read in NCSI_CMD_SEND_CMD payload length ncsi_send_cmd_nl() takes the number of bytes to copy from the attacker-controlled ncsi_pkt_hdr.length field of the in-band packet header, while the source buffer is the NCSI_ATTR_DATA netlink attribute whose readable size is nla_len() - sizeof(ncsi_pkt_hdr). The two length sources are never cross-checked: only nla_len() >= sizeof(struct ncsi_pkt_hdr) is enforced. With hdr->length set larger than the attribute payload (up to 65535 against at most 2032 readable bytes), ncsi_cmd_handler_oem() copies past the end of the netlink attribute buffer with unsafe_memcpy(), leaking up to ~64KB of kernel heap memory into the transmitted NCSI command packet. The destination skb is sized by the declared payload, so the write side does not overflow - this is a pure OOB read / information leak, reachable with CAP_NET_ADMIN on systems with a registered NCSI device (e.g. OpenBMC on Aspeed BMC SoCs, where NET_NCSI=y is standard). Reject commands whose declared payload extends past the end of the data attribute. The issue was found by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab.

In the Linux kernel, the following vulnerability has been resolved: net: prestera: validate firmware header length prestera_fw_hdr_parse() reads the firmware header before checking that the firmware image contains that header. Reject images shorter than struct prestera_fw_header before decoding the magic and version fields.

In the Linux kernel, the following vulnerability has been resolved: rqspinlock: Reset tail when preserving queue on deadlock Currently, the destruction of the waiter queue is suppressed for rqspinlock in cases where a deadlock is detected. Deadlock checks happen relatively frequently (on entry for AA, within 1ms for ABBA), and waiter threads may not be involved in locking scenarios involving deadlocks. Thus, it is useful to not flush the queue and let other waiters take a stab at acquiring the lock after we detect a deadlock and exit. However, we need to follow the same logic as what we did previously for the waitq_timeout label: reset the tail, and if we cannot, signal the next waiter appropriately. In case of deadlocks, this signal would just mark the MCS node as unlocked, and in case of timeouts, it would signal RES_TIMEOUT_VAL. The difference thus is in the value propagated, which decides whether the queue remains active or gets flushed. Not doing the tail reset, and waiting for the next waiter can lead to cases where we are the final waiter, and thus no next waiter arrives, leading to intermittent stalls in this path. Once the next waiter does join, we will be unblocked. In the theoretical case when the next waiter never joins, we risk stalling indefinitely. This can only happen for ABBA deadlocks, since entry into the wait queue is guarded with AA checks. A precise sequence of executions leading up to this scenario can be: CPU 0 holds lock A. CPU 1 holds lock B. CPU 2 attempts lock B, becomes the pending waiter for B. CPU 0 attempts lock B. B has locked+pending bits set, thus CPU 0 queues. CPU 1 attempts lock A. CPU 0 detects an ABBA deadlock. Once deadlock detection happens for CPU 0, it will sit waiting for the next waiter in the queue to populate node->next, which will experience delays until such a waiter arrives. Fix this by adjusting the logic for the check for deadlocks preceding the waitq_timeout label. It would make sense to consolidate code for both cases and use 'ret' to distinguish the value being propagated, but that is left as an exercise for a future refactoring task to avoid diff noise in this patch.

In the Linux kernel, the following vulnerability has been resolved: usb: misc: usbio: check ibuf_len against rxbuf_len in bulk msg ibuf_len is the bulk IN (receive) buffer size, but the EMSGSIZE check in usbio_bulk_msg() compares it against txbuf_len - the bulk OUT endpoint size. Both are taken independently from different endpoints in usbio_probe(), so the check is wrong when they differ. Use rxbuf_len for the IN direction. This matches the buffer that actually holds the response data.

In the Linux kernel, the following vulnerability has been resolved: usb: atm: cxacru: properly kill rcv_urb on error in cxacru_cm() If cxacru_cm() encounters an error while submitting or waiting for snd_urb, it aborts and returns the error without killing the already submitted rcv_urb. This leaves the rcv_urb active. When this happens during initialization (e.g., in cxacru_atm_start()), the driver may ignore the error and proceed to call cxacru_poll_status(), which invokes cxacru_cm() again. Attempting to submit the still-active rcv_urb triggers a warning in usb_submit_urb(): cxacru 1-1:1.0: send of cm 0x84 failed (-104) ATM dev 0: cxacru_atm_start: CHIP_ADSL_LINE_START returned -104 ------------[ cut here ]------------ URB ffff88812658d200 submitted while active WARNING: drivers/usb/core/urb.c:379 at usb_submit_urb+0x79/0x18b0 drivers/usb/core/urb.c:379 ... Call Trace: <TASK> cxacru_cm+0x21a/0xf10 drivers/usb/atm/cxacru.c:631 cxacru_cm_get_array drivers/usb/atm/cxacru.c:722 [inline] cxacru_poll_status+0x178/0x1110 drivers/usb/atm/cxacru.c:828 cxacru_atm_start+0x185/0x360 drivers/usb/atm/cxacru.c:814 usbatm_atm_init+0x144/0x3a0 drivers/usb/atm/usbatm.c:927 usbatm_usb_probe+0x15cb/0x1db0 drivers/usb/atm/usbatm.c:1178 cxacru_usb_probe+0x17f/0x220 drivers/usb/atm/cxacru.c:1370 ... To fix this, ensure that rcv_urb is properly killed if cxacru_cm() aborts early. We can safely call usb_kill_urb() on rcv_urb in the error path, as it is safe to call even if the URB is not active (e.g., if it failed to submit in the first place, or if it already completed).

In the Linux kernel, the following vulnerability has been resolved: net: usb: ipheth: fix carrier_work UAF on disconnect ipheth_sndbulk_callback() re-arms the carrier-check work on any non-zero URB status: else schedule_delayed_work(&dev->carrier_work, 0); Nothing ties that to the interface being up, so the work can be armed again after ipheth_close() has already drained it, and stay armed until the netdev whose private area embeds it is freed. On unplug with a TX URB in flight, ipheth_disconnect() drains the work through unregister_netdev() -> ipheth_close() -> cancel_delayed_work_sync() and only then calls ipheth_kill_urbs(). usb_kill_urb() completes the in-flight TX URB with -ENOENT, so ipheth_sndbulk_callback() runs after the drain and re-arms carrier_work. The same completion also re-arms the work if the interface is only brought down while a TX URB is in flight, and ipheth_carrier_check_work() then keeps re-queueing itself once a second. unregister_netdev() does not call ipheth_close() for an already-down interface, so nothing drains it on the later unplug either. In both cases free_netdev() frees the netdev while carrier_work is still pending, and ipheth_carrier_check_work() dereferences freed memory. Tie the work to the interface state instead of chasing the completion: disable it in ipheth_close() and enable it in ipheth_open(), so a schedule_delayed_work() from the URB completion is a no-op whenever the interface is not up. disable_delayed_work_sync() also waits for a running instance, so it fully replaces the cancel_delayed_work_sync() it takes the place of. The work starts out disabled in ipheth_probe() so the enable/disable counts balance from the first open. Reproduced under KASAN on linux-next (next-20260731) with dummy_hcd and raw-gadget standing in for the device, driving the second path above (the interface is already down, so unregister_netdev() does not call ipheth_close()): 15 of 15 unpatched boots report a slab-use-after-free in __run_timers(), freed by ipheth_disconnect() and re-armed from ipheth_sndbulk_callback() via queue_delayed_work_on(). The same trigger on a kernel differing only by this patch reports 0 of 15, and the carrier check still functions across open/close cycles. The reproducer needs an attached USB device that stops draining bulk OUT, plus a link down and unplug, driven as root. It is not a privilege boundary crossing and no exploit primitive was developed. Found by 0sec (https://0sec.ai).

In the Linux kernel, the following vulnerability has been resolved: vt: add permission check for KDSKBMETA ioctl KDSKBMETA modifies keyboard meta mode but lacks the !perm check that all other keyboard setter ioctls in vt_k_ioctl() enforce, allowing a process to change meta mode on a non-controlling console without authorization.

In the Linux kernel, the following vulnerability has been resolved: Input: evdev - fix information leak in evdev_pass_values() In evdev_pass_values(), the input_event structure is allocated on the kernel stack and populated field-by-field. However, it is never fully initialized. On architectures where struct input_event contains explicit or implicit padding (such as the 32-bit __pad field on SPARC64), these padding bytes are left uninitialized. When this event structure is subsequently passed to the client buffer and later copied to userspace, the uninitialized padding bytes leak kernel stack memory, potentially exposing sensitive information. Similar issues exist in __evdev_queue_syn_dropped and __pass_event. Fix this by explicitly zeroing the entire event structure with memset() before populating its fields. This ensures all padding bytes are cleared before the data crosses the security boundary.

In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: reallocate update replies for mismatched IDs ovs_flow_cmd_new() preallocates the optional reply skb before it takes ovs_mutex and before it knows which existing flow will be updated. That is normally fine because the skb is sized from the request flow identifier. That identifier also becomes the inserted flow's identifier. For updates, however, a request with a UFID may miss the UFID lookup and then fall back to the flow key lookup. That lookup can legitimately find an existing key-identified flow. UFIDs are optional and the flow key is the primary identifier. For echoed replies, ovs_flow_cmd_fill_info() writes the matched flow's identifier, not the request identifier used for the preallocation. A short request UFID can therefore leave too little room for the key identifier. The fill can then fail with -EMSGSIZE and hit the BUG_ON(error < 0) in the update path. Once the update target has been resolved, reallocate the reply skb if the matched flow needs a larger reply than the request identifier allowed. Do this before replacing the actions so the request can still fail cleanly if the rare extra allocation fails.

In the Linux kernel, the following vulnerability has been resolved: net: bridge: mrp: fix uninitialised bytes on the wire br_mrp_alloc_test_skb() builds MRP test frames on an skb from dev_alloc_skb(), which does not clear the linear data area. On the MRA ring-role branch the sub-option TLV header is appended with sub_tlv = skb_put(skb, sizeof(*sub_tlv)); sub_tlv->type = BR_MRP_SUB_TLV_HEADER_TEST_AUTO_MGR; so sub_tlv->length is never written, and the two trailing alignment bytes are appended with a bare skb_put() that does not clear them either. The neighbouring oui and sub_opt regions are explicitly zeroed, so three uninitialised bytes are left in every MRA MRP_Test frame that goes out. Put the sub-option TLV header and the alignment padding in a single skb_put_zero(), which clears both. The AUTO_MGR sub-TLV carries no payload, so the zeroed length field is already the value it should have.

In the Linux kernel, the following vulnerability has been resolved: futex: Prevent robust futex exit race some more A robust futex unlock stores 0 over the whole futex value - wiping FUTEX_WAITERS - and wakes a single waiter. That wakeup is a one-shot notification: the protocol relies on its recipient to either acquire the futex (and eventually unlock while aware of the remaining contention) or re-arm FUTEX_WAITERS before sleeping again. If the woken waiter is killed before it can do either, the kernel must jump in and wake the next task down the line. This is a known complication of the futex protocol with a previous partial fix in commit ca16d5bee598 ("futex: Prevent robust futex exit race"). Unfortunately, that fix is insufficient. If a third task re-acquired the futex through the uncontended fast path in the meantime, the notification is lost: robust exit processing sees that it is owned by another task and does nothing, while the new owner sees no FUTEX_WAITERS when it unlocks and wakes nobody. The remaining waiters sleep forever behind a free futex: A owns the futex, B and C sleep in FUTEX_WAIT uval == A | FUTEX_WAITERS A robust unlock: store 0, FUTEX_WAKE(1) wakes B uval == 0 D fast path acquire: cmpxchg(0 -> D) uval == D, no FUTEX_WAITERS B killed before acting on the wakeup B exit walk, pending op: owner D != B -> no action D unlock: no FUTEX_WAITERS -> no wake C sleeps forever This is clearly a shortcoming in the implementation, which fails to keep the FUTEX_WAITERS bit consistent. Work around this by augmenting the robust list exit processing to also perform the extra wakeup if the futex word is owned by another thread but FUTEX_WAITERS is not set. This does not fix the problem of a non-contended take over/release and free sequence, which has been discussed for years and has been addressed by commit 3ca9595d9fb6 ("futex: Add support for unlocking robust futexes") and subsequent changes, but failed to take the problem described above into account. A more complete solution which is based on the in kernel unlock of contended robust futexes has been discussed in the context of this change and should show up in mainline sooner than later. [ tglx: Amend change log slightly and fixup coding style ]

In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix fib_nlmsg_size() for RTA_VIA nexthops fib_nlmsg_size() still estimates nexthop space as if every gateway is encoded as an IPv4 RTA_GATEWAY attribute. IPv4 routes can also carry an IPv6 gateway, which fib_nexthop_info() dumps as RTA_VIA. As a result, route notifications can allocate an skb that is too small. fib_dump_info() then fails with -EMSGSIZE and rtmsg_fib() hits the WARN_ON() that marks such failures as a fib_nlmsg_size() bug. With panic_on_warn set, this becomes a kernel panic. Mirror the actual nexthop dump layout in fib_nlmsg_size(): account for IPv6 nexthop gateways dumped as RTA_VIA, for the no-header rtnexthop layout used inside RTA_MULTIPATH, and for RTA_FLOW only when it is actually present.

In the Linux kernel, the following vulnerability has been resolved: serial: 8250_dma: Clear stale RX state on shutdown serial8250_release_dma() terminates RX DMA and releases the channel, but leaves rx_running set. If the port is closed while an RX transfer is active, the stale state remains while rxchan is NULL until the channel is requested again on the next open. The DesignWare BUSY workaround added by commit a7b9ce39fbe4 ("serial: 8250_dw: Ensure BUSY is deasserted") calls serial8250_rx_dma_flush() from the LCR write path during startup. This happens before serial8250_request_dma() obtains a new RX channel. On reopen, the stale rx_running state therefore makes the flush path pass a NULL channel to dmaengine_pause(), causing a kernel Oops. Clear rx_running after terminating RX DMA, matching the TX cleanup. Also make the flush helper return if the DMA object or RX channel is not available so startup and teardown paths cannot pass a NULL channel to the DMAengine API.

In the Linux kernel, the following vulnerability has been resolved: serial: 8250_of: clear stuck empty-FIFO RX-timeout on LPC32xx The NXP LPC32xx UART (PORT_LPC3220) can latch an RX character-timeout interrupt while the RX FIFO is empty: IIR reports UART_IIR_RX_TIMEOUT (0x0c) but LSR.DR is clear. A character timeout is only cleared by reading RHR, but serial8250_rx_chars() reads RHR only when LSR.DR is set, so nothing ever clears the condition. The interrupt is level-triggered and re-fires immediately, so on a single-core ARM926 the resulting interrupt storm livelocks the CPU. It is reproducible when userspace repeatedly opens the front-panel port (ttyS1): serial8250_do_set_termios() re-enables interrupts on unlock and the handler then spins forever with iir=0xcc lsr=0x60 ier=0x05, tripping the soft-lockup detector in serial8250_handle_irq_locked(). LPC32xx has no dedicated 8250 glue driver, it's driven by the generic 8250_of. Add a hardware specific handle_irq for PORT_LPC3220, wired up in of_platform_serial_setup() the same way fsl8250_handle_irq is installed. The handler follows dw8250_handle_irq(): on an RX timeout with an empty FIFO (LSR.DR and LSR.BI clear) it does one throwaway RHR read to clear the condition, then calls serial8250_handle_irq_locked(). No real received data is ever discarded, and it is a no-op on healthy UARTs which never report a timeout with DR clear. This is the same class of bug already worked around in other 8250 drivers; see commit 424d79183af0 ("serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt") which reports the identical iir=0xcc/lsr=0x60. See also UART_RX_TIMEOUT_QUIRK in 8250_omap, and the note in 8250_bcm7271.

In the Linux kernel, the following vulnerability has been resolved: mm/damon/lru_sort: error out for >10000 active_mem_bp damos_quota_score() can trigger division by zero if the target value is zero. DAMON_LRU_SORT lets users set the target value for the hot memory scheme via active_mem_bp parameter. It avoids setting it as the target value if the parameter value is zero. However, it also sets the cold memory scheme with a target value that is calculated as '10000 - active_mem_bp + 2'. Hence, if a user sets active_mem_bp 10002, the cold memory scheme's quota goal target value can be zero. As a result, division by zero can be triggered. Fix by returning an error when the user tries to start DAMON with >10000 active_mem_bp parameter value. It makes no sense to set active_mem_bp with 10002. It also requires module parameters write permission to reproduce the issue. That said, the consequence is quite bad. One reliable way to reproduce the issue is like below: # cd /sys/module/damon_lru_sort/parameters # echo 1000 > wmarks_high # echo 995 > wmarks_mid # echo 0 > wmarks_low # echo 10002 > active_mem_bp # echo Y > enabled # dmesg -w [...] [ 597.421247] Oops: divide error: 0000 [#1] SMP NOPTI [ 597.428848] RIP: 0010:damos_quota_score+0x6f/0x480 This issue was discovered [1] by Sashiko.

In the Linux kernel, the following vulnerability has been resolved: mm/damon/ops-common: putback folios on invalid migrate nid damon_pa_migrate() and damos_va_migrate() isolate folios into a local list and then call damon_migrate_pages(). When target_nid is invalid (including the scheme default NUMA_NO_NODE / -1), damon_migrate_pages() returns early without putting the folios back to the LRU. Callers then discard the list head while those folios remain isolated with an extra reference taken by folio_isolate_lru(). The pages stay off the LRU for as long as the mapping exists (anon active+inactive counts drop while RSS does not), and the leftover references can pin the pages after the mapping is gone. Put the folios back on the invalid-nid path so ignored migration requests still return them to the LRU.

In the Linux kernel, the following vulnerability has been resolved: samples/damon/mtier: error out for zero quota goal target values Patch series "mm/damon: avoid division by zero from damos_quota_score()". DAMON_SAMPLE_MTIER and DAMON_LRU_SORT allow the user to trigger division by zero in damos_quota_score(). Avoid it by adding parameters validation checks. This patch (of 2): damos_quota_score() can trigger division by zero if the target_value is zero. DAMON_SAMPLE_MTIER lets users set the target_value via node0_mem_{used,free}_bp parameters. It doesn't guard zero value case, though. As a result, users can trigger division by zero. Fix the issue by returning an error when the user tries to start DAMON with zero node0_mem_{used,free}_bp parameter values. DAMON_SAMPLE_MTIER is just a sample module, but the consequence is quite bad. Also the zero node0_mem_free_bp parameter might look like a reasonable setup to some users. Hence, the issue might really happen in the real world. One reliable way to reproduce the issue is like below: # cd /sys/module/damon_sample_mtier/parameters # echo 4096 > node0_start_addr # echo 8192 > node0_end_addr # echo 8192 > node1_start_addr # echo 81920 > node1_end_addr # echo 0 > node0_mem_free_bp # echo Y > enabled # dmesg -w [...] [18792.235916] Oops: divide error: 0000 [#1] SMP NOPTI [...] [18792.242787] RIP: 0010:damos_quota_score+0x6f/0x480 [...] This issue was discovered [1] by Sashiko.

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb: Fix UAF at delayed release of MIDI2 EPs The recent fix for UAF in ump_to_endpoint() caused another UAF because it tries to dereference the UMP endpoint object, but this might be executed at a delayed context where the endpoint has been already released. Add private_free to clear the associated data for avoiding the further dereference for delayed releases.

In the Linux kernel, the following vulnerability has been resolved: ALSA: us144mkii: re-anchor capture URBs on resubmission capture_urb_complete() resubmits each capture URB without anchoring it: usb_get_urb(urb); ret = usb_submit_urb(urb, GFP_ATOMIC); Anchoring is a property of a submission, not of the URB. The giveback path calls usb_unanchor_urb() before urb->complete(), so an URB resubmitted from its own completion handler is off the anchor. The capture URBs are anchored once, at stream start, so from the first completion onward tascam->capture_anchor is empty. tascam_free_urbs(), tascam_disconnect(), tascam_suspend() and the stop-work path all call usb_kill_anchored_urbs(&tascam->capture_anchor) to reap the capture URBs before anything is freed. With the anchor empty those calls return immediately and the URBs stay queued on the host controller. tascam_free_urbs() then returns the capture transfer buffers with usb_free_coherent(), and snd_card_free() releases the snd_card allocation that embeds tascam (card->private_data). The controller completes the queued URBs afterwards, writing device-supplied data into the freed transfer buffer, and capture_urb_complete() dereferences the freed driver object. KASAN on 7.2.0-rc5 (arm64): BUG: KASAN: slab-use-after-free in dummy_timer Write of size 512 at addr ffff000015b62000 __asan_memcpy dummy_timer hrtimer_run_softirq Allocated by task 64: usb_alloc_coherent tascam_alloc_urbs tascam_probe Freed by task 170: usb_free_coherent tascam_free_urbs tascam_disconnect usb_unbind_interface BUG: KASAN: slab-use-after-free in capture_urb_complete Read of size 4 at addr ffff0000170ee878 Freed by task 170: release_card_device snd_card_free tascam_disconnect Restore the usb_anchor_urb() between the reference count bump and the resubmission. That also makes the handler's usb_unanchor_urb() failure arm meaningful again and restores usb_kill_anchored_urbs() as a barrier on the disconnect, suspend and stop-work paths. The anchoring was removed on the premise that the URB is already anchored from the initial submission, which does not hold once the first giveback has run. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>

In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Serialize the scheduler timeout handlers V3D exposes several independent hardware queues (BIN, RENDER, TFU and CSD) but has only a single, global reset. A timeout on any one queue therefore has to stop, reset and restart the schedulers of every other queue as well. That makes concurrent timeout handlers unsafe. `reset_lock` was never able to make them safe, as a driver-side lock can only cover the driver's &drm_sched_backend_ops.timedout_job callback. The scheduler handles the timed out job and its pending list around that callback, outside of the driver's control, so a global reset triggered by one queue can still interfere with another queue that is in the middle of handling a timeout of its own. Consequently, if a reset happens in the CSD queue while a CL-intensive application is running, the global reset stops and restarts the CL queue's scheduler while that queue is handling a timeout of its own. As drm_sched_stop() and drm_sched_start() subtract and add the credits of every job sitting on the pending list of the scheduler they are called on, and as the CL queue's handler concurrently takes its job off that same list and puts it back, the stop and the start no longer see the same set of jobs. The CL queue is left with more credits in flight than its limit: [ 327.302739] ------------[ cut here ]------------ [ 327.302744] WARNING: CPU: 2 PID: 43 at drivers/gpu/drm/scheduler/sched_main.c:102 drm_sched_run_job_work+0x238/0x4d0 [gpu_sched] [ 327.302884] CPU: 2 UID: 0 PID: 43 Comm: kworker/u16:1 Not tainted 6.18.39-v8-16k+ #3 PREEMPT [ 327.302889] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) [ 327.302893] Workqueue: v3d_bin drm_sched_run_job_work [gpu_sched] [ 327.302984] Call trace: [ 327.302987] drm_sched_run_job_work+0x238/0x4d0 [gpu_sched] (P) [ 327.302997] process_scheduled_works+0x180/0x3d0 [ 327.303010] worker_thread+0x268/0x3e8 [ 327.303016] kthread+0x140/0x250 [ 327.303022] ret_from_fork+0x10/0x20 [ 327.303031] ---[ end trace 0000000000000000 ]--- From that point on, the credit count of the CL queue is broken, causing a complete GPU hang and UI freeze. The DRM scheduler already provides a mechanism to serialize the timeout handlers of different schedulers: an ordered workqueue passed as drm_sched_init()'s @timeout_wq parameter. By default, each scheduler queues its timeout work on the system workqueue, which runs the handlers concurrently. Give all of the queues a shared ordered workqueue instead, as recommended by the DRM scheduler documentation for hardware that has distinct queues but resets globally.

In the Linux kernel, the following vulnerability has been resolved: tracing: Fix race between update_event_fields and, event_define_fields The following sequence may leads race between event_define_fields() and update_event_fields(): CPU0 (loads module A) CPU1 (loads module B) =============================== =============================== load_module(A) load_module(B) notifier_call_chain notifier_call_chain trace_module_notify trace_module_notify mutex_lock(&event_mutex) trace_event_update_all() trace_module_add_events(A) down_write(&trace_event_sem) __register_event(call_A) __add_event_to_tracers(call_A) event_define_fields(call_A) for each f: list_for_each_entry(field, list_add(&f->link, &class->fields, link) &class->fields) field = class->fields->next; Where access to the class->fields is not protected by the event_mutex in trace_event_update_all(). This produces the following panic: Unable to handle kernel access ... at virtual address 0000000000000018 pc : update_event_fields+0xf8/0x368 Call trace: update_event_fields+0xf8/0x368 trace_event_update_all+0x7c/0x2b4 trace_module_notify+0x4c/0x1dc notifier_call_chain+0x84/0x168 blocking_notifier_call_chain_robust+0x64/0xd4 load_module+0x10c8/0x123c __arm64_sys_finit_module+0x230/0x31c Fix by taking event_mutex in trace_event_update_all() before trace_event_sem.

In the Linux kernel, the following vulnerability has been resolved: net: atlantic: free stranded TX buffers on ring deinit aq_vec_deinit() drains the TX rings with a single aq_ring_tx_clean() call, which frees at most AQ_CFG_TX_CLEAN_BUDGET (256) descriptors and stops at hw_head, which no longer moves once aq_vec_stop() has stopped the hardware and NAPI. Completed descriptors beyond the budget and everything still posted in [hw_head, sw_tail) keep their skb or xdp_frame when the interface goes down: aq_vec_ring_free() then frees the buffer ring and the references are lost for good. Today this is a silent memory leak on every interface down under TX/XDP_TX load. With the conversion of the RX path to page_pool posted for net-next it becomes much more visible: XDP_TX frames carry fragment references on the RX ring's page_pool, so a single stranded frame keeps the pool's inflight count above zero forever. page_pool_destroy() then never completes, the pool is leaked together with its pages, and "page_pool_release_retry() stalled pool shutdown" is warned every 60 seconds from that point on, on every ifdown, XDP detach or ring resize under XDP_TX load. Bring back aq_ring_tx_deinit() as it was before the removal and use it for teardown again, with one extension: TX rings can hold xdp_frames nowadays, so release those too. They are returned with xdp_return_frame() since this runs in process context.

In the Linux kernel, the following vulnerability has been resolved: net: atlantic: free RX pages of consumed but not refilled buffers aq_ring_rx_deinit() only walks [sw_head, sw_tail), the region posted to hardware. Since the page reuse strategy was added, a cleaned RX buffer keeps its page (and its DMA mapping) in the ring for reuse, and refill is batched: aq_ring_rx_fill() returns early until AQ_CFG_RX_REFILL_THRES slots are free. Slots that were consumed but not yet reposted therefore sit in the complementary [sw_tail, sw_head) gap with a live page, and the deinit walk never visits them: up to a refill batch worth of pages and DMA mappings leak on every interface down. Walk the whole ring instead and release whatever is still there. Also bail out if the buffer ring is already gone: a partial aq_ptp_ring_alloc() failure frees the ring but leaves aq_nic set, so aq_ptp_ring_deinit() still gets here on the unwind path.

In the Linux kernel, the following vulnerability has been resolved: net/sched: act_gact, act_police: range check the fallback control action tcf_action_check_ctrlact() range checks the primary control action: if (!opcode) ret = action > TC_ACT_VALUE_MAX ? -EINVAL : 0; TC_ACT_VALUE_MAX is TC_ACT_TRAP, so kernel-internal verdicts above it cannot be set that way. But act_gact and act_police each carry a second, independent control action supplied by user space that never reaches that helper - TCA_GACT_PROB.paction and TCA_POLICE_RESULT. Both only reject TC_ACT_GOTO_CHAIN, so any other value is stored verbatim and returned verbatim from the action. In particular user space can store TC_ACT_CONSUMED, which is TC_ACT_VALUE_MAX + 1 and is deliberately not part of the UAPI value range. That verdict tells every caller the action took ownership of the skb, so nobody frees it: sch_handle_ingress(), sch_handle_egress() and tcf_qevent_handle() all deliberately skip the free for it. The result is one leaked sk_buff plus its data buffer per packet traversing the filter, unbounded, for all traffic on the chain including kernel-generated packets. Both are trivially deterministic. act_gact clamps tcfg_pval to >= 1, so with pval = 1 gact_determ() returns the fallback for every packet. act_police has no mandatory rate, so rate = 0 leaves tcfp_mtu = ~0 and tcf_police_mtu_check() always passes. TC_ACT_CONSUMED was added by commit 720f22fed81b ("net: sched: refactor reinsert action"), after both goto-chain guards were written: commit 9469f375ab09 ("net/sched: act_gact: disallow 'goto chain' on fallback control action") and commit c08f5ed5d625 ("net/sched: act_police: disallow 'goto chain' on fallback control action"). Neither guard was widened when the new verdict appeared. Factor the existing range test out of tcf_action_check_ctrlact() as tcf_action_valid() and apply it to both fallbacks. The helper cannot call tcf_action_check_ctrlact() directly because that also allocates a goto_chain, which is exactly what these two sites must not do. Reproduced on v7.2-rc6: kmemleak reports one leaked 232-byte skbuff_head_cache object plus its 704-byte data buffer per packet. With this patch both configurations are rejected with -EINVAL and kmemleak reports none.

In the Linux kernel, the following vulnerability has been resolved: ovl: don't warn when the mount is completed from another user namespace fsopen() records the caller's user namespace in fc->user_ns and hands back an ordinary file descriptor. Nothing ties the task that calls fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The fd is inherited across fork() and exec() and it can be passed over a unix socket. Completing a context from another user namespace is allowed on purpose. vfs_cmd_create() authorizes the create with mount_capable(), which for FS_USERNS_MOUNT checks ns_capable(fc->user_ns, CAP_SYS_ADMIN), and that succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc->user_ns. So an unprivileged task can reach the WARN_ON() in ovl_fill_super(): create a user and a mount namespace in a child, call fsopen("overlay") there, send the fscontext fd to the parent and let the parent issue FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no capability is needed anywhere: WARNING: fs/overlayfs/super.c:1551 at ovl_fill_super+0x7b9/0x1e20 [overlay] CPU: 3 UID: 1000 PID: 3243376 Comm: fswarn Call Trace: get_tree_nodev+0x71/0xa0 ovl_get_tree+0x15/0x20 [overlay] vfs_get_tree+0x2a/0x100 vfs_cmd_create+0x60/0xf0 __do_sys_fsconfig+0x4b2/0x500 The child needs the mount namespace because fsopen() itself gates on may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning the caller's mount namespace. fsconfig() doesn't repeat that check. It is a WARN_ON() and not a WARN_ON_ONCE(), so the condition can be raised in a loop to taint the kernel and flood the log, and it panics a kernel booted with panic_on_warn. Keep refusing the mount and stop warning about it. ovl_parse_param() already spells a user namespace check this way for Opt_override_creds.

In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: don't warn when the mount is completed from another user namespace fsopen() records the caller's user namespace in fc->user_ns and hands back an ordinary file descriptor. Nothing ties the task that calls fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The fd is inherited across fork() and exec() and it can be passed over a unix socket. Completing a context from another user namespace is allowed on purpose. vfs_cmd_create() authorizes the create with mount_capable(), which for FS_USERNS_MOUNT checks ns_capable(fc->user_ns, CAP_SYS_ADMIN), and that succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc->user_ns. So an unprivileged task can reach the WARN_ON() in bm_fill_super(): create a user and a mount namespace in a child, call fsopen("binfmt_misc") there, send the fscontext fd to the parent and let the parent issue FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no capability is needed anywhere: WARNING: fs/binfmt_misc.c:938 at bm_fill_super+0xa2/0xc0 [binfmt_misc] CPU: 15 UID: 1000 PID: 3243382 Comm: fswarn Call Trace: get_tree_keyed+0x7d/0xb0 bm_get_tree+0x34/0x90 [binfmt_misc] vfs_get_tree+0x2a/0x100 vfs_cmd_create+0x60/0xf0 __do_sys_fsconfig+0x4b2/0x500 The child needs the mount namespace because fsopen() itself gates on may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning the caller's mount namespace. fsconfig() doesn't repeat that check. It is a WARN_ON() and not a WARN_ON_ONCE(), so the condition can be raised in a loop to taint the kernel and flood the log, and it panics a kernel booted with panic_on_warn. Keep refusing the mount and stop warning about it. Nothing in bm_fill_super() depends on the two namespaces matching, it derives everything from sb->s_user_ns.

In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Initialise reader page order in rb_allocate_cpu_buffer() In rb_allocate_cpu_buffer(), bpage->order was omitted, leaving it as 0. This is an issue for a ring-buffer with subbufs bigger than PAGE_SIZE if when freed: free_buffer_page() relies on this value. Align the value with the actual allocation size (buffer::subbuf_order).

In the Linux kernel, the following vulnerability has been resolved: fs,fsverity: remove check for fsverity being enabled in setattr_prepare() The check that fs-verity is available in the kernel is not necessary here. Filesystems could have fsverity files even without fs-verity enabled. In that case, truncate on fsverity file will succeed, what this check is trying to prevent.

In the Linux kernel, the following vulnerability has been resolved: sched_ext: Take cgroup_lock() first in scx_cgroup_lock() scx_cgroup_lock() write-locks scx_cgroup_ops_rwsem and then takes cgroup_lock(), which can deadlock through kernfs: scx enable/disable cgroup rmdir cpu.weight write ------------------ ------------ ---------------- cgroup_lock() percpu_down_write(rwsem) cgroup_lock() kernfs_get_active() percpu_down_read(rwsem) kernfs_drain() The enable path waits for the rmdir to release cgroup_mutex. The rmdir, deactivating the cpu controller's files, waits in kernfs_drain() for the write's active reference. The write, in scx_group_set_weight(), waits for the rwsem behind the pending writer. Take cgroup_lock() first. The set_* paths take no cgroup locks inside the read side, so a pending write-lock then only waits for read sections that always run to completion, and no dependency from the rwsem back to cgroup_mutex remains.

Plugin integrity bypass in SiYuan before v3.7.4 allows attackers with same-origin access to overwrite trusted, installed plugins by exploiting the bazaar install endpoint's failure to verify that the downloaded package content matches the caller-supplied packageName. By pairing a legitimate plugin's packageName with an attacker-controlled repoURL, an adversary substitutes malicious plugin code that persists across application restarts, achieving durable code execution within the SiYuan application context. No public exploit code or active exploitation has been identified at time of analysis, but the persistence mechanism elevates the practical impact beyond the moderate CVSS score.

Secret exfiltration via URL parameter interpolation in SiYuan's http_request MCP tool affects all versions before v3.8.0. An MCP client with elevated access can embed secret placeholder references directly in the destination URL of an http_request tool call, causing SiYuan to resolve and transmit stored plaintext secrets to any attacker-controlled host without user confirmation. No public exploit has been identified at time of analysis, but the exploitation mechanism is straightforward for any party holding MCP client access.

Email enumeration in AVideo's RSS feed endpoint (feed/index.php) allows unauthenticated remote attackers to harvest channel owner email addresses across all versions through commit 9c39d8c8. By iterating through public channel names, attackers can systematically extract creator PII from the itunes:email and itunes:author elements of the platform's podcast-compatible RSS output. No public exploit has been identified at time of analysis, but the trivial exploitation path - a standard HTTP GET request requiring no credentials - substantially elevates downstream risk of phishing campaigns and credential-stuffing attacks targeting identified creators.

Arbitrary file read in the Tutor LMS WordPress plugin (all versions before 4.0.6) allows authenticated instructors to retrieve any file on the server — including files outside the web root — by exploiting a missing path validation check in the plugin's media streaming functionality. Critically, readable targets include wp-config.php, which exposes database credentials and WordPress authentication keys and salts; possession of these constants enables an attacker to forge valid session cookies for any account, including site administrators. No public exploit has been identified at time of analysis, and the EPSS score of 0.18% (8th percentile) reflects low observed exploitation activity, but the cascading impact path from instructor account to full site compromise makes patching urgent for any site with open instructor registration.

Unauthenticated information disclosure in the FiboSearch WordPress plugin before 1.34.1 exposes password-protected WooCommerce products and their metadata to any website visitor without requiring the product password. Two AJAX endpoints - the autocomplete handler (dgwt_wcas_ajax_search) and the Details Panel handler (dgwt_wcas_result_details) - fail to enforce WooCommerce's native password-protection access control, allowing enumeration of restricted product names, slugs, and taxonomy data. No public exploit code identified at time of analysis; EPSS is 0.16% (5th percentile), indicating low current exploitation interest and no CISA KEV listing.

Sensitive information disclosure in Combodo iTop prior to version 3.2.3 leaks raw exception messages to authenticated users through the application's AJAX rendering layer. In ajax.render.php, caught exceptions were echoed back to the browser via $e->GetMessage() (HTML-escaped to prevent XSS, but not content-filtered), potentially exposing internal file paths, database schema details, stack context, or configuration fragments. No public exploit has been identified at time of analysis, and the low CVSS score of 3.5 reflects limited practical impact; however, the disclosed internals can meaningfully assist further reconnaissance.

Unauthenticated information disclosure in CrossWatch prior to v0.9.21 allows any network-accessible attacker to enumerate active session metadata via GET /api/app-auth/status, including originating IP addresses, User-Agent strings, internal session IDs, and creation/expiry timestamps. All CrossWatch deployments running versions before 0.9.21 with a network-accessible API are affected. No public exploit code has been identified and the vulnerability is not listed in CISA KEV, though exploitation requires only a standard HTTP client with no credentials.

Symlink-following vulnerability in Runtipi 4.10.0 and earlier enables authenticated administrators to write arbitrary content to any filesystem path accessible by the Runtipi process. An attacker with admin credentials plants a symlink inside a crafted backup archive targeting an arbitrary path, restores the archive via the backup API, and then invokes the user-config write endpoint - causing FilesystemService.writeTextFile() to follow the planted link and write attacker-controlled content outside the intended directory boundary. No public exploit is identified at time of analysis; vendor-released patch v4.10.1 is available and the fix is confirmed by GitHub advisory GHSA-wcrf-g9p9-2wg7.

Integer overflow in GNU Emacs PBM/PPM/PGM image loader (all versions before 31.0.91) enables heap memory disclosure when a user opens a crafted image file. Signed integer multiplication of image height, width, and channel count wraps to a negative value for sufficiently large inputs, bypassing the allocated-buffer bounds check and allowing the pixel reader to over-read heap contents, which are then rendered on-screen as color values. No active exploitation has been confirmed (not in CISA KEV), and no public exploit code has been identified at time of analysis; however, the VulnCheck-reported CVSS 4.0 score of 6.9 reflects high confidentiality and availability impact under local conditions with user interaction.

Version disclosure in Combodo iTop's login page exposes the complete application version string in the HTML title attribute of the logo element to unauthenticated remote users. All iTop releases prior to 3.2.3 are affected; the CVSS vector (AV:N/AC:L/PR:N/UI:N) confirms exploitation requires no authentication or user interaction against any network-accessible login page. No active exploitation has been confirmed (not in CISA KEV) and no public POC has been identified; this vulnerability primarily enables reconnaissance that can be chained into version-targeted follow-on attacks.

Hidden volume creation in VeraCrypt 1.26.6 through 1.26.28 leaves forensically detectable plaintext markers inside file-hosted hidden volume containers, directly undermining plausible deniability guarantees. The FormatNoFs and FormatFat functions apply a quick-format optimization that writes zeroed sectors at predictable 128 MiB intervals via WriteFile, bypassing the EncryptDataUnits path that would fill the area with indistinguishable ciphertext; a forensic examiner with access to the container can identify these anomalous plaintext artifacts and infer hidden volume presence. Encryption strength and hidden-volume contents are not compromised - impact is confined to deniability failure. No public exploit has been identified and this vulnerability is not listed in CISA KEV.

Key derivation in VeraCrypt's non-default wolfCrypt backend silently substituted HKDF for PBKDF2-HMAC in SHA-256 and SHA-512 volume-header derivation, discarding the configured iteration count entirely - meaning any PIM or iteration tuning applied by users of affected builds provided zero additional brute-force resistance. Any attacker who obtains a volume file produced by a WOLFCRYPT=1 source build can attempt password recovery at HKDF speeds rather than PBKDF2-iterated cost, dramatically reducing the work factor. Official precompiled VeraCrypt binaries and standard distribution packages are entirely unaffected; no public exploit has been identified and this vulnerability is not listed in CISA KEV.

Cleartext credential exposure in Johnson Controls Simplex Incident Manager / Autocall Fire Administrator (all versions before 2.01.05) allows a local low-privilege attacker who meets specific preconditions to retrieve sensitive data stored unencrypted in application memory (CWE-316). The CVSS 4.0 vector's subsequent-system confidentiality impact (SC:H) is especially notable given this platform interfaces with fire alarm controllers and building safety networks, meaning extracted credentials could be leveraged against downstream safety-critical infrastructure. No public exploit code and no CISA KEV listing have been identified at time of analysis.

Token exfiltration in Infracost prior to 0.10.45 allows an attacker who controls scanned Terraform source to redirect a configured Terraform Cloud or registry credential to an arbitrary attacker-controlled host. The vulnerable code path in internal/hcl/remote_variables_loader.go derived the destination hostname from untrusted Terraform cloud/backend block attributes without validating it against the operator-configured trusted host. CI pipelines using pull_request_target or same-repository pull request workflows that expose a TFC token to Infracost scans are affected; standard fork pull_request workflows without secrets are explicitly not vulnerable. No public exploit code has been identified at time of analysis, and this CVE is not listed in CISA KEV.

Information disclosure in the Brushfire video content streaming platform (online.brushfire.com) exposes internal database path strings within HTTP responses to unauthenticated remote users, allowing enumeration of other users' data. The root cause is CWE-497 (Exposure of Sensitive System Information to an Unauthorized Control Sphere), where backend infrastructure details are insufficiently abstracted from client-facing responses. The vendor applied a server-side fix in February 2026; no active exploitation has been confirmed and no public proof-of-concept has been identified.

Out-of-bounds read in iccDEV (all versions prior to 2.3.2.1) crashes the ICC profile parser via a size_t integer underflow in CIccEmbedIO::Read8() when processing embedded ICC v5 profiles. Unauthenticated remote attackers can trigger the denial-of-service condition by delivering a maliciously crafted ICC profile that requires user interaction to parse (e.g., opening a file in an application backed by this library). No public exploit code and no CISA KEV listing exist at time of analysis; vendor-released patch version 2.3.2.1 is available.

Vault token disclosure in the N-able PassPortal browser extension (versions before 3.49.6) stems from missing origin validation on postMessage events, classified under CWE-1385. A malicious web page can send a crafted postMessage to the extension listener, causing it to disclose HashiCorp Vault tokens to an untrusted origin - enabling authentication abuse against any Vault instance the user's session is authorized to access. No public exploit code has been identified at time of analysis, but the network-accessible, unauthenticated attack path (UI:A in CVSS 4.0) and high confidentiality impact make this a meaningful credential theft risk for MSP environments.

Spring AI 2.0.0's Semantic Cache feature leaks cached LLM responses across unrelated system prompt contexts due to insufficient isolation in the context hashing mechanism. Applications using semantic caching across multiple tenants or security domains - where different system prompts define distinct access boundaries - are at risk of cross-context information disclosure and response tampering. Exploitation requires authenticated access and high attack complexity (AC:H, PR:L); no public exploit code and no CISA KEV listing exist at time of analysis.

Stored shortcode injection in the ProfilePress WordPress plugin before 4.17.1 allows unauthenticated attackers to persist shortcodes in two unfiltered profile fields, which WordPress then executes when any visitor loads the public profile page. The impact is limited to information disclosure - exposing a targeted user's email address, login date, and registration date - but the attack requires no elevated privileges and no special configuration beyond default plugin deployment. A publicly available exploit exists per WPScan's disclosure; patch version 4.17.1 is confirmed available from the vendor.

Username denylist bypass in Limit Login Attempts Security (Limit Login Attempts Reloaded) before version 3.3.5 allows a WordPress user who has been explicitly blocked by an administrator to successfully authenticate by varying the case of their username or by supplying the account's associated email address instead. This is a logic flaw in the plugin's denylist enforcement, entirely defeating the access control that a site administrator intended to impose on specific accounts. A publicly available proof-of-concept is documented in the WPScan advisory; the low CVSS score of 3.7 with AC:H reflects that successful exploitation requires the attacker to already hold valid credentials for the denylisted account.

Webhook authentication bypass in the Charitable WordPress donation plugin (versions before 1.8.12) allows unauthenticated remote attackers to forge Square payment webhook notifications, causing the plugin to record donations as successfully paid without any actual financial transaction occurring. The vulnerability exists in all default configurations where Square is the configured payment gateway, requiring no credentials or user interaction to exploit. A publicly available proof-of-concept exists per WPScan reporting, though this vulnerability has not been listed in CISA's Known Exploited Vulnerabilities catalog at time of analysis.

Payment gateway merchant account verification is entirely absent in the myCred WordPress plugin before version 3.2.5, enabling unauthenticated remote attackers to fraudulently inflate their in-site credit balances by routing payments to a gateway account they control instead of the site operator's. An attacker needs only to complete a payment of the expected amount through a supported gateway and trigger the resulting notification to the vulnerable site - no knowledge of or access to the site's merchant credentials is required. A publicly available exploit exists per WPScan reporting (EUVD-2026-63909), and a vendor-released patch in version 3.2.5 is confirmed available.

Improper authorization in Dolibarr's user account management component (htdocs/user/card.php) through version 23.0.4 permits authenticated non-admin users to delete administrator accounts by supplying an arbitrary user ID to the Account Handler. The commit diff confirms the root cause: the deletion code path executed without verifying whether the target account held admin privileges or whether the requesting user was an administrator. A public exploit exists (CVSS 4.0 supplemental E:P); no active exploitation has been confirmed via CISA KEV.

STIX document import in misp-stix through version 2026.7.8 allows an unauthenticated attacker who can supply a crafted STIX bundle to inject arbitrary MISP attribute metadata - including distribution level, sharing_group_id, and classification tags - into the importing MISP instance. The import pipeline trusted attacker-controlled STIX fields (tool labels for STIX2, document title for STIX1) to decide whether content originated from MISP itself, and then passed the complete x_misp_attributes dictionary without field filtering directly into attribute creation. No public exploit has been identified at time of analysis; patch commits are available upstream from the MISP project.

Improper output encoding in Apache CloudStack's management UI exposes administrators to cross-site scripting (XSS) when using the Lock User functionality across versions 4.20.0.0-4.20.3.0 and 4.21.0.0-4.22.1.0. A low-privilege user can embed a malicious script payload in a user-controlled field; when an administrator invokes the Lock User workflow, the CloudStack UI renders the payload without proper HTML or JavaScript escaping, executing it in the admin's browser session. No public exploit or CISA KEV listing has been identified at time of analysis, but the potential for admin session hijacking makes this a meaningful risk in multi-tenant environments.

Sensitive information exposure in Apache CloudStack's Webhook module allows unauthorized actors to view data they should not have access to during webhook delivery listing and deletion operations. Affected deployments span versions 4.20.0.0 through 4.20.3.0 and 4.21.0.0 through 4.22.1.0, covering two active release trains. No public exploit or active exploitation has been identified at time of analysis; vendor-released patches are available.

CRLF injection in @fastify/busboy's multipart part-header parser allows unauthenticated remote attackers to embed bare carriage return or line feed characters into parsed Content-Disposition filenames and field names, which are then handed to applications as if they were clean values. All versions through 3.2.1 are affected; the fix is in 3.2.2. When applications forward these tainted values to CR/LF-sensitive sinks - HTTP response headers, log systems, or filesystem paths - attackers can achieve log forging, HTTP header injection, or filesystem filename pollution. No public exploit or CISA KEV listing has been identified at time of analysis.

Unauthorized post data disclosure in the Duplicate Post WordPress plugin before 1.5.6 allows authenticated users holding a delegated role to read content, metadata, and passwords for posts they should not have access to - including other users' private and draft posts. The CVSS vector (PR:H/C:L) reflects a constrained impact limited to information disclosure within authenticated contexts, making this a meaningful risk in multi-user editorial WordPress environments but not in single-author deployments. A publicly available proof-of-concept exists per WPScan's advisory; no active exploitation has been confirmed via CISA KEV.

Unauthenticated information disclosure in Dokan WooCommerce Multivendor Marketplace plugin (versions before 5.0.14) allows any remote actor to retrieve per-vendor commission configuration from an unprotected store REST endpoint without credentials. The exposed data includes commission type and, where category-based commissions are configured, per-category and default commission rates - leaking potentially sensitive business financial details for every vendor on the marketplace. A publicly available proof-of-concept exists; however, active exploitation has not been confirmed via CISA KEV.

Kernel heap corruption and GPU memory leaks in Imagination Technologies Graphics DDK expose systems to local denial-of-service from non-privileged users. A double-free defect in the GPU memory free paths - triggered via user-initiated GPU system calls - can corrupt kernel heap state or cause memory leaks, with potential availability impact at the kernel level. No active exploitation is confirmed (EPSS 0.15%, no CISA KEV listing), but a vendor patch is available and a ChromeOS stable channel advisory confirms real-world distribution reach.

Private thread content disclosure in Rocket.Chat exposes all private thread parents and their full reply content to any low-privilege authenticated user on instances running versions prior to 8.8.0 across multiple maintained release branches. By substituting a MongoDB operator object (e.g., {"$gt": ""}) for the expected string room-id or thread message-id in the Meteor DDP methods getThreadsList and getThreadMessages, an attacker with any valid account can cause downstream MongoDB queries to fan out across all rooms while the authorization check resolves only to a room the attacker legitimately accesses. No public exploit has been identified at time of analysis, but the technique is straightforward for any developer familiar with DDP WebSocket debugging, and the fix pattern is visible in the public GitHub pull request.

Unexpected application termination in Apple macOS arises when processing a maliciously crafted file, triggering an out-of-bounds read (CWE-125) that crashes the handling application. Affected versions span all three active macOS release trains: Sonoma prior to 14.8.5, Sequoia prior to 15.7.5, and Tahoe prior to 26.4. No public exploit code has been identified and EPSS sits at the 5th percentile (0.15%), indicating low real-world exploitation probability; vendor-released patches are available for all three tracks.