Information Disclosure

CVE-2026-16288 is reported by Ubuntu but carries no public description, CVSS score, vector, or CWE at time of analysis. The vulnerability's nature, affected component, and impact are entirely unconfirmed. No meaningful synthesis is possible without a description or scoring data; treat this record as a placeholder pending vendor disclosure.

CVE-2026-18054 is associated with the Ubuntu platform per vendor reporting, but no description, CVSS score, CWE classification, or technical details are available in the provided data. Without a vulnerability description, the affected component, impact, and exploitation conditions cannot be determined. A meaningful security assessment is not possible from the supplied intelligence.

CVE-2026-63320 has no publicly available description, CVSS score, or CWE classification at time of analysis. The sole intelligence signal is a vendor report attributed to Ubuntu. Without a description, affected version range, or impact details, no meaningful impact statement can be made - this record should be treated as pending NVD enrichment.

Insufficient data prevents meaningful synthesis of CVE-2026-63109. The only confirmed intelligence signal is a vendor report attributed to Ubuntu, with no description, CVSS score, CWE classification, or version information available at time of analysis. No impact, affected component, or attack scenario can be characterized from the provided data.

CVE-2026-61405 has been reported via Ubuntu's vendor security channel, but no description, CVSS score, CWE classification, or supporting intelligence is available at time of analysis. The affected package, vulnerability class, and impact cannot be determined from the provided data. Security teams should consult Ubuntu Security Notices (USN) directly for authoritative details before making triage decisions.

CVE-2026-61406 is reported by Ubuntu with no public description, CVSS score, CWE classification, or affected version data available at time of analysis. The nature, impact, and exploitability of this vulnerability cannot be characterized from the provided intelligence. Security teams should monitor Ubuntu Security Notices (USN) and the Ubuntu CVE tracker for forthcoming disclosure.

Internal Ash attribute and argument names leak through GraphQL error responses in ash_graphql 1.9.0 through 1.10.x, bypassing application-configured error handlers intended to redact them. A logic flaw in AshGraphql.Errors causes a sanitizing error_handler's decision to suppress the :path field to be silently overridden, re-injecting raw internal field names via build_error_path/5. Unauthenticated remote clients can trigger validation failures on non-exposed or nested fields to enumerate internal schema structure that the application deliberately chose to hide. No public exploit or KEV listing exists at time of analysis.

Cross-session record leakage in ash_graphql's subscription batcher allows one subscriber's resolved GraphQL records to be delivered to a different subscriber's topic, potentially crossing tenant and actor boundaries. Versions 1.4.0 through 1.10.x are affected when the Batcher process falls back to inline `:backpressure_sync` or `:noproc` execution paths and a subscription resolver triggers a nested synchronous Ash notification in the same caller process. No public exploit has been identified at time of analysis, and a vendor-released patch is available in version 1.11.0.

Plaintext values of encrypted fields in ash_cloak leak verbatim into application logs, error-tracker payloads, changeset inspection output, and telemetry when the source attribute is not explicitly declared sensitive. All ash_cloak versions 0.1.0 through 0.3.x for the Elixir/Ash Framework are affected; a patch is available in 0.4.0. No public exploit is identified at time of analysis.

Predictable authentication token generation in TOTOLINK N600R firmware 4.3.0cu.7866_B20220506 exposes the router's web management interface to session token prediction attacks from the network. The loginAuth function in /web_cste/cgi-bin/cstecgi.cgi generates insufficiently random values (CWE-330), enabling unauthenticated remote attackers to predict valid session tokens and gain unauthorized access to router configuration data. A proof-of-concept exploit script (poc.py) is publicly available on GitHub, though high attack complexity limits practical exploitation to technically capable attackers.

State machine mismanagement in the NGSetup Handler of Linux Foundation Magma 1.9.0 allows remote, unauthenticated attackers to induce an invalid state in the AMF component by sending crafted NGAP NGSetup messages. The affected function resides in ngap_amf_handlers.c, which processes the initial setup handshake between 5G base stations (gNBs) and the Access and Mobility Management Function (AMF). A public proof-of-concept is available via a GitHub issue; this is not listed in the CISA KEV catalog.

Improper input validation in the NGSetupRequest Handler of Linux Foundation Magma 1.9.0 allows remote unauthenticated attackers to impact availability of the 5G core's Access and Mobility Management Function (AMF) by supplying a malformed NG-IoT-DefaultPagingDRX argument. A public proof-of-concept is available via GitHub issue #16023, though the vulnerability has not been added to CISA KEV and the project maintainers have not responded to the coordinated disclosure, meaning no patch is available. The CVSS 4.0 score of 6.9 reflects limited availability impact only, with no confidentiality or integrity exposure.

Improper integrity check validation in Linux Foundation Magma 1.9.0's SecurityModeComplete Handler allows remote unauthenticated attackers to bypass NAS-layer security verification in the mobile core network. The SecurityModeComplete message is part of the LTE Non-Access Stratum security negotiation procedure; failure to validate the integrity check value (CWE-354) means crafted messages can be accepted without proper cryptographic verification. A publicly available proof-of-concept exists on GitHub, and the CVSS 4.0 vector confirms network-reachable, zero-prerequisite exploitation with low-level impact across confidentiality, integrity, and availability dimensions.

Information disclosure in the InitialUEMessage Handler of Linux Foundation Magma 1.9.0 allows unauthenticated remote attackers to extract sensitive data by sending crafted UE attachment requests to the mobile core network. A proof-of-concept exploit has been publicly disclosed, elevating practical risk above theoretical concern despite the CVE's medium severity rating. The CVSS 4.0 vector confirms no integrity or availability impact - the exposure is limited to low-confidentiality data leakage - but the zero-authentication, network-accessible nature of the flaw broadens the attack surface for any operator with reachable core signaling interfaces.

SiYuan's publish mode before v3.8.1 leaks invisible-tier content to unauthenticated readers through three unguarded rendering pathways: SQL embed blocks, attribute-view keys, and attribute-view backlinks. Administrators who mark notes as invisible to control what anonymous visitors see receive no protection - those same visitors can enumerate the hidden content by exploiting any of the three listing mechanisms. No active exploitation has been identified (no CISA KEV listing, no public POC), and the vendor has released a fix in v3.8.1.

