Information Disclosure
Monthly
Unauthenticated credential exposure in rclone before 1.75.0 allows remote attackers to retrieve backend storage secrets via the pprof debug endpoint, bypassing the main handler's fail-closed authentication entirely. The root cause is architectural: rclone registers Go's net/http/pprof handler on its own separate router route rather than nesting it within the authenticated main handler, so GET /debug/pprof/cmdline returns the full process argv - including cloud backend credentials - to any unauthenticated caller. No CISA KEV listing or confirmed public exploit code exists at time of analysis, but exploitation requires no authentication, no special tooling, and no user interaction, making any network-exposed RC instance immediately vulnerable to credential theft.
Heap-based buffer under-read in libxml2's XML Schema identity constraint processor affects all Nokogiri releases prior to 1.18.8, which bundle the vulnerable libxml2 library. The flaw in xmlSchemaIDCFillNodeTables can be triggered by supplying a crafted XSD schema or by submitting untrusted XML documents for validation against trusted schemas that combine xsd:keyref with recursively defined types carrying additional identity constraints. No public exploit has been identified at time of analysis, and upstream libxml2 maintainers and MITRE independently rate actual exploitability as low - in notable conflict with the NVD-assigned CVSS 4.0 base score of 8.7.
Server-Side Request Forgery in PraisonAI before version 4.6.58 allows unauthenticated remote attackers to force the application server to make HTTP requests to internal network resources, including cloud metadata endpoints (169.254.169.254), loopback services, and RFC 1918 hosts. Two independent bypass paths exist in the Jobs API webhook_url validator: a DNS rebinding path exploiting the TOCTOU gap between validation and request dispatch, and a fail-open condition where socket.gaierror exceptions are silently swallowed, accepting unresolvable domains with no validation at all. A detailed proof-of-concept including curl commands is published in the GHSA advisory; no CISA KEV listing was present at time of analysis.
Item duplication and protected-item extraction in the MintyItanium Lost-Auction Minecraft auction plugin (all versions prior to commit 88c920b05042929db334ba06d57f052b42d6b3f8) allows authenticated players to manipulate GUI interactions to obtain barrier blocks or duplicate items from the auction interface. The root cause is improper control flow in the GUI handling logic (CWE-670), enabling players to bypass intended item restrictions without elevated permissions. No public exploit code has been identified at time of analysis, and the vulnerability is confined to Minecraft server game integrity rather than infrastructure security.
Cart quantity manipulation in macrozheng mall up to version 1.0.3 allows authenticated remote attackers to exploit a business logic error in the OmsCartItemServiceImpl.updateQuantity function at the /cart/update/quantity endpoint by submitting maliciously crafted quantity values. The CWE-840 classification confirms the root cause is improper enforcement of business rules rather than a memory-safety flaw, allowing attackers to potentially submit negative, zero, or arbitrarily large quantity values to distort cart totals or order pricing. No public exploit code has been identified at time of analysis, and the vendor's unexplained deletion of the associated GitHub issue (#984) leaves patch status unresolved.
Privileged information disclosure in YOOtheme Pro for Joomla (versions 1.0.0 through 5.0.41) allows authenticated users holding only com_template editing permissions to read metadata about arbitrary Joomla modules - access that normally requires the separate com_modules permission. The root cause is CWE-284 (Improper Access Control): the extension's template editor fails to verify whether the requesting user holds the appropriate module-management permission before returning module data. No public exploit identified at time of analysis, and the CVSS 4.0 score of 5.1 (Medium) reflects the high privilege requirement and limited confidentiality impact.
Ech0 before version 4.7.3 exposes guest commenter email addresses to unauthenticated remote callers via public comment-listing API endpoints, due to a missing `json:"-"` serialization tag on the Comment model's Email field. Any attacker with HTTP access to an Ech0 instance can enumerate every guest commenter email stored in the database by calling `/api/comments` or `/api/comments/public` without credentials. A working proof-of-concept script is published in the GHSA advisory; no public exploit has been confirmed as actively exploited (CISA KEV listing absent).
Missing HttpOnly cookie flags in HCL Hive expose session tokens and sensitive credentials to client-side script access, enabling session hijacking when combined with cross-site scripting. The CVE description cites broader infrastructure weaknesses - lateral movement, container breakout, and internal communications exposure - suggesting CWE-1004 is one root cause within a cluster of related configuration flaws. No public exploit has been identified at time of analysis, and no KEV listing exists, but the network-accessible attack surface with no privilege requirement (beyond user interaction) makes this relevant for any internet-exposed Hive deployment.
HCL Hive's software supply chain governance weaknesses expose the application to risk from vulnerable, unmaintained, or malicious third-party dependencies incorporated into its build or runtime environment. The flaw (CWE-1104) reflects insufficient vetting of upstream components, meaning existing dependencies may carry unpatched CVEs or could serve as an introduction vector for malicious code. With a CVSS of 4.2 (AV:N/AC:H/PR:N/UI:R), exploitation is constrained by high attack complexity and user interaction requirements; no public exploit and no CISA KEV listing were identified at time of analysis.
HCL Hive exposes sensitive host environment information through a network-accessible information disclosure flaw, enabling unauthenticated remote attackers - under high attack complexity conditions - to collect reconnaissance data about the underlying system. The CVSS 3.7 (Low) score reflects both the constrained confidentiality impact and the high exploitation complexity. No public exploit code or active exploitation has been identified at time of analysis.
Symlink following in LACT (Linux AMDGPU Control Tool) versions through 0.10.0 allows a local low-privileged user to redirect privileged file operations to attacker-chosen paths via a crafted UNIX symbolic link, resulting in local denial-of-service. Reported by SUSE and tracked in their Bugzilla (bsc#1276481), the flaw is rooted in CWE-61 and is confined to systems with multi-user local access where LACT is installed. No public exploit code has been identified and the issue does not appear in the CISA KEV catalog.
Filter injection in the EXT:solr (Apache Solr for TYPO3 - Enterprise Search) extension enables unauthenticated visitors to bypass per-site document isolation on shared Solr cores, exposing public search-indexed content belonging to adjacent TYPO3 site installations. The flaw exists because user-supplied additionalFilters request parameters can pre-register a named siteHash filter that the query builder then refuses to overwrite, undermining the multi-tenancy boundary the extension relies upon for site separation. No public exploit code has been identified at time of analysis, and exploitation is gated on a specific shared-core deployment pattern; no active exploitation is confirmed.
Unrestricted Solr query syntax passthrough in the TYPO3 EXT:solr enterprise search extension exposes indexed data to remote unauthenticated attackers via blind injection techniques. By crafting queries that exploit Solr's native field selectors, wildcards, and range operators, an attacker can enumerate schema field names and systematically extract stored values without triggering obvious errors. No public exploit code has been identified at time of analysis; the CVSS 4.0 score of 6.3 reflects high attack complexity (AC:H/AT:P) that limits opportunistic mass exploitation.
Insufficient JWT expiration validation in the TYPO3 'Syssy - TYPO3 Monitoring & Security Checks' extension allows an attacker already in possession of a valid SYSSY project API key to authenticate using an expired token, bypassing the intended session time boundary (CWE-613). The limited confidentiality and integrity impact (VC:L/VI:L per the CVSS 4.0 vector) reflects access to monitoring and security check data rather than full system compromise. No active exploitation has been confirmed (not listed in CISA KEV), and no public exploit code has been identified at time of analysis.
Cleartext transmission of TYPO3 system information occurs in the Syssy - TYPO3 Monitoring & Security Checks extension when OpenSSL is absent on the hosting server, exposing potentially sensitive configuration and system data to network interception (CWE-319). All tracked versions of the extension are affected per CPE data, though exploitation is constrained by the dual requirement of OpenSSL being unavailable and the attacker already possessing the SYSSY project's API key. No public exploit code has been identified and this vulnerability is not listed in the CISA KEV catalog; the CVSS 4.0 score of 5.3 reflects the medium-severity, partially-authenticated nature of the flaw.
Prototype pollution in the `@cleverbrush/deep` package (versions ≤ 4.4.0) allows a remote attacker to corrupt `Object.prototype` by supplying crafted JSON containing reserved JavaScript keys (`__proto__`, `constructor`, `prototype`) to the `deepExtend()` function without any privilege requirement. Any Node.js application that passes externally controlled input through `deepExtend()` is at risk of property injection affecting every plain object in the runtime, potentially enabling authentication bypass or logic manipulation downstream. A public exploit exists (GitHub issue #213); the vulnerability is not listed in CISA KEV, so widespread active exploitation is not confirmed at time of analysis.
Local File Inclusion in the Events Manager WordPress plugin (all versions through 7.3.7.4) allows an administrator-level attacker to store a malicious PHP file traversal path via the em_options_save function, which is then executed without any further authentication on every admin_init hook invocation - including unauthenticated admin-ajax.php requests. The two-phase attack converts a high-privilege write primitive into a persistent, unauthenticated code execution trigger that survives account remediation until the stored option is manually purged. No public exploit code has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog.
Rocket.Chat's unauthenticated DDP method sendForgotPasswordEmail lacks a rate-limiting rule, enabling any network caller to flood a target email address with password reset messages from the deployment's own mail sender and to enumerate account types at scale. The method is reachable both via the Meteor DDP protocol and the unauthenticated HTTP route POST /api/v1/method.callAnon/sendForgotPasswordEmail, requiring no credentials. A side-channel in the method's response - returning false only when the target belongs to an OAuth-authenticated account with Accounts_AllowPasswordChangeForOAuthUsers disabled - allows an attacker to distinguish account authentication types, confirming information disclosure beyond simple email abuse. No public exploit or KEV listing is identified at time of analysis.
Cookie-path scoping manipulation in Adminer 4.6.0-5.5.0 results from an incomplete fix for a prior X-Forwarded-Prefix header injection (GHSA-8478-xrj3-h9c2). The validation guard in bootstrap.inc.php blocks double-slash prefixes (//evil.com) but accepts backslash variants (/\evil.com); because browsers normalize backslash to forward slash, the malformed prefix survives as a network-path reference into cookie_path(), corrupting the Set-Cookie Path attribute. Exploitation depends on a misconfigured or absent reverse proxy that permits clients to supply the X-Forwarded-Prefix header, and no public exploit has been identified at time of analysis.
Infinite-loop denial of service in OpenEXR versions prior to 3.2.10, 3.3.12, and 3.4.13 allows an attacker to permanently hang any process that parses a crafted EXR image by triggering an integer overflow in the sample-count helper roundListSizeUp(). When UINT_MAX is passed as a sample-count value, 32-bit unsigned left-shift arithmetic wraps the accumulator to zero, producing a loop condition that never terminates. The vulnerability is reachable through public OpenEXRUtil APIs, making it exploitable wherever applications accept externally-supplied EXR files. No public exploit code or CISA KEV listing has been identified at time of analysis.
Uncontrolled recursion in Autodesk 3ds Max's SVG parser allows a crafted file to exhaust the call stack and crash the application, resulting in denial of service. The attack requires user interaction - a victim must open a maliciously crafted SVG file - and has no impact on confidentiality or integrity. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.
Null byte injection in Netty's MqttEncoder affects applications using versions prior to 4.1.137.Final and 4.2.17.Final that forward user-controlled input into MQTT UTF-8 string fields - specifically client identifiers, will topics, usernames, and PUBLISH topic names. Because the encoder performs no null byte validation, an attacker with adjacent-network access and low-level privileges can embed the prohibited U+0000 character, causing downstream MQTT brokers to misparse field boundaries and potentially bypass topic-based ACLs or misidentify client sessions. No public exploit has been identified at time of analysis, and the vulnerability has not been added to the CISA KEV catalog.
Universe checking state desynchronization in the Rocq Prover allows the kernel to continue accepting universe-inconsistent terms after a module using `Local Unset Universe Checking` is closed, despite user-visible diagnostics reporting the check as enabled. Once the module closes, Hurkens' paradox can be applied without axioms, plugins, or unsafe features to derive a proof of False, from which any proposition is provable. A public proof-of-concept is available, no patch exists, and neither `Print Assumptions` nor `Test Universe Checking` reveals the compromised kernel state.
Lean 4's formal proof kernel accepts unsound opaque declarations due to a missing closure check in environment::add_opaque, enabling a metaprogram to admit a constant of type False without sorry, unsafeCast, or any unsafe mechanism - directly shattering the kernel's soundness guarantee. All Lean 4 versions before 4.32.2 are affected; a publicly available proof-of-concept at https://github.com/endrazine/lean-cve-poc-14484 confirms exploitability. No CISA KEV listing exists, but the POC's public availability and the ecosystem's reliance on kernel soundness for formal guarantees make this a high-priority upgrade for any organization using Lean 4 for verified software or mathematical proofs.
Soundness violation in Rocq Prover's guard checker (versions V8.20 through V9.1.1) allows crafting a nested fixpoint that produces a proof of False from purely definitional code - no tactics, axioms, plugins, or unsafe flags required. The flaw stems from the checker's failure to track higher-order recursive calls when a fixpoint passes itself as an argument to a nested fixpoint, which then applies it to a non-subterm value, admitting a type definitionally equal to its own negation. A public proof-of-concept exploit exists at github.com/endrazine/rocq-cve-poc-21683; no active exploitation is confirmed in CISA KEV, but any proof corpus accepted by affected Rocq versions should be considered potentially unsound until re-verified under Rocq 9.2.0.
Rocq Prover's kernel guard checker fails to revalidate the recursive tree representation of inductive type parameters after they are altered by transport, allowing construction of provably non-terminating fixpoint definitions that the kernel accepts as structurally decreasing. Two cooperating fixpoints exploit this: the first corrupts the recursive tree via a transport rewrite, and the second inherits the corrupted tree without re-verification, enabling a structurally non-decreasing call to be accepted as terminating. The resulting definition derives a proof of False from axioms consistent with the calculus of inductive constructions, breaking logical soundness; a public proof-of-concept exists at https://github.com/endrazine/rocq-cve-poc-22024 and no merged patch is available at time of analysis.
Logical unsoundness in Rocq Prover's guard checker allows a crafted nested mutual fixpoint definition to be accepted as structurally terminating when it is not, yielding a proof of False derivable without axioms, plugins, or unsafe flags in versions V8.20 through V9.1.1. The flaw means any proposition - including security-critical formally verified properties - can be trivially proven once a malicious or malformed proof file is compiled on an affected system. A public proof-of-concept exploit exists; no active exploitation has been recorded in CISA KEV, consistent with the niche academic deployment base.
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.
Unauthenticated credential exposure in rclone before 1.75.0 allows remote attackers to retrieve backend storage secrets via the pprof debug endpoint, bypassing the main handler's fail-closed authentication entirely. The root cause is architectural: rclone registers Go's net/http/pprof handler on its own separate router route rather than nesting it within the authenticated main handler, so GET /debug/pprof/cmdline returns the full process argv - including cloud backend credentials - to any unauthenticated caller. No CISA KEV listing or confirmed public exploit code exists at time of analysis, but exploitation requires no authentication, no special tooling, and no user interaction, making any network-exposed RC instance immediately vulnerable to credential theft.
Heap-based buffer under-read in libxml2's XML Schema identity constraint processor affects all Nokogiri releases prior to 1.18.8, which bundle the vulnerable libxml2 library. The flaw in xmlSchemaIDCFillNodeTables can be triggered by supplying a crafted XSD schema or by submitting untrusted XML documents for validation against trusted schemas that combine xsd:keyref with recursively defined types carrying additional identity constraints. No public exploit has been identified at time of analysis, and upstream libxml2 maintainers and MITRE independently rate actual exploitability as low - in notable conflict with the NVD-assigned CVSS 4.0 base score of 8.7.
Server-Side Request Forgery in PraisonAI before version 4.6.58 allows unauthenticated remote attackers to force the application server to make HTTP requests to internal network resources, including cloud metadata endpoints (169.254.169.254), loopback services, and RFC 1918 hosts. Two independent bypass paths exist in the Jobs API webhook_url validator: a DNS rebinding path exploiting the TOCTOU gap between validation and request dispatch, and a fail-open condition where socket.gaierror exceptions are silently swallowed, accepting unresolvable domains with no validation at all. A detailed proof-of-concept including curl commands is published in the GHSA advisory; no CISA KEV listing was present at time of analysis.
Item duplication and protected-item extraction in the MintyItanium Lost-Auction Minecraft auction plugin (all versions prior to commit 88c920b05042929db334ba06d57f052b42d6b3f8) allows authenticated players to manipulate GUI interactions to obtain barrier blocks or duplicate items from the auction interface. The root cause is improper control flow in the GUI handling logic (CWE-670), enabling players to bypass intended item restrictions without elevated permissions. No public exploit code has been identified at time of analysis, and the vulnerability is confined to Minecraft server game integrity rather than infrastructure security.
Cart quantity manipulation in macrozheng mall up to version 1.0.3 allows authenticated remote attackers to exploit a business logic error in the OmsCartItemServiceImpl.updateQuantity function at the /cart/update/quantity endpoint by submitting maliciously crafted quantity values. The CWE-840 classification confirms the root cause is improper enforcement of business rules rather than a memory-safety flaw, allowing attackers to potentially submit negative, zero, or arbitrarily large quantity values to distort cart totals or order pricing. No public exploit code has been identified at time of analysis, and the vendor's unexplained deletion of the associated GitHub issue (#984) leaves patch status unresolved.
Privileged information disclosure in YOOtheme Pro for Joomla (versions 1.0.0 through 5.0.41) allows authenticated users holding only com_template editing permissions to read metadata about arbitrary Joomla modules - access that normally requires the separate com_modules permission. The root cause is CWE-284 (Improper Access Control): the extension's template editor fails to verify whether the requesting user holds the appropriate module-management permission before returning module data. No public exploit identified at time of analysis, and the CVSS 4.0 score of 5.1 (Medium) reflects the high privilege requirement and limited confidentiality impact.
Ech0 before version 4.7.3 exposes guest commenter email addresses to unauthenticated remote callers via public comment-listing API endpoints, due to a missing `json:"-"` serialization tag on the Comment model's Email field. Any attacker with HTTP access to an Ech0 instance can enumerate every guest commenter email stored in the database by calling `/api/comments` or `/api/comments/public` without credentials. A working proof-of-concept script is published in the GHSA advisory; no public exploit has been confirmed as actively exploited (CISA KEV listing absent).
Missing HttpOnly cookie flags in HCL Hive expose session tokens and sensitive credentials to client-side script access, enabling session hijacking when combined with cross-site scripting. The CVE description cites broader infrastructure weaknesses - lateral movement, container breakout, and internal communications exposure - suggesting CWE-1004 is one root cause within a cluster of related configuration flaws. No public exploit has been identified at time of analysis, and no KEV listing exists, but the network-accessible attack surface with no privilege requirement (beyond user interaction) makes this relevant for any internet-exposed Hive deployment.
HCL Hive's software supply chain governance weaknesses expose the application to risk from vulnerable, unmaintained, or malicious third-party dependencies incorporated into its build or runtime environment. The flaw (CWE-1104) reflects insufficient vetting of upstream components, meaning existing dependencies may carry unpatched CVEs or could serve as an introduction vector for malicious code. With a CVSS of 4.2 (AV:N/AC:H/PR:N/UI:R), exploitation is constrained by high attack complexity and user interaction requirements; no public exploit and no CISA KEV listing were identified at time of analysis.
HCL Hive exposes sensitive host environment information through a network-accessible information disclosure flaw, enabling unauthenticated remote attackers - under high attack complexity conditions - to collect reconnaissance data about the underlying system. The CVSS 3.7 (Low) score reflects both the constrained confidentiality impact and the high exploitation complexity. No public exploit code or active exploitation has been identified at time of analysis.
Symlink following in LACT (Linux AMDGPU Control Tool) versions through 0.10.0 allows a local low-privileged user to redirect privileged file operations to attacker-chosen paths via a crafted UNIX symbolic link, resulting in local denial-of-service. Reported by SUSE and tracked in their Bugzilla (bsc#1276481), the flaw is rooted in CWE-61 and is confined to systems with multi-user local access where LACT is installed. No public exploit code has been identified and the issue does not appear in the CISA KEV catalog.
Filter injection in the EXT:solr (Apache Solr for TYPO3 - Enterprise Search) extension enables unauthenticated visitors to bypass per-site document isolation on shared Solr cores, exposing public search-indexed content belonging to adjacent TYPO3 site installations. The flaw exists because user-supplied additionalFilters request parameters can pre-register a named siteHash filter that the query builder then refuses to overwrite, undermining the multi-tenancy boundary the extension relies upon for site separation. No public exploit code has been identified at time of analysis, and exploitation is gated on a specific shared-core deployment pattern; no active exploitation is confirmed.
Unrestricted Solr query syntax passthrough in the TYPO3 EXT:solr enterprise search extension exposes indexed data to remote unauthenticated attackers via blind injection techniques. By crafting queries that exploit Solr's native field selectors, wildcards, and range operators, an attacker can enumerate schema field names and systematically extract stored values without triggering obvious errors. No public exploit code has been identified at time of analysis; the CVSS 4.0 score of 6.3 reflects high attack complexity (AC:H/AT:P) that limits opportunistic mass exploitation.
Insufficient JWT expiration validation in the TYPO3 'Syssy - TYPO3 Monitoring & Security Checks' extension allows an attacker already in possession of a valid SYSSY project API key to authenticate using an expired token, bypassing the intended session time boundary (CWE-613). The limited confidentiality and integrity impact (VC:L/VI:L per the CVSS 4.0 vector) reflects access to monitoring and security check data rather than full system compromise. No active exploitation has been confirmed (not listed in CISA KEV), and no public exploit code has been identified at time of analysis.
Cleartext transmission of TYPO3 system information occurs in the Syssy - TYPO3 Monitoring & Security Checks extension when OpenSSL is absent on the hosting server, exposing potentially sensitive configuration and system data to network interception (CWE-319). All tracked versions of the extension are affected per CPE data, though exploitation is constrained by the dual requirement of OpenSSL being unavailable and the attacker already possessing the SYSSY project's API key. No public exploit code has been identified and this vulnerability is not listed in the CISA KEV catalog; the CVSS 4.0 score of 5.3 reflects the medium-severity, partially-authenticated nature of the flaw.
Prototype pollution in the `@cleverbrush/deep` package (versions ≤ 4.4.0) allows a remote attacker to corrupt `Object.prototype` by supplying crafted JSON containing reserved JavaScript keys (`__proto__`, `constructor`, `prototype`) to the `deepExtend()` function without any privilege requirement. Any Node.js application that passes externally controlled input through `deepExtend()` is at risk of property injection affecting every plain object in the runtime, potentially enabling authentication bypass or logic manipulation downstream. A public exploit exists (GitHub issue #213); the vulnerability is not listed in CISA KEV, so widespread active exploitation is not confirmed at time of analysis.
Local File Inclusion in the Events Manager WordPress plugin (all versions through 7.3.7.4) allows an administrator-level attacker to store a malicious PHP file traversal path via the em_options_save function, which is then executed without any further authentication on every admin_init hook invocation - including unauthenticated admin-ajax.php requests. The two-phase attack converts a high-privilege write primitive into a persistent, unauthenticated code execution trigger that survives account remediation until the stored option is manually purged. No public exploit code has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog.
Rocket.Chat's unauthenticated DDP method sendForgotPasswordEmail lacks a rate-limiting rule, enabling any network caller to flood a target email address with password reset messages from the deployment's own mail sender and to enumerate account types at scale. The method is reachable both via the Meteor DDP protocol and the unauthenticated HTTP route POST /api/v1/method.callAnon/sendForgotPasswordEmail, requiring no credentials. A side-channel in the method's response - returning false only when the target belongs to an OAuth-authenticated account with Accounts_AllowPasswordChangeForOAuthUsers disabled - allows an attacker to distinguish account authentication types, confirming information disclosure beyond simple email abuse. No public exploit or KEV listing is identified at time of analysis.
Cookie-path scoping manipulation in Adminer 4.6.0-5.5.0 results from an incomplete fix for a prior X-Forwarded-Prefix header injection (GHSA-8478-xrj3-h9c2). The validation guard in bootstrap.inc.php blocks double-slash prefixes (//evil.com) but accepts backslash variants (/\evil.com); because browsers normalize backslash to forward slash, the malformed prefix survives as a network-path reference into cookie_path(), corrupting the Set-Cookie Path attribute. Exploitation depends on a misconfigured or absent reverse proxy that permits clients to supply the X-Forwarded-Prefix header, and no public exploit has been identified at time of analysis.
Infinite-loop denial of service in OpenEXR versions prior to 3.2.10, 3.3.12, and 3.4.13 allows an attacker to permanently hang any process that parses a crafted EXR image by triggering an integer overflow in the sample-count helper roundListSizeUp(). When UINT_MAX is passed as a sample-count value, 32-bit unsigned left-shift arithmetic wraps the accumulator to zero, producing a loop condition that never terminates. The vulnerability is reachable through public OpenEXRUtil APIs, making it exploitable wherever applications accept externally-supplied EXR files. No public exploit code or CISA KEV listing has been identified at time of analysis.
Uncontrolled recursion in Autodesk 3ds Max's SVG parser allows a crafted file to exhaust the call stack and crash the application, resulting in denial of service. The attack requires user interaction - a victim must open a maliciously crafted SVG file - and has no impact on confidentiality or integrity. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.
Null byte injection in Netty's MqttEncoder affects applications using versions prior to 4.1.137.Final and 4.2.17.Final that forward user-controlled input into MQTT UTF-8 string fields - specifically client identifiers, will topics, usernames, and PUBLISH topic names. Because the encoder performs no null byte validation, an attacker with adjacent-network access and low-level privileges can embed the prohibited U+0000 character, causing downstream MQTT brokers to misparse field boundaries and potentially bypass topic-based ACLs or misidentify client sessions. No public exploit has been identified at time of analysis, and the vulnerability has not been added to the CISA KEV catalog.
Universe checking state desynchronization in the Rocq Prover allows the kernel to continue accepting universe-inconsistent terms after a module using `Local Unset Universe Checking` is closed, despite user-visible diagnostics reporting the check as enabled. Once the module closes, Hurkens' paradox can be applied without axioms, plugins, or unsafe features to derive a proof of False, from which any proposition is provable. A public proof-of-concept is available, no patch exists, and neither `Print Assumptions` nor `Test Universe Checking` reveals the compromised kernel state.
Lean 4's formal proof kernel accepts unsound opaque declarations due to a missing closure check in environment::add_opaque, enabling a metaprogram to admit a constant of type False without sorry, unsafeCast, or any unsafe mechanism - directly shattering the kernel's soundness guarantee. All Lean 4 versions before 4.32.2 are affected; a publicly available proof-of-concept at https://github.com/endrazine/lean-cve-poc-14484 confirms exploitability. No CISA KEV listing exists, but the POC's public availability and the ecosystem's reliance on kernel soundness for formal guarantees make this a high-priority upgrade for any organization using Lean 4 for verified software or mathematical proofs.
Soundness violation in Rocq Prover's guard checker (versions V8.20 through V9.1.1) allows crafting a nested fixpoint that produces a proof of False from purely definitional code - no tactics, axioms, plugins, or unsafe flags required. The flaw stems from the checker's failure to track higher-order recursive calls when a fixpoint passes itself as an argument to a nested fixpoint, which then applies it to a non-subterm value, admitting a type definitionally equal to its own negation. A public proof-of-concept exploit exists at github.com/endrazine/rocq-cve-poc-21683; no active exploitation is confirmed in CISA KEV, but any proof corpus accepted by affected Rocq versions should be considered potentially unsound until re-verified under Rocq 9.2.0.
Rocq Prover's kernel guard checker fails to revalidate the recursive tree representation of inductive type parameters after they are altered by transport, allowing construction of provably non-terminating fixpoint definitions that the kernel accepts as structurally decreasing. Two cooperating fixpoints exploit this: the first corrupts the recursive tree via a transport rewrite, and the second inherits the corrupted tree without re-verification, enabling a structurally non-decreasing call to be accepted as terminating. The resulting definition derives a proof of False from axioms consistent with the calculus of inductive constructions, breaking logical soundness; a public proof-of-concept exists at https://github.com/endrazine/rocq-cve-poc-22024 and no merged patch is available at time of analysis.
Logical unsoundness in Rocq Prover's guard checker allows a crafted nested mutual fixpoint definition to be accepted as structurally terminating when it is not, yielding a proof of False derivable without axioms, plugins, or unsafe flags in versions V8.20 through V9.1.1. The flaw means any proposition - including security-critical formally verified properties - can be trivially proven once a malicious or malformed proof file is compiled on an affected system. A public proof-of-concept exploit exists; no active exploitation has been recorded in CISA KEV, consistent with the niche academic deployment base.
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.