Authenticated administrators in SiYuan before v3.8.1 can bypass the IsForbiddenAbsPath security guard - introduced to remediate GHSA-c8r8-95hg-mp34 - by targeting the /history/*path and /repo/diff/*path API endpoints, which construct file paths independently and were never covered by the guard. Exploitation enables retrieval of historical file snapshots including data/.siyuan/publishAccess.json, which stores plaintext publish-mode passwords, and files under data/templates/. No public exploit identified at time of analysis; the vendor-released patch is v3.8.1.

Path traversal in SiYuan 3.8.0 allows an authenticated attacker to read arbitrary files within the workspace directory via the POST /api/template/render endpoint, including conf/conf.json, which contains the API token and cookie signing key. The RenderTemplate function enforces only a workspace-boundary check (util.IsAbsPathInWorkspace) but omits the sensitive-path exclusion (refuseToAccess() blocklist) applied by the file API, creating an inconsistency in access controls across API surfaces. The issue is fixed in v3.8.1; no public exploit identified at time of analysis.

WWBN AVideo's Live plugin exposes an unauthenticated endpoint at plugin/Live/api/preauthorize.json.php that accepts credentials via HTTP GET with no rate limiting, enabling two distinct abuse vectors: sustained brute-force password guessing against any user account and uncapped triggering of two-factor authentication confirmation emails. All versions of AVideo are affected per CPE data, and exploitation requires no privileges or user interaction. No public exploit code or active exploitation has been identified at time of analysis, though the attack surface is trivially low-complexity for any remote attacker.

Cleartext API key storage in browser-use web-ui versions 2.0.0 through 3.0.0 exposes configured LLM provider credentials to any local user with filesystem read access. The application writes API keys to predictably-named JSON files in a temporary settings directory without encryption or access controls, as identified in src/webui/webui_manager.py. An attacker who gains read access to that directory can silently harvest credentials and use them to impersonate the victim against third-party LLM APIs, incurring charges or extracting data. No public exploit code has been identified at time of analysis.

Arbitrary directory creation in browser-use web-ui 2.0.0-3.0.0 allows remote unauthenticated attackers to create directories at any path writable by the root-running container. The `run_agent_task` function passes user-supplied `save_recording_path`, `save_trace_path`, `save_agent_history_path`, and `save_download_path` values directly to filesystem operations without sanitizing absolute path inputs. Because the Gradio interface requires no authentication and containers commonly run as root, the effective write surface spans the entire container filesystem. No public exploit has been identified at time of analysis.

Race condition exploitation in FileCodeBox's Pickup Limit Handler allows remote unauthenticated attackers to bypass configured file download quotas by sending concurrent retrieval requests. The flaw exists in the `update_file_usage` function (`apps/base/views.py`) across all releases prior to v2.5.0 - including v2.4.0 despite the CVE description citing only 'up to 2.3'. A public proof-of-concept is available via GitHub issue #482, though no active exploitation has been confirmed by CISA KEV. The vendor-released fix is confirmed in v2.5.0 via commit 8d7d856.

Incorrect string trimming in ash_sql causes divergent behavior between SQL-layer and in-memory evaluation of the `string_trim/1` function, enabling users to pad string fields with tab, newline, carriage-return, or form-feed characters to bypass trimmed uniqueness or equality checks. All ash_sql versions from 0.1.0 up to (not including) 0.7.1 are affected wherever `string_trim/1` appears in Ash filters, validations, or identity constraints that are evaluated at the SQL layer. No public exploit has been identified and no active exploitation is confirmed; the overall risk is low (CVSS 4.0: 2.1), but the bypass can permit duplicate record creation or filter evasion in affected applications.

Uncontrolled recursion in ash_oban's compile-time-generated Oban worker code enables unbounded heap growth and CPU exhaustion in the BEAM worker process when a trigger's on_error action deterministically raises on the job's final attempt. Affected versions span 0.8.0-rc.1 through 0.8.13 of the ash-project/ash_oban Elixir library. Any condition that causes the on_error action to fail repeatedly - a data-layer outage, a misconfigured action, or a record the action validates and rejects - loops handle_error/4 forever, growing the process heap without bound until the BEAM runtime kills the worker. No public exploit has been identified at time of analysis; a vendor-released patch is confirmed at 0.8.14.

Weak password recovery in Beetel 450TC3 router firmware 01.00.00_01 allows low-privileged authenticated attackers to exploit a flawed account recovery workflow over the network, potentially escalating privileges to administrative control of the device. A public proof-of-concept has been disclosed on GitHub, and the exploit reference explicitly describes authenticated privilege escalation as the realized impact. The vendor did not respond to coordinated disclosure, meaning no patch exists and no vendor-confirmed mitigations are available.

Integer underflow in NASA cFS's cFE Software Bus module (versions up to 7.0.1) allows a network-reachable, low-privileged attacker to manipulate TotalMsgSize and HdrSize arguments in CFE_SB_GetUserDataLength, triggering a CWE-191 wrap-around that produces an incorrect message-length value. The resulting memory misread yields low-level confidentiality, integrity, and availability impacts on both the vulnerable system and downstream Software Bus consumers. No vendor patch exists - NASA did not respond to coordinated disclosure - and no public exploit or CISA KEV listing has been identified at time of analysis.

JSON path injection in AshSqlite (0.1.2-rc.0 through 0.2.17) allows any attacker who can supply user-controlled input to a get_path/2 query segment to read nested JSON sub-fields that the application never intended to expose. The vulnerable AshSqlite.SqlImplementation code naively concatenates user-supplied segments with periods into a SQLite json_extract path, so a segment containing a dot (e.g., 'private.secret') descends two JSON levels instead of matching a single literal key. No public exploit has been identified and the vulnerability is absent from the CISA KEV catalog; a vendor patch is available targeting version 0.2.18.

Cleartext exposure of nested sensitive fields in Ash Paper Trail audit logs (versions 0.3.0-0.6.x) allows any principal with read access to the version resource table to recover credentials, tokens, or other sensitive values stored inside embedded resources, union types, or lists. The redaction logic in `maybe_redact_changes/3` and `AshPaperTrail.Resource.Changes.CreateNewVersion` only inspects top-level resource attributes for the `sensitive?` flag, never recursing into nested structures, so a parent attribute that is not itself marked sensitive silently passes its embedded sensitive children through to the version table in cleartext. No public exploit has been identified and the issue is not listed in CISA KEV; a vendor-released patch is available at version 0.7.0.

Cleartext storage of sensitive Ash resource attributes in AshPaperTrail versions 0.1.1 through 0.6.x allows any actor with read access to the generated version resource to recover plaintext values of fields marked `sensitive? true`. The library's `CreateVersionResource` transformer incorrectly derives the sensitivity flag for the `changes` map from the `ignore_attributes` exclusion list rather than from the actual tracked attributes, causing the map to always be declared `sensitive? false` and `public? true`, which bypasses Ash's built-in redaction and exposes sensitive values in API responses, logs, and inspect output. No public exploit is identified and no active exploitation is confirmed; a vendor patch was released in version 0.7.0.

The `qs.stringify` function in the qs Node.js query-string library throws an uncaught `TypeError` when serializing any object whose `constructor.isBuffer` property is truthy but not callable, enabling denial of service against applications that re-serialize attacker-controlled data. Express 4 (default query-parser) and body-parser with `extended: true` both parse incoming HTTP data using options that preserve the `constructor` key in output, meaning a crafted request body or query string can reach the vulnerable code path with no non-default configuration required on the target application. A working proof-of-concept is embedded in the CVE description; no CISA KEV listing exists at time of analysis.

Payment status workflow bypass in macrozheng mall up to version 1.0.3 allows authenticated remote attackers to manipulate the orderId parameter at the /order/paySuccess endpoint, potentially marking arbitrary orders as paid without completing actual payment. This CWE-841 business logic flaw directly threatens e-commerce transaction integrity - a proof-of-concept exists (CVSS 4.0 E:P), though no active exploitation is confirmed in CISA KEV. Notably, the vendor silently deleted the GitHub disclosure issue without providing any remediation, leaving no patch available at time of analysis.

Session termination via unsigned SAML LogoutRequest in pac4j-saml before 6.5.6 allows unauthenticated remote attackers to destroy any active SAML session by submitting a forged, unsigned LogoutRequest containing a guessed NameID (e.g., an email address used as the SAML subject identifier) when the IdP omits a SessionIndex. The root cause is that SAML2LogoutValidator.validateLogoutRequest() did not enforce signature validation in this code path, permitting the NameID alone to trigger session destruction without any cryptographic proof of IdP origin. No public exploit code is known and this is not listed in CISA KEV; however, the attack is low-complexity and entirely unauthenticated per the CVSS 4.0 vector.

Authentication bypass in pac4j-oidc before 6.5.6 allows remote unauthenticated attackers to establish authenticated sessions by submitting OIDC callback requests carrying only a third-party access token, bypassing issuer, audience, nonce, and subject validation entirely. Applications built on the pac4j Java security framework that use OIDC for single sign-on are vulnerable to token substitution attacks from any attacker who holds a valid access token issued by the same identity provider for any other registered OAuth client. No public exploit code has been identified at time of analysis; vendor-released patch is available in version 6.5.6.

Account enumeration in Cockpit CMS before 2.14.1 exposes valid usernames through measurable response-time differences in the authentication check endpoint. When a submitted username matches an existing account, the application performs a full bcrypt hash comparison - an intentionally slow operation - whereas non-existent accounts return immediately without any hash computation, creating a statistically detectable timing delta. Unauthenticated remote attackers can exploit this by issuing repeated authentication probes and measuring latency, building a list of valid accounts to target with credential stuffing or brute-force attacks. No public exploit code or CISA KEV listing has been identified at time of analysis, though a researcher advisory (MFC-2026-001) exists.

Race condition in macrozheng mall's /order/submit endpoint (versions up to 1.0.3) allows authenticated remote attackers to exploit unsynchronized order state through concurrent HTTP request timing. The CVSS 4.0 vector (AV:N/AC:H/PR:L) confirms network reachability but high attack complexity and a required authenticated session, yielding limited integrity and availability impact. No public exploit code has been identified and the vendor deleted the associated GitHub issue without explanation, reducing transparency around scope and remediation.

Predictable API key generation in the Newsletters WordPress plugin (versions before 4.17) enables unauthenticated network-accessible attackers who successfully derive the key to perform privileged API operations - including adding or deleting subscribers and sending bulk emails. Exploitation requires the plugin's optional API feature to be enabled. A publicly available proof-of-concept exists via WPScan, though EPSS stands at 0.10% (1st percentile), indicating minimal observed exploitation at time of analysis and no CISA KEV listing.

Cleartext password disclosure in MariaDB Connector/R2DBC (org.mariadb:r2dbc-mariadb) prior to 1.4.1 allows a network-positioned attacker posing as a database server to harvest user credentials during authentication. The connector's AuthenticationPlugin interface lacked any requireSecure() gate, so plugins transmitting credentials in cleartext - mysql_clear_password and PAM/dialog - could be triggered by a forged AuthSwitchRequest over an unencrypted plain-TCP connection, causing the client to respond with the user's database password as raw bytes on the wire. No public exploit code has been identified and no KEV listing exists; the issue is fully patched in version 1.4.1.

MariaDB Connector/R2DBC prior to 1.4.1 hardcodes UTF-8 for all character encoding and decoding but fails to reject mid-session charset changes announced by the server via the OK-packet session-state-tracking mechanism. A hostile or man-in-the-middle server, or server-side constructs such as stored routines, triggers, or server configuration, can shift character_set_client to a non-UTF-8 encoding after connection initialization, causing the driver and server to interpret identical bytes under different encodings. This produces silent data corruption and a charset-confusion mismatch that can undermine byte-wise quoting and escaping, creating a pathway to SQL injection in applications that rely on driver-level escaping; no public exploit has been identified at time of analysis and the vendor-released patch is available in version 1.4.1.

Charset-confusion in MariaDB Connector/J (all branches prior to 2.7.14, 3.3.5, 3.4.3, and 3.5.9) allows a server-side character set change mid-session to silently decouple the driver's UTF-8 encoding assumption from the server's active encoding. Because the driver continues escaping SQL string literals as UTF-8 while the server parses incoming bytes under a different multi-byte encoding (e.g., GBK or BIG5), the mismatch can defeat byte-wise SQL quoting and enable SQL injection - a well-documented attack class for charset-confusion primitives. No public exploit has been identified and this CVE is not listed in CISA KEV at time of analysis.

MariaDB Connector/J exposes database account passwords in cleartext to on-path attackers or hostile servers when PAM (dialog) authentication is used over plain TCP. The driver's PAM handler (SendPamAuthPacketFactory, plugin name 'dialog') failed to override the requireSsl() gate that correctly protects its sibling mysql_clear_password plugin, inheriting a default value of false and thus omitting the secure-transport requirement. Under the default connector configuration (sslMode=DISABLE, restrictedAuth=null), a man-in-the-middle or rogue server can issue an Authentication Switch Request for the dialog plugin and receive the account password in cleartext, granting full credential reuse against the real database. No public exploit has been identified and the vulnerability is not listed in CISA KEV, but the attack mechanics are straightforward for any on-path attacker against affected deployments.

Non-constant-time authentication comparisons and plaintext logging of XRES* in free5GC's AUSF component (v1.4.4 and earlier) expose two distinct vulnerability classes under CWE-208. The 5G-AKA confirmation path writes the expected XRES* value to INFO-level application logs immediately before comparison, making authentication material directly readable by any principal with AUSF log access - operators, SIEM agents, log-collection sidecars, or compromised containers. Both 5G-AKA and EAP-AKA' confirmation paths use non-constant-time Go primitives (strings.EqualFold, bytes.Equal, ==) instead of crypto/subtle.ConstantTimeCompare, though the researcher's own PoC confirmed the timing signal is too small to distinguish from HTTP/SBI noise under standard network conditions. No public exploit or CISA KEV listing; patched in v1.4.5.

PAM dialog authentication in MariaDB Connector/Node.js discloses account passwords in cleartext when connections use plain TCP, because the SendPamAuthPacketFactory handler omitted the secure-transport gate that was already applied to the sibling mysql_clear_password plugin. Applications connecting to MariaDB with default settings (sslMode=DISABLE, restrictedAuth=null) over untrusted network paths are exposed to credential theft by any on-path attacker or rogue server that issues an Authentication Switch Request for the dialog plugin. No active exploitation or public exploit code has been identified; vendor-released patches are available across all active 3.x branches.

IBM Integrated Analytics System versions 1.0.0.0 through 1.0.31.0 fails to properly validate TLS certificates, enabling network-positioned attackers to conduct man-in-the-middle attacks and intercept sensitive data in transit. IBM has confirmed the issue and released a patch via advisory node/7285149. No public exploit code or CISA KEV listing has been identified at time of analysis; however, the network-accessible attack vector with no authentication requirement raises the relevance for deployments where the system communicates across untrusted network segments.

IBM Integrated Analytics System versions 1.0.0.0 through 1.0.31.0 employs cryptographic algorithms below acceptable security standards, exposing highly sensitive data to decryption by a network-positioned attacker. The CVSS vector (AV:N/AC:H/PR:N/UI:N) indicates network exploitation without authentication but requires high attack complexity, consistent with a passive interception or man-in-the-middle scenario. No public exploit code has been identified, and IBM has released a remediation patch via support advisory 7285147.

Memory corruption in the TP-Link TL-WR841N v14 embedded HTTP service allows an unauthenticated attacker with adjacent network access to trigger a buffer overflow by submitting a crafted multipart/form-data request containing an oversized boundary parameter. The confirmed impact is limited to undefined application behavior resulting from process memory corruption; TP-Link's own advisory and the CVE description both explicitly state that arbitrary code execution, information disclosure, and denial-of-service have not been demonstrated, despite those labels appearing in the CVE tags. No public exploit code has been identified at time of analysis, and this CVE is not listed in CISA's Known Exploited Vulnerabilities catalog.

CSV injection in the MongoDB MongoSQL Transition Readiness Tool allows a low-privileged cluster user to embed spreadsheet formula directives inside database or collection names, which are written unsanitized into generated CSV reports. When an operator opens the report in a spreadsheet application such as Microsoft Excel or LibreOffice Calc, the formula executes on the operator's workstation, potentially exfiltrating report contents to an attacker-controlled endpoint or triggering external content retrieval. No public exploit code or CISA KEV listing has been identified at time of analysis; exploitation is constrained by the requirement for both cluster write access and an operator who opens the file in a formula-evaluating spreadsheet.

Graylog Server's system catalog entity titles API endpoint leaks protected database fields - including user password hashes - to authenticated requesters who craft custom field-selection parameters. PR:L authentication is required, and permission checks are partially enforced: regular users are limited to their own password hash, but any user holding an admin role can extract password hashes for every account in the system. No public exploit or CISA KEV listing has been identified; vendor-released patch 7.1.4 is available and is the only remediation.

Copilot Chat in Microsoft Edge (Chromium-based) exposes a race condition that enables an authorized, low-privileged attacker to disclose information across a component scope boundary over the network. The flaw arises from improper synchronization of concurrent access to a shared resource within the Copilot Chat feature, producing partial confidentiality and, per the official CVSS vector, limited integrity exposure. No public exploit code has been identified at time of analysis, and this vulnerability does not appear in the CISA Known Exploited Vulnerabilities catalog.

Heap out-of-bounds read and stack out-of-bounds access in GIMP's file-psd plugin allow an attacker to crash the application or disclose limited memory contents by convincing a user to open a specially crafted PSD image. The flaw affects GIMP as shipped in Red Hat Enterprise Linux 6 through 9 and stems from missing validation of the channel-count parameter during PSD parsing. No active exploitation has been identified; the attack requires local file delivery and deliberate user interaction, significantly constraining real-world risk.

StarRocks through version 4.0.13 exposes complete query history for all users to any authenticated low-privilege user via the unguarded query_detail REST endpoint. The endpoint returns full SQL text, execution plans, and profiling data without filtering by the requesting user's identity, meaning statements containing embedded credentials - connection strings, passwords passed as query parameters - are fully readable by any logged-in account. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog, but the low authentication bar (any valid account) and high confidentiality impact make this a meaningful lateral-movement and credential-harvesting risk in multi-tenant or shared StarRocks deployments.

Heap out-of-bounds read in GIMP's file-pvr plugin exposes users of Red Hat Enterprise Linux 6 through 9 to application crashes and limited heap memory disclosure when opening a crafted PVR image file. The VQ (Vector Quantization) compressed-texture decoder omits mandatory bounds validation, allowing a malicious image to read beyond allocated heap regions. Impact is primarily denial of service via crash, with a secondary low-severity information disclosure path; no public exploit code and no CISA KEV listing are associated with this issue at time of analysis.

Nonce reuse in wolfEngine's AES-CCM implementation for TLS 1.2 and DTLS 1.2 allows a network-positioned adversary to recover plaintext across records and forge authentication tags within a session. The root defect is that wolfEngine reads the explicit CCM nonce from the uninitialized record input buffer rather than deriving it from the TLS sequence number in the Additional Authenticated Data, producing a constant nonce for every record under the same key. Exposure is sharply constrained: AES-CCM cipher suites must be explicitly selected (non-default), only wolfEngine is affected (wolfProvider is not), and TLS 1.3 is entirely outside scope. No public exploit or CISA KEV listing exists at time of analysis; the vendor-released fix is wolfEngine 1.4.1.

Capture-replay authentication bypass in the Forminator WordPress plugin (versions up to and including 1.57.1) allows unauthenticated network-accessible attackers to achieve low-level integrity impact against affected installations. Reported by Patchstack under CWE-294, the flaw enables replay of captured authentication or nonce tokens, potentially allowing unauthorized form actions or integrity-affecting operations without valid credentials. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.

Heap out-of-bounds read in GIMP's file-ico plugin allows a local attacker to crash GIMP or leak limited heap memory contents by delivering a specially crafted ICO image file to a victim user. Affected packages span Red Hat Enterprise Linux 6 through 9. No public exploit code or CISA KEV listing exists at time of analysis, but the user-interaction requirement (opening a malicious file) is the primary delivery mechanism and a realistic social-engineering target in image-processing workflows.

Heap out-of-bounds read in GIMP's file-iff plugin allows a local attacker to crash the application or disclose limited heap memory contents by delivering a specially crafted IFF/ILBM image file. The flaw stems from missing validation of HAM row size when the number of color planes (nPlanes) is zero, causing a size mismatch that bypasses memory bounds checking. No active exploitation has been confirmed (not in CISA KEV) and no public exploit code has been identified at time of analysis.

Log forging in morgan HTTP request logger middleware for Node.js (all versions prior to 1.12.0) allows unauthenticated remote attackers to inject Unicode line separator characters - U+0085 (Next Line), U+2028 (Line Separator), and U+2029 (Paragraph Separator) - into log output via attacker-controlled token values such as the Basic auth username surfaced through the remote-user token. This causes Unicode-aware downstream log processors and SIEM pipelines to split a single HTTP request record into multiple logical entries, enabling false log injection and audit trail manipulation. This is an incomplete-fix follow-up to CVE-2026-5078, which addressed only ASCII control characters; no public exploit has been identified at time of analysis.

Sensitive data exposure in Le-yan's Medical Practice Management System enables access to confidential medical or patient data through URL query string parameters that persist in browser history and server or proxy log files (CWE-598). The application transmits sensitive values via HTTP GET parameters rather than POST body or secure headers, causing this data to be recorded in multiple secondary storage locations outside the intended session scope. No public exploit code has been identified at the time of analysis, but the attack class requires minimal technical sophistication once access to affected log or history files is established; medical data sensitivity elevates real-world impact beyond what the base CVSS score alone suggests.

Uncontrolled recursion between Elixir's charlist inspection path and the error-message rescue clause in List.to_string/1 and List.to_charlist/1 can exhaust a BEAM node's memory when an attacker controls list data reaching those functions. A crafted list whose printable prefix exceeds the 4096-element printable_limit but which carries an invalid element beyond that threshold bypasses the ASCII classification check, triggers ArgumentError in IO.chardata_to_string/1, and then recurses infinitely through the rescue clause because the inner inspect/1 call is not in tail position - every frame is retained on the process heap. No public exploit has been identified at time of analysis; vendor-released patches are available as Elixir 1.18.5, 1.19.6, and 1.20.4.

Cross-user data disclosure in SvelteKit (npm/@sveltejs/kit versions 2.38.0 through 2.60.0) stems from a race condition in the query.batch() API that can cause concurrent HTTP requests from different authenticated users to merge under a single shared request context. Successful exploitation allows one user to receive response data belonging to another user's simultaneous session, including potentially sensitive application state. Vendor-released patch version 2.60.1 is available; no active exploitation has been confirmed and no public exploit code has been identified at time of analysis.

Prototype pollution in SvelteKit's remote form functions allows network-accessible attackers to remove methods from JavaScript object prototypes by supplying crafted, user-controlled file input path names. Affected versions are all @sveltejs/kit releases up to and including 2.69.0; the vendor released a fix in 2.69.1. No active exploitation is documented in CISA KEV, and no public exploit code has been identified at time of analysis, though the vulnerability is network-reachable and requires no authentication from the attacker.

Arbitrary file write outside the worktree boundary in gix-worktree-state (part of gitoxide) before 0.33.0 on Windows enables an attacker-controlled repository to overwrite files at arbitrary paths on a victim's filesystem. The flaw manifests when gix_worktree_state::checkout() performs an incremental materialization: a malicious repo first places a symlink entry at path P pointing outside the worktree, then a subsequent incremental checkout of a regular-file entry at the same path follows the Windows reparse point and writes attacker-supplied blob content through the link. No public exploit code is identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.

Stale public share links in filebrowser through 2.63.23 can silently redirect to unrelated files uploaded after a rename operation, unexpectedly exposing new content to anyone holding the original link. The defect (CWE-459, Incomplete Cleanup) arises because share records are keyed by file path rather than a file identifier - deletion triggers cleanup, but rename does not, leaving the share dormant. No public exploit or CISA KEV listing exists at time of analysis, and the CVSS 4.0 score of 2.3 reflects the multi-step preconditions required, but the confidentiality risk is real for deployments where multiple users share create permissions on overlapping directories.

Stale public share links in File Browser 2.63.6-2.63.23 expose subsequently uploaded content to unauthenticated network access after a privileged user deletes another user's shared file without triggering proper link invalidation. Because the surviving share URL continues to resolve to whatever is later placed at the same storage path, an attacker who retains or discovers the original link can retrieve entirely unrelated files without authentication. No public exploit code is identified at time of analysis, and the CVSS 4.0 score of 2.3 reflects the constrained, multi-step preconditions required.

Unauthenticated information disclosure in WWBN AVideo through version 30.0 exposes user registration statistics via two unprotected PHP endpoints. The report4.json.php and report4.1.json.php files return daily and cumulative user-registration counts to any remote requester without authentication or session validation. No public exploit code has been identified at time of analysis and this vulnerability is not listed in the CISA KEV catalog; however, its trivial exploitation path and network accessibility make it easy for any actor who can reach the server to enumerate platform growth data.

Timing side-channel in OX Dovecot Pro and CE exposes the length of configured doveadm passwords and API keys to adjacent-network attackers who can send repeated unauthenticated requests and measure response latency with high precision. The secret value itself is never disclosed - only its length - which marginally reduces brute-force search space. No active exploitation is identified and no public exploit exists; the vendor-assigned CVSS score of 3.1 accurately reflects the constrained attack surface and limited practical impact.

Memory disclosure in OX Dovecot Pro and OX Dovecot CE exposes uninitialized server process memory to authenticated IMAP users who send a malformed URLFETCH command. The IMAP URLAUTH extension's error-handling path fails to sanitize its response buffer, returning raw memory contents to the requesting client that may include session tokens, cached credentials, or message data from co-resident sessions. No active exploitation has been identified and no public exploits are known, though the low attack complexity for authenticated users makes insider threats and compromised accounts realistic vectors.

IMAP compression in OX Dovecot Pro and CE enables a CRIME/BREACH-class side-channel attack where shared compression state across session responses leaks information about mailbox contents. An adversary who can both send mail to a target user and observe the byte sizes of that user's IMAP traffic can use response-size variations to confirm whether a small message body matches a guessed candidate text. No public exploits are known and the attack has not been confirmed as actively exploited; arbitrary content recovery was not demonstrated, bounding real-world impact to oracle-style guess confirmation against short messages.

Authenticated availability disruption in OX Dovecot Pro and OX Dovecot CE allows any valid credential holder to crash the imap-hibernate service by opening many concurrent connections and sending malformed IMAP commands, triggering an intermittent out-of-bounds read (CWE-125). The crash terminates the imap-hibernate process, dropping hibernated IMAP sessions for co-hosted users and degrading service availability. No public exploit code is known and the vulnerability is not listed in CISA KEV; however, the low attack complexity means any authenticated user on a shared mail platform could attempt disruption.

In the Linux kernel, the following vulnerability has been resolved: mm: mglru: fix stale batch updates after memcg reparenting The mglru page table walker batches per-generation size deltas in walk->nr_pages while walking page tables without holding the lruvec lock. The reset_batch_size() later folds those deltas into walk->lruvec under the lruvec lock. The page table walker can run concurrently with the memcg reparenting path as follows: CPU0 CPU1 ==== ==== walk_mm --> walk_page_range --> update_batch_size --> walk->nr_pages += delta mem_cgroup_css_offline --> memcg_reparent_objcgs --> lock lruvec lru_gen_reparent_memcg --> reparent child folios to parent unlock lruvec lock lruvec reset_batch_size --> child lrugen->nr_pages += delta This will trigger the following warning in lru_gen_exit_memcg(): VM_WARN_ON_ONCE(memchr_inv(lruvec->lrugen.nr_pages, 0, sizeof(lruvec->lrugen.nr_pages))); And the user-visible impact of underestimated nr_pages in MGLRU was premature OOMs because MGLRU does not try to reclaim memory when nr_pages reaches zero, but there are still more pages. To fix it, make reset_batch_size() check CSS_DYING under RCU before flushing the pending batch. A non-dying memcg keeps the original lruvec stable against RCU-delayed offlining; a dying memcg redirects the deltas to the first non-dying ancestor.

In the Linux kernel, the following vulnerability has been resolved: igc: remove napi_synchronize() in igc_down() When an AF_XDP zero-copy application is killed abruptly, the XSK pool is torn down but NAPI keeps polling. igc_clean_rx_irq_zc() then returns the full budget on every poll, so napi_complete_done() never clears NAPI_STATE_SCHED. igc_down() calls napi_synchronize() before napi_disable(), so it spins forever waiting for that bit and the interface never goes down. Drop the napi_synchronize() and let napi_disable() do the job -- it sets NAPI_STATE_DISABLE, which forces the stuck poll to complete. Reorder it ahead of igc_set_queue_napi() so the NAPI mapping is cleared only after polling has stopped, matching the recent igb fix b1e067240379.

In the Linux kernel, the following vulnerability has been resolved: power: supply: max17040: handle missing status supplier MAX17040 does not report charger state itself, so the driver forwards POWER_SUPPLY_PROP_STATUS to a supplier power supply. If no supplier is registered, power_supply_get_property_from_supplier() returns -ENODEV and leaves the output value untouched. max17040_get_property() currently ignores that error and returns success, so userspace can read an uninitialized status value from the battery power supply. This happens on systems that use the fuel gauge without a charger supplier relationship in firmware. Return POWER_SUPPLY_STATUS_UNKNOWN when no supplier provides STATUS, and propagate other supplier lookup errors.

In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Fix missing mem scrub at clear key import in cca_clr2cipherkey() The helper function _ip_cprb_helper() uses internal buffer memory for building and processing CPRBs. After use this buffer was never scrubbed which could lead to leaving for example clear key material in memory which could be exposed via tricky reuse of this same memory. Extend the _ip_cprb_helper() function with another parameter 'scrub' used to steer scrubbing of this buffer. So now the caller has the opportunity to decide if scrubbing is needed or not. Extend the clear key to secure key token import process in function cca_clr2cipherkey() to tell the helper function from above to scrub the cprb buffer when the clear key value is part of the request data. Add explicit scrubbing on return from function cca_clr2cipherkey() for the random EXOR buffer and the cprb buffer. Overall this cleans the internal used buffer in case of clear key import to prevent sensitive data to get exposed.

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: check if dml21_add_phantom_plane() is successful Verify that the phantom plane was allocated to avoid a later segfault. (cherry picked from commit 5adb54abe5a8e82cbff7f8806db30a5f4924329f)

In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Avoid double-deactivate of IRQs in the nested context In the nested state, the physical interrupt has already been deactivated through the HW bit in the LR. The extra deactivation would be harmless but can hit an errata case on AmpereOne, so avoid it here. On AmpereOne, deactivating a physical interrupt through ICC_DIR_EL1 or ICC_EOIR1_EL1 (depending on EOImode) which is not active, but is the highest priority pending interrupt causes the cpu to lose the interrupt pending state and also prevents the delivery of future interrupts.

In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix double free of wq, engine, and group structs The release callbacks for wq, engine, and group devices (idxd_conf_wq_release, idxd_conf_engine_release, idxd_conf_group_release) each call kfree() on the enclosing struct. The setup error paths and cleanup functions also call kfree() explicitly after put_device(), producing a double free whenever put_device() drops the reference count to zero and fires the release. In the setup functions, device_initialize() is called before device_add(), so the reference count is exactly 1 at the error sites. put_device() unconditionally fires the release, which frees the struct; the subsequent explicit kfree() then operates on freed memory. For idxd_setup_wqs(), the wq release callback also owns opcap_bmap and wqcfg. The error unwind additionally freed those fields explicitly before calling put_device(), causing further double frees on both. Remove the redundant explicit kfree() calls from all setup error paths and cleanup functions for wq, engine, and group structs, delegating sole ownership of those allocations to the release callbacks.

In the Linux kernel, the following vulnerability has been resolved: hwmon: (sht3x) Fix unaligned accesses Sashiko reports: In sht3x_update_client(), the 16-bit temperature and humidity values are extracted from a stack-allocated byte array using be16_to_cpup(). The pointers passed to this function are calculated as buf and buf + 3. Since the difference between the two pointers is an odd number of bytes, at least one of them is guaranteed to be at an unaligned offset. This will trigger an alignment fault on strict-alignment architectures such as ARMv5 or SPARC, resulting in a kernel panic. Fix the problem by using get_unaligned_be16() instead of be16_to_cpup(), and put_unaligned_be16() instead of cpu_to_be16().

In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Initialize hba->rpmbs list in ufshcd Initialize the hba->rpmbs list in ufshcd_alloc_host() to prevent NULL pointer dereference in the device teardown path if ufs_rpmb_probe() fails.

In the Linux kernel, the following vulnerability has been resolved: riscv: drop __init from vec_check_unaligned_access_speed_all_cpus This function runs within a kthread and need not necessarily finish before system finishes boot and free_initmem() unmaps the .init.text section. This function makes calls to SBI for probing unaligned access speed, and if this is slow for some reason (say some debug prints were added to SBI), the kthread can still be running at this point and result in an instruction page fault when trying to fetch from the freed region. [ 25.642087] Unable to handle kernel paging request at virtual address ffffffff80a04ef8 [ 25.646694] Current vec_check_unali pgtable: 4K pagesize, 48-bit VAs, pgdp=0x00004000316e9000 [ 25.653170] [ffffffff80a04ef8] pgd=000010004be7e401, p4d=000010004be7e401, pud=000010004be7e001, pmd=000010000c3000e3 [ 25.661244] Oops [#1] [ 25.662997] Modules linked in: [ 25.665357] CPU: 3 UID: 0 PID: 42 Comm: vec_check_unali Not tainted 7.0.0-tt-blackhole-asrinivasan-00007-g30ff73f18211 #570 PREEMPTLAZY [ 25.674669] Hardware name: Tenstorrent Blackhole (DT) [ 25.678545] epc : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.683458] ra : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.688372] epc : ffffffff80a04ef8 ra : ffffffff80a04ef8 sp : ffff8f8000203e20 [ 25.693874] gp : ffffffff814dc168 tp : ffffaf8001ad9900 t0 : 0000000000000000 [ 25.699401] t1 : fffffffffffffff0 t2 : ffffaf8001ad9a10 s0 : ffff8f8000203e30 [ 25.704912] s1 : ffffaf80018dc780 a0 : 0000000000000000 a1 : 0000000000000002 [ 25.710407] a2 : 00000000000001f0 a3 : 0000000000000018 a4 : 0000000000000000 [ 25.715917] a5 : 0000000000000000 a6 : ffffaf8001c03d98 a7 : ffffaf8001c03e30 [ 25.721419] s2 : ffff8f8000023c98 s3 : ffffaf8001aa1240 s4 : ffffffff80a04ee0 [ 25.726937] s5 : 0000000000000000 s6 : 0000000000000000 s7 : 0000000000000000 [ 25.732450] s8 : 0000000000000000 s9 : 0000000000000000 s10: 0000000000000000 [ 25.737944] s11: 0000000000000000 t3 : 0000000000000002 t4 : 0000000000000402 [ 25.743481] t5 : 0000000000000040 t6 : 0000000000000004 ssp : 0000000000000000 [ 25.749024] status: 0000000200000120 badaddr: ffffffff80a04ef8 cause: 000000000000000c [ 25.755060] [<ffffffff80a04ef8>] vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.760964] [<ffffffff80047a10>] kthread+0xd8/0xfc [ 25.764660] [<ffffffff80010c48>] ret_from_fork_kernel+0x18/0x1c4 [ 25.769220] [<ffffffff80895fe6>] ret_from_fork_kernel_asm+0x16/0x18 [ 25.774018] Code: cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc (cccc) cccc Drop __init from its signature so that this doesn't happen.

In the Linux kernel, the following vulnerability has been resolved: iommufd/viommu: Release the igroup lock on the vdevice_size error path iommufd_vdevice_alloc_ioctl() takes idev->igroup->lock, then validates the driver's vdevice_size against the core structure size with a WARN_ON_ONCE. On failure that guard jumps to out_put_idev, below out_unlock_igroup, so it skips the mutex_unlock(), leaving the igroup lock held and deadlocking the next vDEVICE operation on that group. Jump to out_unlock_igroup instead.

In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1]

In the Linux kernel, the following vulnerability has been resolved: bpf: Disable xfrm_decode_session hook attachment BPF LSM programs can currently attach to xfrm_decode_session(). That hook may return an error, but security_skb_classify_flow() calls it from a void path and triggers BUG_ON() if an error is returned. Disable BPF attachment to the hook to prevent a BPF LSM program from turning packet classification into a full panic.

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: LAG, MPESW, Fix missing complete() on devcom error mlx5_mpesw_work() returned without calling complete() when mlx5_lag_get_devcom_comp() returned NULL. A caller that queued the work and waited on mpesww->comp would block indefinitely. Funnel the early-return path through a new "complete" label so the waiter is always woken.

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: sco: Fix a race condition in sco_sock_timeout() sco_sock_timeout() runs asynchronously and lock_sock(sk). If the socket is closing while the timer is running, it holds the same lock (lock_sock(sk)) twice, leading to a deadlock. CPU 0 CPU 1 ==================== ====================== sco_sock_close() sco_sock_timeout() lock_sock(sk) // <-- LOCK __sco_sock_close() sco_chan_del() sco_conn_put() sco_conn_free() disable_delayed_work_sync() lock(sk) // <-- SAME LOCK Fix this by moving disable_delayed_work_sync() outside of lock_sock(sk), ensuring that no lock_sock(sk) is held before sco_sock_timeout(). Lockdep splat: WARNING: possible circular locking dependency detected 6.13.0-rc4 #7 Not tainted syz-executor292/9514 is trying to acquire lock: ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_lock_acquire sect/v6.13-rc4/./include/linux/rcupdate.h:337 [inline] ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_read_lock sect/v6.13-rc4/./include/linux/rcupdate.h:849 [inline] ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4137 [inline] ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: __flush_work+0xd1/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195 but task is already holding lock: ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline] ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: sco_sock_close+0x25/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:524 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}: lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849 lock_sock_nested+0x48/0x130 sect/v6.13-rc4/net/core/sock.c:3622 lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline] sco_sock_timeout+0xbe/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:158 process_one_work sect/v6.13-rc4/kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa99/0x18f0 sect/v6.13-rc4/kernel/workqueue.c:3310 worker_thread+0x8a9/0xd80 sect/v6.13-rc4/kernel/workqueue.c:3391 kthread+0x2c6/0x360 sect/v6.13-rc4/kernel/kthread.c:389 ret_from_fork+0x4e/0x80 sect/v6.13-rc4/arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 sect/v6.13-rc4/arch/x86/entry/entry_64.S:244 -> #0 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}: check_prev_add sect/v6.13-rc4/kernel/locking/lockdep.c:3161 [inline] check_prevs_add sect/v6.13-rc4/kernel/locking/lockdep.c:3280 [inline] validate_chain+0x1888/0x5760 sect/v6.13-rc4/kernel/locking/lockdep.c:3904 __lock_acquire+0x13b4/0x2120 sect/v6.13-rc4/kernel/locking/lockdep.c:5226 lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849 touch_work_lockdep_map sect/v6.13-rc4/kernel/workqueue.c:3909 [inline] start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4163 [inline] __flush_work+0x70f/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195 __cancel_work_sync sect/v6.13-rc4/kernel/workqueue.c:4351 [inline] disable_delayed_work_sync+0xbb/0xf0 sect/v6.13-rc4/kernel/workqueue.c:4514 sco_conn_free sect/v6.13-rc4/net/bluetooth/sco.c:95 [inline] kref_put sect/v6.13-rc4/./include/linux/kref.h:65 [inline] sco_conn_put+0x18f/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:107 sco_chan_del+0xe2/0x210 sect/v6.13-rc4/net/bluetooth/sco.c:236 sco_sock_close+0x8f/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:526 sco_sock_release+0x62/0x2d0 sect/v6.13-rc4/net/blueto ---truncated---

In the Linux kernel, the following vulnerability has been resolved: hwmon: (occ) unregister sysfs devices outside occ lock occ_active(false) and occ_shutdown() unregister sysfs-backed devices while occ->lock is held. hwmon_device_unregister() and sysfs_remove_group() can wait for active sysfs callbacks to drain, and those callbacks can enter the OCC update path and try to take occ->lock again. That gives the unregister paths the lock ordering occ->lock -> sysfs callback drain, while a callback has the opposite edge sysfs callback -> occ->lock. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the real unregister and callback carrier: occ_shutdown() hwmon_device_unregister() occ_show_temp_1() occ_update_response() Lockdep reported the circular dependency with occ_shutdown() already holding the OCC mutex and hwmon_device_unregister() waiting on the sysfs side: WARNING: possible circular locking dependency detected ... (sysfs_lock) ... at: hwmon_device_unregister+0x12/0x30 [vuln_msv] ... (&test_occ.lock) ... at: occ_shutdown.constprop.0+0xe/0x40 [vuln_msv] occ_update_response.isra.0+0xb/0x20 [vuln_msv] occ_show_temp_1.constprop.0.isra.0+0x23/0x40 [vuln_msv] *** DEADLOCK *** Serialize hwmon registration and removal with a separate hwmon_lock. Under that lock, detach occ->hwmon and update occ->active while occ->lock is held so concurrent OCC state changes still see a stable state, then drop occ->lock before calling hwmon_device_unregister(). Remove the driver sysfs group before taking occ->lock in occ_shutdown(), so draining the driver attributes cannot wait while the OCC mutex is held. Also make OCC update callbacks return -ENODEV after deactivation, so callbacks that already passed sysfs active protection do not poll the hardware after teardown has detached the hwmon device.

In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: defer reset until cmd_mutex is unlocked vub300_cmndwork_thread() holds cmd_mutex while it sends a command and waits for the command response. If the response wait times out, __vub300_command_response() kills the command URBs and then synchronously resets the USB device through usb_reset_device(). That reset path re-enters the driver through vub300_pre_reset(), which also takes cmd_mutex. The worker therefore tries to acquire the same mutex recursively while it is still holding it from the command path. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the real worker and timeout/reset carrier: vub300_cmndwork_thread() __vub300_command_response() usb_lock_device_for_reset() usb_reset_device() vub300_pre_reset() Lockdep reported the same-task recursive acquisition on cmd_mutex: WARNING: possible recursive locking detected ... (&test_vub300.cmd_mutex) ... at: usb_reset_device... [vuln_msv] ... (&test_vub300.cmd_mutex) ... at: vub300_cmndwork_thread+0x12/0x20 [vuln_msv] Workqueue: vub300_cmd_wq vub300_cmndwork_thread [vuln_msv] *** DEADLOCK *** Return a flag from __vub300_command_response() when the timeout path needs a device reset, then perform the reset after vub300_cmndwork_thread() has cleared the in-flight command state and dropped cmd_mutex. The reset is still attempted before mmc_request_done(), preserving the existing request completion ordering while avoiding the recursive lock.

In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Treat zero-length cert chain as query for blob lengths When handling a PDH export, treat a zero-length userspace cert chain buffer as a request to query the length of the relevant blobs. Failure to account for the zero-length buffer trips a BUG_ON() when running with CONFIG_DEBUG_VIRTUAL=y due to trying to get the physical address of the ZERO_SIZE_PTR (returned by kzalloc() on the bogus allocation). kernel BUG at arch/x86/mm/physaddr.c:28 ! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 30 UID: 0 PID: 28580 Comm: syz.2.18 Kdump: loaded Tainted: G W 6.18.16-smp-DEV #1 NONE Tainted: [W]=WARN Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 RIP: 0010:__phys_addr+0x16a/0x180 arch/x86/mm/physaddr.c:28 RSP: 0018:ffffc9008329fc80 EFLAGS: 00010293 RAX: ffffffff8179110a RBX: 0000778000000010 RCX: ffff8884e6992600 RDX: 0000000000000000 RSI: 0000000080000010 RDI: 0000778000000010 RBP: ffffc9008329fdf0 R08: 0000000000000dc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff126d297 R12: dffffc0000000000 R13: 1ffff92010653fc8 R14: 0000000080000010 R15: dffffc0000000000 FS: 0000555556bec9c0(0000) GS:ffff88aa4ce1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd3159e7000 CR3: 00000004fbc44000 CR4: 0000000000350ef0 Call Trace: <TASK> [<ffffffff853d3869>] sev_ioctl_do_pdh_export+0x559/0x7a0 drivers/crypto/ccp/sev-dev.c:2308 [<ffffffff853d1fdd>] sev_ioctl+0x2cd/0x480 drivers/crypto/ccp/sev-dev.c:2556 [<ffffffff82549ebc>] vfs_ioctl fs/ioctl.c:52 [inline] [<ffffffff82549ebc>] __do_sys_ioctl fs/ioctl.c:598 [inline] [<ffffffff82549ebc>] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:584 [<ffffffff8630115f>] do_syscall_x64 arch/x86/entry/syscall_64.c:64 [inline] [<ffffffff8630115f>] do_syscall_64+0x9f/0xf40 arch/x86/entry/syscall_64.c:98 [<ffffffff81000136>] entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fd3158eac39 </TASK> Thankfully, the bug is benign outside of CONFIG_DEBUG_VIRTUAL=y as getting the physical address is just arithmetic, and the PSP errors out before trying to write to the garbage address (which it must, otherwise querying the blob lengths would clobber memory at pfn=0).

In the Linux kernel, the following vulnerability has been resolved: media: atomisp: gc2235: fix UAF and memory leak gc2235_probe() handles its error paths incorrectly. If media_entity_pads_init() fails, gc2235_remove() is called, which tears down the subdev and frees dev, but then still falls through to atomisp_register_i2c_module(). This results in use-after-free. If atomisp_register_i2c_module() fails, the media entity and control handler are left initialized and dev is leaked. gc2235_remove() unconditionally calls media_entity_cleanup() and v4l2_ctrl_handler_free(), but these are not initialized at every error path in gc2235_probe(). Replace gc2235_remove() calls in the probe error paths with explicit unwind labels that free only the resources initialized at each point of failure, in reverse order of initialization.

In the Linux kernel, the following vulnerability has been resolved: pinctrl: spacemit: fix NULL check in spacemit_pin_set_config spacemit_pin_set_config() looks up the per-pin descriptor with spacemit_get_pin() then checks the wrong variable for failure: const struct spacemit_pin *spin = spacemit_get_pin(pctrl, pin); ... if (!pin) return -EINVAL; reg = spacemit_pin_to_reg(pctrl, spin->pin); pin is an unsigned int pin id, where 0 (GPIO_0 / gmac0_rxdv on K3) is a valid pin, so rejecting it here drops the PAD config write for the first pin of every group. On K3 Pico-ITX the GMAC RGMII group lists pin 0 as its first entry, so its drive-strength / bias configuration was silently ignored. The intended guard is against spacemit_get_pin() returning NULL when the pin id isn't in the SoC's pin table. Check spin instead, which both restores PAD setup for pin 0 and prevents a NULL deref on spin->pin.

In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix warning in poll cq direct mode CQs allocated by ib_alloc_cq() always have a comp_handler. Though in direct mode this handler is never expected to be called, it is still called when the driver is reset, triggering the following WARN_ONCE(): Call trace: ib_cq_completion_direct+0x38/0x60 hns_roce_cq_completion+0x54/0x90 (hns_roce_hw_v2] hns_roce_handle_device_err+Ox1c8/0x340 [hns_roce_hw_v2] hns_roce_hw_v2_uninit_instance.constprop.0+0x34/0x70 [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify+0xc4/0xe0 [hns_roce_hw_v2] hclge_notify_roce_client+0x60/0xbc [hclge] hclge_reset_rebuild+0x48/0x34c [hclge] hclge_reset_subtask+0xcc/0xec [hclge] hclge_reset_service_task+0x80/0x160 [hclge] hclge_service_task+0x50/0x80 (hclge] process_one_work+0x1cc/0x4d0 worker_thread+0x154/0x414 kthread+0x104/0x144 ret_from_fork+0x10/0x18

In the Linux kernel, the following vulnerability has been resolved: EDAC/igen6: Fix call trace due to missing release() When unloading the igen6_edac driver, there is a call trace: Device '(null)' does not have a release() function, it is broken and must be fixed. See Documentation/core-api/kobject.rst. WARNING: drivers/base/core.c:2567 at device_release+0x84/0x90, CPU#5: rmmod/127209 ... RIP: 0010:device_release+0x84/0x90 Call Trace: <TASK> kobject_put+0x8c/0x220 put_device+0x17/0x30 igen6_unregister_mcis+0xa2/0xe0 [igen6_edac] igen6_remove+0x82/0xb0 [igen6_edac] ... Fix the call trace by providing empty release() functions for the memory controller devices.

In the Linux kernel, the following vulnerability has been resolved: liveupdate: Reference count incoming FLB data Increment the incoming FLB refcount in liveupdate_flb_get_incoming() so that the FLB structure cannot be freed while the caller is actively using it. Add an additional liveupdate_flb_put_incoming() function so the caller can explicitly indicate when it is done using the FLB data. During a Live Update, a subsystem might need to hold onto the incoming File-Lifecycle-Bound (FLB) data for an extended period, such as during device enumeration. Incrementing the reference count guarantees that the data remains valid and accessible until the subsystem releases it, preventing future use-after-free bugs.