Information Disclosure

Information disclosure in Dell OpenManage Server Administrator (OMSA) managed nodes running versions prior to 11.1.0.3 stems from use of a broken or risky cryptographic algorithm in the product's network communication, which an unauthenticated remote attacker could leverage to expose limited information (CVSS 3.1: 3.7, AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N). The high attack-complexity metric indicates that realistic exploitation requires a privileged man-in-the-middle position on the path to the managed node or offline cryptanalysis of captured management traffic, not a single direct request, and there is no integrity or availability impact. No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV, consistent with the independent assessment that this is a genuinely low-priority exposure typically confined to internal or out-of-band management networks. Affected platforms include the Windows managed-node patch and managed-node builds for RHEL 8.10, RHEL 9.4, SLES 15, and Ubuntu 22.04.

Acer System Monitoring, the WebSocket-enabled helper bundled with NitroSense and PredatorSense on Acer Nitro and Predator laptops, is configured to bind its listener to all network interfaces rather than to localhost, so any host that can reach the port on the same network segment can talk to the service without authentication or user interaction. The consequences are limited - the assessed impact is confined to low-level confidentiality, integrity and availability effects (minor telemetry exposure or restricted interaction with the service) - and the issue is compounded only mildly by the fact that the utility must actually be installed and running on a reachable machine. This is a low-priority finding: no public exploit code exists, no confirmed active exploitation has been reported, and the vendor vector (CVSS 4.0 score 2.7) plus an independent assessment (CVSS 3.1 AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L) agree that practical exposure is realistically limited to an attacker on the same LAN, hotel or office Wi-Fi.

Authenticated WordPress users holding the Author role or above can export every comment stored on a site running the Comments Import & Export plugin before version 2.5.4, because the export routine performs no moderate_comments capability check and does not scope results to the caller's own content. Exposed data includes commenter email addresses, IP addresses, unapproved comment bodies and comment meta. Publicly available exploit code exists, but the weakness is gated behind a valid Author-level credential, so exposure is concentrated on multi-author sites or installations that permit author-level self-registration; the impact is confidentiality-only and bounded.

Forged email tracking links in the Newsletter WordPress plugin before 9.3.8 let an unauthenticated attacker who first recovers the plugin's weakly generated signing key offline obtain any subscriber's session token and then read or modify that subscriber's stored personal data. The root cause is a signing key generated with insufficient entropy combined with tracking links signed by an unkeyed hash, which makes offline key recovery practical rather than dependent on a leaked secret; publicly available exploit code exists. Rated CVSS 4.8 (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N), the issue is real but moderate: exploitation requires the tracking feature to be in use and a successful offline key-recovery step, and the impact per forged link is bounded to a single subscriber with no code execution or availability loss.

Information disclosure in the LearnPress WordPress plugin before 4.4.7 allows unauthenticated remote attackers to retrieve the correct answer for every option of a quiz question, along with the instructor's accompanying explanation, from any course configured to be taken without enrolling. Exploitation is remote and requires no authentication, no user interaction and no special client, but it is gated by a non-default course setting (enrollment-free access), which is why the vendor and our assessment rate the attack complexity as high and the overall CVSS at 3.7. Publicly available exploit code exists (WPScan published the vulnerability write-up), though there is no indication of confirmed active exploitation in CISA KEV; the practical harm is limited to quiz answer-key and explanation disclosure, with no credential, PII or write-access impact.

Double decoding in the Canva Desktop deeplink handler (versions before 1.125.0) lets an unauthenticated attacker who convinces a user to open a crafted custom-URI deeplink cause the application to load arbitrary same-origin content within that user's session. The flaw (CWE-174) yields limited integrity impact only, with no confidentiality or availability effect, and exploitation requires user interaction (UI:R). No public exploit code or confirmed active exploitation has been identified at time of analysis (no CISA KEV entry; no EPSS score supplied), and the vendor has released a fix in v1.125.0.

Unauthenticated attackers can write to the WordPress database option ai1wm_auth_header in All-in-One WP Migration and Backup versions up to 7.110 by sending a crafted Authorization: Basic header to admin-ajax.php or admin-post.php, because the plugin's Ai1wm_Main_Controller::init() method on the admin_init hook reads PHP_AUTH_USER and PHP_AUTH_PW without authentication or nonce checks and stores them as reversible base64. This integrity-only issue (CVSS 5.3) allows overwriting the stored credential with attacker-chosen values, and in environments using WordPress Application Passwords, legitimate credentials sent to /wp-admin/ are silently captured into the database, though extracting them requires separate read access. No public exploit code or active exploitation has been identified at time of analysis.

Squid caching proxy is affected by an uncharacterized security issue tracked as CVE-2026-61642 and referenced upstream only as '[SQUID-2026:6]', surfaced through Ubuntu's distributor advisory ingestion. The provided data contains no vulnerability description text, no CVSS score or vector, and no CWE, so the impact, attack vector, and required proxy deployment mode (forward or reverse) cannot be determined; no public exploit code identified at time of analysis. Because exploitation prerequisites are unconfirmed and risk cannot be meaningfully scored, defenders running Squid - particularly Ubuntu-packaged Squid - should retrieve the upstream SQUID-2026:6 advisory and the corresponding Ubuntu security notice to establish affected versions and exposure before treating this as actionable.

Risk cannot be meaningfully assessed for CVE-2026-82374 because the published record contains no description, no CVSS score or vector, no CWE classification, no CPE data, and no reference set; the sole available signal is that the record was reported by the vendor Ubuntu. With no affected package, version range, deployment mode, or attack vector specified, it is not possible to state who is affected or what an attacker could achieve, and no public exploit identified at time of analysis. The CVE is not associated with CISA KEV status or an EPSS score in the supplied intelligence, so no conclusion about active exploitation or likelihood can be drawn.

Squid proxy software is affected by CVE-2026-62846, an issue tracked under the vendor's SQUID-2026:9 advisory identifier and reported into this dataset by the Ubuntu security team. No CVSS score, CVSS vector, CWE classification, or free-text technical description was supplied with the record, and the independent assessment concludes that risk cannot be meaningfully scored from the available input; therefore the specific impact, attack vector, and authentication prerequisites of this CVE remain unconfirmed. There is no indication of confirmed active exploitation (no CISA KEV entry) and no public exploit code identified at time of analysis, though the absence of exploit signals here reflects missing intelligence rather than a positive finding of unreachability.

An unspecified defect in an as-yet-unidentified Ubuntu package is tracked as CVE-2026-82373, but the record carries no description, no CVSS vector, no CWE classification, and no patch reference, so the affected component, attack surface, and impact cannot be established. The only confirmed signal is provenance: the entry was reported by the Ubuntu security team through its vendor CVE tracker. No public exploit code has been identified at time of analysis and there is no CISA KEV confirmation of active exploitation, so risk cannot be meaningfully assessed from the provided data.

Local privilege escalation in the NetworkManager VPNC plugin (network-manager-vpnc) lets a user who can create or modify a VPN connection profile inject newline/control characters into the generated vpnc configuration, causing a rogue directive such as 'Password helper' to be written and subsequently executed by the privileged helper when the connection is activated. The record is explicitly identified as an incomplete fix of CVE-2018-10900, meaning the original newline-injection vector was not fully neutralized, and exposure is limited to Linux hosts where the optional VPNC plugin is installed and the attacker already holds local rights to edit VPN settings. The provided intelligence contains no CVSS score, CWE, EPSS estimate, KEV listing, or POC indicator, so no public exploit identified at time of analysis and the actual risk depends on local privilege boundaries rather than remote reachability.

Attacker-influenced connection profile data can be routed into pppd's root-context pty/shell invocation in the ppp package (reported by Ubuntu), potentially letting a local user obtain code execution with the privileges of the pppd process. Our independent assessment scores this CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H - local access is required, a connection must be initiated, and the target must actually use pppd for PPP/DSL/dial-up/mobile-broadband/VPN links, so exploitability is limited by how niche PPP is on modern systems; exploitation is not passive against a default configuration. No CVSS score, no CVSS vector and no CWE were supplied with the vendor report, there is no vendor-released patch identified at time of analysis and no public exploit identified at time of analysis. The exact privilege level required is not confirmed from the input, though the assessed vector implies an authenticated local user (PR:L).

Local privilege escalation in the NetworkManager iodine VPN plugin (network-manager-iodine) lets an authenticated local user obtain code execution as root through option confusion in the root-privileged nm-iodine-service. A user who is permitted (typically via polkit for an active session) to create or edit an iodine VPN connection can supply a connection property value that iodine's command-line parser interprets as an option flag instead of data, producing behaviour that runs while the service is still root and before iodine drops privileges to an unprivileged user. Exploitation requires local access plus an installed, configured plugin, and no public exploit was identified at time of analysis; the assessed vector is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (high confidentiality, integrity and availability impact, scope unchanged). Note that no CVSS vector, CWE, EPSS, KEV, SSVC or POC signal was supplied in the source data, so severity here derives from the independent assessment rather than vendor scoring.

Sandbox bypass in the n8n Git node lets an authenticated member-level user read git repository objects located outside the path enforced by N8N_RESTRICT_FILE_ACCESS_TO. n8n validates a relative remote URL against the configured repositoryPath, but git is then executed with that directory as its working directory and walks up to the enclosing repository's top level, where it resolves the identical URL string from outside the sandbox; a subsequent fetch or pull merges the external repository's objects into the attacker's own repository, from which the contents can be read back. Versions before 1.123.76, 2.37.7, and 2.38.2 are affected; no public exploit code has been identified at time of analysis, and the confidentiality-only impact (CVSS 4.0 base 5.3, assessed as CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N) is neutralized by upgrading or by disabling the Git node.

Credential leakage in the rmcp Rust SDK (the official Rust SDK for the Model Context Protocol) prior to 2.1.0 allows an attacker who controls or compromises an MCP endpoint to harvest API keys and tokens from victim clients. StreamableHttpClientTransport builds its default reqwest HTTP client with automatic redirect following and replays caller-supplied StreamableHttpClientTransportConfig.custom_headers on cross-origin 307/308 redirects without marking them sensitive, so secrets such as x-api-key headers are forwarded to the redirect target where the attacker can capture and reuse them. The issue is not actively exploited per available intelligence, no public exploit code was identified at time of analysis, and exploitation is condition-gated: it requires a client that (a) runs a pre-2.1.0 version, (b) places secrets in custom_headers rather than the standard Authorization path, and (c) talks to a malicious or compromised MCP server, which is why the assessed vector carries high attack complexity and limits impact to confidentiality (CVSS 6.8, AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N, CWE-200). A vendor patch is available in rmcp 2.1.0.

Cross-tenant data exposure on the djust live WebSocket path affects installations before 1.0.7 that use host-, subdomain-, or domain-based TenantResolvers for multi-tenancy. Because the request rebuilt by handle_mount and ViewRuntime._build_request carries no client Host, get_host() falls back to "testserver", so the tenant resolves to None on the live path even though the ordinary HTTP path resolves it correctly; with STRICT_MODE=False the tenant-scoped managers then return unscoped rows and an authenticated user can read other tenants' data. With the default STRICT_MODE the identical flaw only yields empty querysets (broken tenancy, no disclosure). No public exploit code exists and there is no confirmed active exploitation; EPSS/KEV data were not provided, and the CVSS vector (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N, 6.3) reflects the high attack complexity and the dependency on an explicit STRICT_MODE=False configuration.

Information disclosure in the djust Python WebSocket framework before 1.0.7 causes Django Model instances assigned to public (non-underscore) view attributes to be serialized to the browser with no sensitive-field denylist, exposing fields such as the password hash, is_staff/is_superuser privilege flags, tokens, and other PII inside the render payload sent to the client. Exploitation requires authenticated access to a view that assigns a full model to a public attribute (CVSS:3.1 AV:N/PR:L), and the resulting impact is confidentiality-only but rated High (C:H/I:N/A:N). No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV.

Prototype pollution in the unflatten helper of Builder.io Gen2 SDKs (the @builder.io/sdk-react, sdk-vue, sdk-svelte and sdk-solid packages at or below 5.2.11, and sdk-angular, sdk-react-nextjs and sdk-qwik at or below 0.25.13) lets unauthenticated remote attackers poison Object.prototype in a victim's browser by luring the victim into opening a crafted preview link whose builder.userAttributes query parameters carry __proto__ or prototype segments. Exploitation is not automatable against a passive server - it hinges on user interaction (UI:P), because the SDK must actually be running in the victim's browser when the malicious URL is processed, and real harm (DOM XSS, client-side logic tampering, denial of service) only materializes if downstream application code reads the polluted inherited properties. No CISA KEV entry and no public exploit code were identified at time of analysis, and the independent assessment rates real-world risk as moderate-to-low.

Remote, authenticated administrators of Cisco Identity Services Engine (ISE) can escalate from the web management interface to write access on the appliance's underlying operating system by sending a single crafted HTTP request, and Cisco confirms root is easy to reach from that primitive, making the practical outcome full device compromise. The flaw is improper restriction of resource/file names (CWE-641) in the ISE management web/API layer, reachable over the network with no user interaction but requiring valid administrative credentials (CVSS 3.1 PR:H), so it is a post-authentication escalation path rather than a pre-auth entry point. Cisco's published base score of 4.9 (Medium) understates the outcome - the vendor assigned a High Security Impact Rating for exactly this reason, and our independent assessment raises confidentiality, integrity and availability impact to High; no public exploit code has been identified at time of analysis and the CVE is not in CISA KEV.

OpenTelemetry-Go versions 1.5.0 through 1.44.0 can write sensitive collector configuration into an application's own logs when the application explicitly opts into internal diagnostic logging through otel.SetLogger at Info verbosity: the TracerProvider created event serializes span processor, exporter, and client configuration, exposing OTLP gRPC and HTTP collector endpoints, the OTLP HTTP Insecure flag, and complete Zipkin collector URLs. Anyone able to read those logs - local files, aggregated log stores, or a SIEM - can reconstruct internal collector topology and can recover credentials or tokens where operators embedded them in Zipkin URL user-info or query strings. The vendor CVSS 4.0 base score is 2.0 and no public exploit identified at time of analysis; note that OTLP authentication headers, TLS key material, and span payloads are never written by this path, and default OpenTelemetry configurations that do not install a logger are unaffected because the default logger does not emit the diagnostic event.

An out-of-bounds read in GPAC 26.08-DEV (the wait_for_header_and_parse routine in src/utils/downloader.c) can disclose memory contents or crash the process when the downloader parses a crafted or empty Content-Range value in an HTTP response header. The victim must actively initiate a download from a malicious or man-in-the-middle server for the malformed header to reach the parser; the vulnerable code path is in GPAC's generic HTTP/fetch machinery rather than a media-decoding path, and the consequence is limited to information disclosure or a crash - no write primitive or code execution is demonstrated. Publicly available exploit code exists (the issue is tracked publicly on the GPAC GitHub project) but the flaw is not confirmed actively exploited (CISA KEV), and the assessed impact is low on both the availability and confidentiality axes.

Information disclosure in the Tanium Discover module allows an authenticated console user to read data they should not have access to, with the vendor confirming the flaw has been addressed. The vulnerability requires network reachability and a valid low-privilege Tanium session (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, base 6.5) but no user interaction, and it affects only organizations that have licensed and deployed the optional Discover component. Impact is confined to confidentiality - there is no integrity or availability effect - and no public exploit code or confirmed active exploitation has been identified at time of analysis.

Clear-text logging in Arista EOS with the gRPC Network Packet Sampling Interface (gNPSI) enabled can expose gNPSI client credentials to authenticated users who can read local or remote accounting logs. Affected devices are those running EOS with the non-default, opt-in gNPSI feature configured; exploitation requires an already-authenticated user with log access and specific conditions under which the credentials are written in clear text. This is a moderate-severity information-disclosure issue (vendor CVSS 4.0 score 6.0), not remote code execution or unauthenticated access, and no public exploit has been identified at time of analysis.

Denial of service in HP's HPLIP (HP Linux Imaging and Printing Software) printing stack is reachable when a physically-present attacker supplies specially crafted input that triggers a CWE-191 integer underflow, crashing or hanging affected components; the scored CVSS:3.1 vector (AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) limits impact to availability only, with no confidentiality or integrity loss. The physical attack vector (direct hardware/USB or local physical access) is the dominant gating factor and rules out remote or network-based exploitation, and no public exploit has been identified at time of analysis. HP has stated that it identified and remediated the underlying issues, so a vendor fix is available per advisory hpsbpi04151, though the specific affected and fixed version ranges are not enumerated here and must be confirmed against that bulletin. Overall this is a genuine but low-priority issue: real availability impact, but exploitation requires an attacker to already have hands on the machine.

Cleartext disclosure of peer VRRP authentication credentials in Arista EOS log output allows an authenticated, privileged user - or anyone able to read a system receiving forwarded agent trace logs - to recover the shared secret that authenticates VRRP advertisements, without needing any presence on the VRRP network segment itself. The defect applies to EOS platforms configured with authenticated VRRP; exploitation requires high-privilege access to the switch's agent trace logs or to a downstream log collector, and the resulting impact is confidentiality-only (CVSS 4.0 base 2.1; our independent assessment rates it CVSS 3.1 AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N, i.e. PR:H and C:L). No public exploit code and no confirmed active exploitation were identified at time of analysis; this is a low-priority log-hygiene issue whose only notable edge over routine secret-in-log bugs is that the leak escapes the on-link boundary normally assumed for VRRP secrets.

Denial of service in HP Linux Imaging and Printing Software (HPLIP) can be triggered by a physically present attacker who supplies crafted input via a local device or print/scan job, exploiting improper array index validation (CWE-129). Although HP's advisory bundles several vulnerabilities that could potentially enable a broader range of impacts, the specific vector for this CVE limits the effect to availability (system crash or service disruption) with no confidentiality or integrity impact. No public exploit code or active exploitation has been identified at time of analysis, and the primary prerequisite is physical access to the target system.

Command injection (CWE-78) in HP's HPLIP (HP Linux Imaging and Printing) software enables an unauthenticated local user to execute commands or modify files with high integrity impact (VI:H) after active user interaction, matching HP's CVSS 4.0 score of 6.8 (AV:L/AC:L/PR:N/UI:A/VC:L/VI:H/VA:L) and the independent CVSS 3.1 assessment (AV:L/AC:L/PR:N/UI:R/C:L/I:H/A:L). The HP security bulletin HPSBPI04151 bundles this issue with other externally reported HPLIP flaws that could lead to remote code execution, privilege escalation, denial of service, or information disclosure, but the exact vulnerable component is not disclosed. No public exploit code or CISA KEV entry is identified at time of analysis, and the local vector plus mandatory user interaction prevents triggering without a user processing attacker-supplied input.

Local attackers with valid credentials on Linux systems running HPLIP can exploit symbolic-link handling flaws (CWE-61) in HPLIP components to read or modify arbitrary files, as described in HP security bulletin HPSBPI04151. This CVE is one of multiple issues remediated by HP in HPLIP and is assessed as a moderate, locally-scoped issue (CVSS 3.1: AV:L/AC:L/PR:L/UI:N, limited confidentiality/integrity impact) rather than an urgent priority, despite the broader impact list in the description; no public exploit code or CISA KEV active exploitation has been identified at time of analysis. Exploitation requires local access and a vulnerable HPLIP component that follows attacker-controllable symlinks at a predictable path, limiting impact to unauthorized file read/modification.

Insufficient origin validation in the Mattermost Desktop App (versions up to and including 6.2.2.0) lets server-rendered content from an untrusted or compromised Mattermost server reach local or private network resources, giving the attacker a limited information-disclosure window. Exploitation is not remote-only: the victim must be running the desktop client and actively connect to and view content from an attacker-controlled server (CVSS 4.7, AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N), and only confidentiality is affected - there is no integrity or availability impact. Mattermost credits game0v3r under its responsible disclosure policy (MMSA-2026-00698); there is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis, so overall risk is moderate and low priority.

Deactivated, deleted, or password-reset-locked Concrete CMS accounts keep working API access via any bearer token issued to them before the account state change, letting the holder continue calling the OAuth REST API endpoints under /ccm/api/1.0/* until that already-issued token expires on its own. All Concrete CMS versions before 9.5.4 are affected when the OAuth REST API is enabled; the vendor rates this only 2.0 (CVSS v4.0) and our independent assessment aligns with a low-impact, high-complexity authenticated issue, with no public exploit identified at time of analysis. The flaw is time-limited to the residual lifetime of the token and grants no more access than that token originally had, so it is a stale-credential/session-expiration problem rather than a route to new privileges.

A link-following (symlink) defect in the Dell Update Package (DUP) Framework before version 26.07.03 allows a locally authenticated high-privileged attacker to plant or control a symbolic link so that a privileged DUP file operation resolves to an attacker-chosen path, producing limited integrity and availability impact on the affected host. Exploitation is tightly constrained: the attack vector is local-only (CVSS:3.1/AV:L), requires high privileges (PR:H) plus the ability to create or control symlinks in a path consumed by a DUP operation, and depends on a race or predictable-path condition (AC:H), yielding a base score of 3.0 with I:L/A:L and C:N. No public exploit code was identified at time of analysis and there is no KEV confirmation of active exploitation; Dell has published a fixed version (26.07.03) via advisory DSA-2026-417. Note that the accompanying 'Information Disclosure' tag is not supported by the assessed vector, which shows no confidentiality impact, making this a low-priority local hardening issue rather than a data-exposure event.

Improper link resolution in the Dell Update Package (DUP) Framework before 26.07.03 allows an attacker who already holds high local privileges on a host to point framework file operations at a location of their choosing, resulting in unauthorized filesystem access with limited integrity and availability impact (CVSS 3.1 base score 3.0, AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:L). Because exploitation demands pre-existing high privilege, local access, the ability to plant a symbolic link in a path the framework touches, and a successful link-resolution race, this is a low-severity, hard-to-reach issue that cannot be triggered remotely or by an unprivileged user. There is no public exploit identified at time of analysis, no CISA KEV listing, and a vendor patch is available as version 26.07.03.

Cross-tenant TLS configuration leakage in flightctl (shipped as Red Hat Edge Manager 1 and embedded in Red Hat Advanced Cluster Management for Kubernetes 2) lets an authenticated organization user have their HTTPS git repository's TLS settings - potentially InsecureSkipVerify, a custom CA bundle, or their own mTLS client certificate - applied to another organization's concurrent git.Clone operations, because the device-render worker installs each per-repository tls.Config into go-git's process-global Protocols map. Exploitation requires a multi-tenant deployment that renders devices for several organizations concurrently from a shared goroutine pool and is inherently non-deterministic (AC:H) since the attacker cannot control which tenant's configuration wins; single-tenant or serialized-rendering deployments are not exposed. The vendor scores this 6.6 (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:L/A:N) while our independent assessment rates privileges as PR:L because defining an HTTPS git repository only needs a normal authenticated tenant/organization account; no public exploit code was identified at time of analysis, there is no CISA KEV listing, and no EPSS score was provided.

Information exposure affecting Dell ECS 3.8.1.0 through 3.8.1.7 and Dell ObjectScale prior to 4.4.0.0 arises from the platform's use of a broken or risky cryptographic algorithm (CWE-327). Exploitation is not remotely reachable: it requires an attacker who already holds local access to a storage node together with a high-privileged account (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N per our assessment; NVD scored the confidentiality impact as C:H under the same vector structure), so the dominant limiting factor is the privileged-local-access precondition rather than any technical barrier. There is no public exploit code identified at time of analysis and CISA SSVC rates Exploitation 'none' and Automatable 'no'; the practical risk is low, bounded by credential/algorithm hygiene on the appliance, and remediation is available via ObjectScale 4.4.0.0 and the fixed Dell ECS release cited in Dell advisory DSA-2026-393.

Unauthenticated information disclosure in Rallly before 4.15.0 allows remote attackers who possess a poll's urlId to retrieve the names and email addresses of scheduled-event invitees through the polls.get tRPC procedure, regardless of the poll's privacy settings. The urlId is embedded in the public invite links Rallly generates and shares, so no credentials, user interaction, or non-default configuration are needed; CVSS 3.1 rates this 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N). There is no public exploit code identified and no indication of active exploitation at time of analysis, and the vendor has released a fix in version 4.15.0.

Information disclosure in Zope AccessControl (zopefoundation AccessControl) versions prior to 7.4 allows authenticated users who already hold through-the-web Python code-authoring privileges to break out of the restricted-execution sandbox and read objects that the security policy is supposed to hide. Reaching str.format or str.format_map through a str subclass bypasses AccessControl's policy-restricted getattr and getitem guards, so a crafted format string can recursively walk attributes and subscriptions to disclose objects reachable from the values available to the formatting call. The impact is confined to confidentiality (CVSS 6.8, C:H with no integrity or availability impact); Vendor-released patch: 7.4, and no public exploit identified at time of analysis.

OpenFGA releases prior to 1.18.1 can have their ListUsers API return a user who should have been excluded by the authorization model, causing applications that use ListUsers to enumerate or enforce access to treat an excluded subject as authorized. The flaw is triggered only by a specific combination: a relation expressed as an intersection containing an exclusion operand (for example 'viewer: (org_member but not banned) and active'), where the included base is granted through a type-bound public wildcard ('user:*') and the excluded user also holds a concrete tuple satisfying another intersection operand. It is remotely reachable (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N, base 5.3) but limited to callers already authorized to invoke ListUsers, and it does not affect the Check API in the vendor's reproducing tests; no public exploit code or CISA KEV listing was identified at time of analysis, and the issue is fixed in 1.18.1.

OAuth flow hijacking in the Jenkins Bitbucket Server Integration Plugin 6.0.1 and earlier allows an attacker to substitute the callback URL used in the plugin's OAuth authorization step and capture the Bitbucket access token issued to a victim. Exploitation is not against a static endpoint: the plugin must be installed with its OAuth authorization flow in active use, the attacker must have an OAuth handshake in progress, and a victim who is already authenticated must complete the authorization step (UI:R) within a timing window the attacker must hit (AC:H). Rated only CVSS 4.2 with no confidentiality or integrity impact beyond the scope of the hijacked victim's token, this is a genuine authentication-flow flaw but a low-priority one; no public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis.

Credential isolation bypass in Jenkins GitLab Plugin 1.2149.vcfc32c82b_f7f and earlier allows an authenticated user who holds Item/Configure permission on a folder to reach 'alternative GitLab API token credentials' that are scoped to a different folder and that they are not entitled to use, because the plugin caches the GitLab API client under a cache key derived solely from the credentials ID and never incorporates the folder in which the credentials were resolved. Rated CVSS 3.1 5.4 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N) under CWE-522 (insufficiently protected credentials), the issue is a moderate authorization/credential-isolation flaw rather than an unauthenticated remote compromise, and it only exists on multi-tenant Jenkins controllers that actually rely on folder-scoped credentials - single-tenant installations and controllers where all credentials are global/system-scoped see no practical impact. There is no public exploit identified at time of analysis, CISA SSVC records Exploitation: none and Automatable: no, and the CVE is not KEV-listed, so it warrants scheduled patching rather than emergency response.

Information disclosure in Jenkins Gradle Plugin 2.19.1252.v15196b_5a_6e10 and earlier lets an authenticated Jenkins user who can influence the build log of a Gradle job trick the plugin into fetching build scan data from an attacker-controlled URL in preference to the Develocity server URL set in the plugin's global configuration. Because the plugin attaches the globally configured Develocity access key to that outbound request, the attacker can capture the credential; instances with no Develocity access key configured have nothing to leak, so exposure is conditional rather than universal. No public exploit code has been identified at time of analysis, and this is a genuine but moderate-severity issue: exploitation requires authenticated job-run or job-configure privileges plus a configured access key, and the resulting impact is limited to confidentiality (assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N).

An out-of-bounds read in the userspace SMB daemon of MikroTik RouterOS before 7.24 allows unauthenticated remote attackers to read memory beyond the end of the request buffer by sending a minimal SMB1 SessionSetupAndX frame with a crafted uniPwdLen field value. The over-read occurs in the SessionSetupAndX handler before any credential validation, so no authentication or user interaction is required, though exploitation is only possible when the non-default SMB service is enabled and reachable on the network. Vendor-released patch: RouterOS 7.24; there is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, and the independent assessment rates the impact as limited memory disclosure (VC:L) with possible service disruption (VA:L) rather than code execution or full memory disclosure.

Origin validation errors in the AG-UI TypeScript client SDK (ag-ui 1.0) allow remote, low-privileged attackers who can influence an agent event stream to bypass event-origin checks and release the pending-interrupt gate, yielding low confidentiality, integrity, and availability impact. Affected deployments are those consuming untrusted or compromised AG-UI event sources; the advisory describes manipulation of the TEXT_MESSAGE_START argument, while the upstream fix PR #2701 also addresses an interrupt/resume state flaw where a stream emits an interrupt outcome and then finishes a subsequent run without a resume. Independent assessment rates this medium severity (vendor CVSS 4.0 base 5.3) with no signals of elevated real-world risk; no public exploit identified at time of analysis, and no CISA KEV entry.

A permissive cross-origin resource sharing (CORS) misconfiguration in the AG-UI aws-strands Python integration (ag-ui 0.3.0) allows a remote, unauthenticated attacker who convinces a victim to load an attacker-controlled web page to issue cross-origin requests against a deployed agent endpoint and read limited response data. The flaw is confined to deployments that bootstrap a FastAPI app via create_strands_app in integrations/aws-strands/python/src/ag_ui_strands/utils.py, where the helper installs wildcard CORS (any origin, method, and header) and mounts the agent route with no authentication dependency; deployments that supply an explicit origins allowlist, set cors_enabled=False, or attach an auth dependency are not affected. Exploitation is rated high complexity and difficult (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N, CVSS 4.0 base 2.3), the impact is limited to low confidentiality loss with no integrity or availability effect, and the browser prohibition on combining wildcard origins with credentialed requests further constrains what a successful attack can expose. No confirmed active exploitation (no CISA KEV listing) and no public exploit code were identified at time of analysis, and no EPSS score was provided in the source data.

Information disclosure in the a2ui agent-to-UI rendering library (versions 0.8, 0.9, and 1.0) lets a caller that can drive an A2UI surface read JavaScript prototype-chain members - such as __proto__, constructor, toString, and valueOf - through the Model Processor's data-binding path resolver, leaking internal object structure rather than application data. The flaw is an unauthenticated-of-the-network-but-role-limited (CVSS PR:L) defect in model-processor.ts, where path segments are evaluated as current[segment] without an own-property check; impact is limited to low confidentiality loss with no integrity or availability effect, and there is no public exploit identified at time of analysis. Vendor risk is low-to-moderate: a fix exists upstream as commit 1b3bff23 (PR #2355), but no tagged patched release has been independently confirmed.

In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped Wire up a gmem_invalidate_range() call for SNP VMs, and use it to force vCPUs to reload/recheck their guest-provided VMSA if the backing gmem page is being invalidated, e.g. is being PUNCH_HOLE'd. Use the same core logic to handle invalidations as VMX does for the APIC-access page, as the two concepts are nearly identical: shove the physical address of a page into the vCPU's control structure: 1. Snapshot the invalidation sequence counter 2. Grab the pfn (from guest_memfd in this case) 3. Acquire mmu_lock for read 4. Re-request reload if retry is needed, otherwise commit the change. Note, the re-request action in #4 is necessary as KVM's retry logic is fuzzy, i.e. can get false positives. If the guest_memfd page has been dropped, at some point a subsequent reload will fail to get a PFN from guest_memfd, and KVM will fail KVM_RUN. If the retry was due to a false positive, KVM will retry until there are no relevant MMU notifier events (and will retry in the "outer" loop, i.e. will drop locks and resched as needed). Note #2! Take care to invalidate the VMSA when a relevant memslot is DELETED or MOVED, as invalidations in response to PUNCH_HOLE are predicated on memslot bindings (KVM doesn't know what GFN range(s) to invalidate without a binding). And more importantly, the VMSA mapping requires a memslot, i.e. must be invalidated if its memslots disappears, regardless of the state of the underlying guest_memfd inode. Failure to invalidate the vCPU's control.vmsa_pa (which is checked by pre_sev_run()) can prevent KVM from properly freeing the page as firmware will reject the RMPUPDATE to reclaim the page with FAIL_INUSE if the vCPU is actively running, i.e. if VMSA page is in-use. That in turn leads to an RMP #PF on the next use, as the page will still be assigned to the SNP VM. SEV-SNP: RMPUPDATE failed for PFN 78d198, pg_level: 1, ret: 3 SEV-SNP: PFN 0x78d198, RMP entry: [0xfff0000000144001 - 0x000000000000000f] CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 Call Trace: <TASK> dump_stack_lvl+0x54/0x70 rmpupdate+0x12c/0x140 rmp_make_shared+0x3b/0x60 sev_gmem_invalidate+0xe0/0x170 [kvm_amd] delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm] vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e </TASK> ------------[ cut here ]------------ SEV: Failed to update RMP entry for PFN 0x78d198 error -14 WARNING: arch/x86/kvm/svm/sev.c:5160 at sev_gmem_invalidate+0x126/0x170 [kvm_amd], CPU#3: sev_snp_vmsa_pu/31345 CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 RIP: 0010:sev_gmem_invalidate+0x12b/0x170 [kvm_amd] Call Trace: <TASK> delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm] vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e </TASK> irq event stamp: 20689 hardirqs last enabled at (20699): [<ffffffff8e76092c>] __console_unlock+0x5c/0x60 hardirqs last disabled at (20708): [<ffffffff8e760911>] __console_unlock+0x41/0x60 softirqs last enabled at (20722): [<ffffffff8e6cd74e>] __irq_exit_rcu+0x7e/0x140 softirqs last disabled at (20717): [<ffffffff8e6cd74e>] __irq_exit_rcu+0x7e/0x140 ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: ffff99 ---truncated---

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix division by zero in get_estimated_bw() get_estimated_bw() divides by link->dpia_bw_alloc_config.bw_granularity, which is zeroed by reset_bw_alloc_struct() and only populated once DP_TUNNELING_BW_ALLOC_CAP_CHANGED has been handled. link_dp_dpia_handle_bw_alloc_status(), the DPCD interrupt handler, calls get_estimated_bw() whenever DP_TUNNELING_ESTIMATED_BW_CHANGED is set, independently of whether DP_TUNNELING_BW_ALLOC_CAP_CHANGED has ever fired for that link. A connected USB4/DPIA tunneling device that reports an estimated-bandwidth change before ever reporting a capability change drives a division by zero in this IRQ path. link_dpia_send_bw_alloc_request() already guards the same bw_granularity division; add the identical guard here rather than introducing a new pattern. (cherry picked from commit f2a961457c33dc34223aad5c9e8971de34a4eed3)

In the Linux kernel, the following vulnerability has been resolved: usb: image: mdc800: change kmalloc() to kzalloc() Change the kmalloc() calls in usb_mdc800_init() for irq_urb_buffer and download_urb_buffer to kzalloc(), avoiding potential stack leaks if a shorter message is received in mdc800_usb_irq() and mdc800_usb_download_notify()

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output() The snd_usbmidi_us122l_output() picks a count of 2 on anything slower than high speed and never relates it to ep->max_transfer. The URB buffer holds exactly max_transfer bytes, so a device declaring a one byte bulk endpoint takes two bytes from snd_rawmidi_transmit(), and the memset that pads the rest computes 1 - 2 in int and wraps to SIZE_MAX. Only 0x800e and 0x800f are pinned to nine bytes. The US-122MKII at 0x0644:0x8021 falls to the default and takes usb_maxpacket(), which the USB core only clamps downward. The akai and novation output ops in this file were given the same guard recently. Do the same here.

In the Linux kernel, the following vulnerability has been resolved: usb-storage: ene_ub6250: fix race between scan work and probe ene_ub6250_probe() calls usb_stor_probe2(), which starts the usb-storage infrastructure and schedules the delayed scan work. The driver then calls ene_get_card_type(), which sends an ENE command through ene_send_scsi_cmd() and the usb-storage bulk transfer helpers. Both the delayed scan work, through usb_stor_Bulk_max_lun(), and ene_get_card_type() use us->current_urb. The scan work serializes this access with us->dev_mutex, but the ENE card-type probe does not. If the scan work runs while ene_get_card_type() is still using us->current_urb, usb_submit_urb() warns that the URB is already active. Serialize ene_get_card_type() with us->dev_mutex, matching the locking used by the scan path.

In the Linux kernel, the following vulnerability has been resolved: usb: storage: realtek_cr: fix use-after-free on disconnect realtek_cr_destructor() calls timer_delete() before the chip containing the timer is freed. The timer callback may still be running and can rearm itself, resulting in a use-after-free. Use timer_shutdown_sync() to wait for the callback and prevent further rearming. Do this unconditionally because ss_en may be changed after the timer is armed. Move timer_setup() into init_realtek_cr() so the timer is initialized before any failure path can invoke the destructor. Found by static analysis.

In the Linux kernel, the following vulnerability has been resolved: usb: typec: hd3ss3220: track VBUS enable state per consumer regulator_is_enabled() reports the aggregate regulator state, not whether this consumer holds an enable reference. If another consumer enables VBUS first, the driver can skip its own regulator_enable() call and later attempt to drop a reference it never acquired, triggering an unbalanced regulator disable warning. Track successful enable and disable calls locally. Keep the state unchanged when an operation fails so a later role or ID notification retries the operation while this consumer keeps balanced references.

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: initialize work in f_midi_alloc() f_midi_alloc initializes free_ref to 1 and it can only be incremented when a sound card is registered via f_midi_register_card(). f_midi_register_card() is only called in f_midi_bind() which actually performs INIT_WORK. If f_midi_bind() is never run, work is not initialized and the if condition in f_midi_free becomes true, this results in a warning later in __flush_work as work->func = 0. Fix this by moving INIT_WORK from f_midi_bind() to f_midi_alloc().

In the Linux kernel, the following vulnerability has been resolved: xhci: fix lost bounce buffers on TDs spanning several ring segments When a TD reaches a link TRB with data that is not aligned to the endpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail through the bounce buffer of the ring segment holding that link TRB. xhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers, copies the data back into the URB's buffer. The enqueue path records the segment that was bounced in td->bounce_seg, under the assumption that a TD never spans more than two ring segments. That assumption does not hold: a TD large enough to span three or more segments crosses several link TRBs and can be bounced at each of them. Only the last one survives in td->bounce_seg, so every earlier bounce buffer is neither copied back nor DMA unmapped. The URB still completes with actual_length equal to the requested length and no error, so the transfer looks successful while a wMaxPacketSize sized hole in the destination buffer silently keeps its previous contents. It also leaks a DMA mapping per dropped bounce. Any sufficiently large and fragmented bulk transfer can hit this. It was found with a USB mass storage device behind xHCI backing a dm-verity target with 512 byte hash blocks, where the stale data is detected rather than silently consumed. The device enumerates as SuperSpeed, so wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash block. verity_prefetch_io() makes the block layer merge hundreds of them into a single request of up to 512 scatterlist entries of 512 bytes each. At 256 TRBs per ring segment such a TD spans three segments, and every segment boundary falls on an odd multiple of 512, i.e. unaligned to wMaxPacketSize. dm-bufio then caches a hash block holding stale data and dm-verity declares the metadata block corrupted: device-mapper: verity: 8:2: metadata block 10850 is corrupted A reproducer running this under qemu is available at https://github.com/baloo/xhci-verity The bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs) already lives on the ring segment, so there is nothing extra to track. Keep recording the last bounced segment in td->bounce_seg and, on completion, walk the segments from td->start_seg up to it, unmapping every segment that still has a pending bounce. Stopping at td->bounce_seg rather than td->end_seg matters: a bounce implies the TD continues past that segment's link TRB, so bounce_seg is always strictly before end_seg, and a later TD may already have started in end_seg and been bounced there. Walking that far would copy a foreign bounce buffer into this URB and unmap it twice. It also keeps the walk correct if a TD ever wraps the whole ring so that end_seg == start_seg. [mn: Add ring->num_segs check to prevent unlikely infinite for loop.]

In the Linux kernel, the following vulnerability has been resolved: samples/damon/mtier: handle damon_stop() failure damon_sample_mtier_stop() assumes its damon_stop() call will always successfully stops the two DAMON contexts. Hence it deallocates the two DAMON contexts after the damon_stop() call. However, if a given context is already stopped, damon_stop() fails and returns an error while letting the DAMON contexts that have not yet stopped keep running. This kind of unexpected early DAMON context stops could happen due to memory allocation failures in kdamond_fn(). Because damon_sample_mtier_stop() just deallocates all DAMON contexts with damon_target and damon_region objects that are linked to the contexts, the execution of the unstopped DAMON context (kdamond) ends up using the memory that freed (use-after-free). Fix the issue by separating the damon_stop() to be invoked per context. Note that DAMON_SYSFS also allows multiple DAMON contexts execution. But, it calls damon_stop() for each context one by one. Hence this issue is only in mtier. For the long term, it would be better to refactor damon_stop() to always ensure stopping all contexts regardless of the failures in the middle. Make this fix in the current way, though, to keep it simple and easy to backport. I will do the refactoring later. The issue was discovered [1] by Sashiko.

In the Linux kernel, the following vulnerability has been resolved: samples/damon/wsse: handle damon_start() failure Patch series "samples/damon: handle damon_{start,stop}() failures". All DAMON sample modules are not correctly handling failures from damon_start(). Among those, mtier also has an additional problem for handling of damon_stop() failures. wsse and prcl also have a problem in their damon_call() failure handling. As a result, memory leaks, next DAMON operation disruptions, and use-after-free can happen. Fix those. Note that only the damon_start() failure caused issues can reliably be reproduced. Reproducing those issues require the admin permission, though. This patch (of 6): damon_sample_wsse_start() callers assume it will clean up resources when it fails. And the function does the cleanup for context buildup failures. However, it is not doing the cleanup for damon_start() failure. As a result, when damon_start() fails, it leaks the memory for DAMON context. Free the context in case of the failure to fix the issues. Note that the issue can reliably be reproduced because the module calls damon_start() in the exclusive mode. For example, $ sudo damo start $ echo $$ | sudo tee /sys/module/damon_sample_wsse/parameters/target_pid $ echo Y | sudo tee /sys/module/damon_sample_wsse/parameters/enabled $ sudo cat /proc/allocinfo | grep damon_new_ctx Because the first command is running another DAMON instance, the third command fails the damon_start() call because the new DAMON instance cannot exclusively run. And without this fix, by repeating the third and the fourth commands above, we can show the memory consumption is only increasing due to the leaks. It requires the sudo permission though. The issue was discovered [1] by Sashiko.

In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: handle region split failure in apply_min_nr_regions() damon_apply_min_nr_regions() repeatedly split each region until its size becomes small enough to meet the user-defined low limit of the number of regions. The loop assumes the split operation (damon_split_region_at()) will always succeed and create the new region. But the operation could silently fail for memory allocation failures, for example. If such failure happens and the region was the last region, the linked list-based next region fetching returns invalid pointer. As a result, invalid memory dereference and corruption could happen. Even if the corner case is handled, it imposes stress to the allocator by trying split regions for other targets. Fix the issue by breaking all the loops for any region split failure. This means there could be a min_nr_regions violation. It will only rarely happen since the allocation is arguably too small to fail. Even if it happens, it is only temporal. damon_apply_min_nr_regions() will be called again after the aggregation interval. The user impact of the issue should be minor, since the allocation is arguably too small to fail. But, it could still theoretically happen, and the consequence is very bad. This issue was discovered [1] by Sashiko.

In the Linux kernel, the following vulnerability has been resolved: dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the caller's fd table via dma_buf_fd() -> fd_install() before dma_heap_ioctl() copies the result back to userspace. If the trailing copy_to_user() fails, userspace never learns the fd number, but the fd (and the underlying dma-buf reference) are already visible to other threads in the same process and are leaked for the lifetime of the process. The obvious "close it on the failure path" fix is unsafe: once fd_install() has run, another thread can already dup() the fd, send it via SCM_RIGHTS, or close() it and let its number be reused, so a subsequent close_fd() from the ioctl path can operate on an unrelated file. This was pointed out by Christian König on v1 [1]. Restructure the allocation path so that fd_install() is the last, unfailable step of a successful ioctl: 1. heap->ops->allocate() creates the dma_buf. 2. get_unused_fd_flags() reserves an fd number in the caller's fd table without publishing it, so no other thread can observe it. 3. copy_to_user() delivers the fd number to userspace; on failure the fd is returned with put_unused_fd() and the dma_buf reference is dropped with dma_buf_put(), leaving no user- visible state behind. 4. dma_buf_fd_install() publishes the fd and emits the trace_dma_buf_fd tracepoint -- from here on the ioctl cannot fail. A new dma_buf_fd_install() helper is introduced in dma-buf.c to wrap fd_install() together with the DMA_BUF_TRACE() call, preserving the export tracing that dma_buf_fd() provides. dma_heap_ioctl_allocate() is refactored to return the struct dma_buf * directly (returning ERR_PTR on failure) so the caller holds the dmabuf reference across steps 3 and 4. The failure at step 3 is easily reachable from userspace: pass a struct dma_heap_allocation_data that lives in a page whose protection is flipped to PROT_READ between copy_from_user() and copy_to_user() (e.g. via mprotect()). Before this change each such ioctl leaks one dmabuf fd; after it, the fd table is unchanged on failure and only /dev/dma_heap/<name> remains open. No UAPI or heap-driver interface change. [1] https://lore.kernel.org/dri-devel/175e98de-f414-47d7-81c1-c0fe0a8f7f62@amd.com/

In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Fix kernel address leakages in LBR stack Before Arch LBR gained CPL filtering support, a user-only branch stack could still contain kernel addresses. As a result, kernel branch records may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. For example, on Intel Tiger Lake, the following command can still report SYSRET/ERET entries with kernel-space from addresses: $ ./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \ ./perf bench syscall basic --loop 1000 | \ ./perf script -i - --fields brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' Total time: 0.000 [sec] 0.219000 usecs/op 4,566,210 ops/sec [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.551 MB - ] 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/- 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/- 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/- 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/- The problem is that intel_pmu_lbr_filter() does not fully validate the privilege level of sampled entries. It filters some mismatches based on the branch type and the to address, but it does not reject entries whose from address violates the requested branch privilege filter. Fix this by extending software filtering to validate both from and to addresses against br_sel. Any LBR entry contains kernel address does not match the requested user filter is dropped. This prevents kernel addresses from appearing in user-only branch stacks.

In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix debugfs UAF on adapter removal i2c_del_adapter() frees the adapter's debugfs directory before it unregisters the adapter device, but the new_device sysfs attribute stays writable until device_del(). A write racing with removal still reaches i2c_device_probe(), which passes the freed adap->debugfs to debugfs_create_dir() as the new client's parent: BUG: KASAN: slab-use-after-free in lookup_noperm_common+0x407/0x430 Read of size 4 at addr ffff88803ef87810 by task syz.0.61/6090 lookup_noperm_common+0x407/0x430 simple_start_creating+0x9c/0x110 debugfs_start_creating+0xdb/0x1a0 debugfs_create_dir+0x24/0x350 i2c_device_probe+0x814/0xbf0 It's technically possible to create a client after i2c_deregister_clients has run. That client will never be unregistered and make wait_for_completion hang. Close the window by removing the new_device attribute at the start of i2c_del_adapter(). device_remove_file() will drain any clients left.

In the Linux kernel, the following vulnerability has been resolved: i2c: mux: Fix channel node leak on adapter add failure i2c_mux_add_adapter() takes a reference to the Device Tree channel node before registering the new adapter. If adapter registration fails, the error path frees the private data without dropping that reference. Release the channel node before freeing the private data.

In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: return early from a zero-length flush SYNC_BO does not constrain its size, so a request for zero bytes reaches drm_clflush_virt_range(), which ends with an unconditional clflushopt(end - 1). For an empty range that is the byte before the mapping, and abo->mem.kva comes from vmap(), so the access lands in the guard page below the vmalloc area and faults: BUG: unable to handle page fault for address: ffffd16fbbc70fff #PF: supervisor read access in kernel mode Oops: Oops: 0000 [#1] SMP NOPTI CPU: 7 UID: 1000 Comm: sync_bo_probe RIP: 0010:drm_clflush_virt_range+0x3c/0x70 Call Trace: amdxdna_drm_sync_bo_ioctl+0x124/0x430 [amdxdna] drm_ioctl+0x301/0x4c0 __x64_sys_ioctl+0x115/0x2f0 do_syscall_64+0xa6/0x3d0 Any process that can open the render node can do this. Reproduced 3 of 3 times on a Strix Point NPU (1022:17f0), by calling SYNC_BO with size 0 on an AMDXDNA_BO_SHARE object. The import arm takes the same request but flushes the whole scatterlist, so it survives it. Nothing needs flushing for an empty range, so answer before choosing a path.

In the Linux kernel, the following vulnerability has been resolved: accel/ethosu: check MMIO mapping errors in probe devm_platform_ioremap_resource() returns an error pointer when the register resource cannot be mapped. ethosu_probe() stores it and continues until initialization dereferences it through MMIO accessors. Return the mapping error before initializing the device.

In the Linux kernel, the following vulnerability has been resolved: accel/ethosu: fix job completion fence cleanup ethosu_ioctl_submit_job() allocates done_fence before validating buffer handles. Errors after allocation call ethosu_job_err_cleanup(), which frees the job but leaks the uninitialized fence. A scheduler dependency error also lets ethosu_job_run() return before dma_fence_init(). Normal cleanup then passes a zeroed refcount to dma_fence_put(). Release done_fence in the common cleanup path and use dma_fence_was_initialized() to distinguish initialized fences from raw allocations. [robh: also fix goto]

In the Linux kernel, the following vulnerability has been resolved: nvme-fabrics: fix DHCHAP secret leak on parse failure nvmf_parse_options() duplicates dhchap_secret and dhchap_ctrl_secret with match_strdup() before validating the DHHC-1: representation. If validation fails, the parser returns -EINVAL before the temporary string in p is assigned to opts->dhchap_secret or opts->dhchap_ctrl_secret. nvmf_create_ctrl() subsequently frees opts, but nvmf_free_options() cannot release the unassigned temporary string. Each rejected option therefore leaks one allocation. This is easy to miss because valid secrets transfer ownership to opts and are freed normally, while the malformed-secret path still returns the expected -EINVAL to userspace. With CONFIG_NVME_HOST_AUTH enabled, the leak is reachable before the required-option checks and transport lookup. No NVMe-oF target or working transport connection is required; for example, repeatedly writing dhchap_secret=BAD or dhchap_ctrl_secret=BAD to /dev/nvme-fabrics deterministically takes the leaking parse path. Free the temporary string before leaving both validation error paths. Use kfree_sensitive() because the copied option may contain secret material even when its representation is rejected, matching the sensitive cleanup used for stored DHCHAP secrets.

In the Linux kernel, the following vulnerability has been resolved: mtd: mtdoops: free page bitmap when the backing MTD is removed mtdoops_notify_add() allocates oops_page_used when the configured MTD device is registered. mtdoops_notify_remove() detaches from that device but leaves the bitmap allocated. If the same MTD device is later registered again, the add path allocates a new bitmap and overwrites the old pointer, leaking one vmalloc allocation per remove/add cycle. This is only visible when the backing MTD device can disappear and be registered again while mtdoops remains loaded, so the usual static MTD case does not expose it. Free the bitmap after unregistering the dumper and flushing the pending workers, then clear the pointer and page count before a later attach can allocate fresh state. Clearing the pointer also keeps the module exit path from freeing the same bitmap a second time after a remove event.

In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: validate ONFI extended parameter page sections nand_flash_detect_ext_param_page() allocates the length declared by the ONFI parameter page, then treats the data as a fixed header followed by variable-length sections. It reads that header and advances over sections without first proving that the fixed page and each current section fit in the allocation. Reject pages shorter than the fixed header, track the remaining variable area while walking sections, and require the ECC section to contain every field read from struct onfi_ext_ecc_info. Use device-scoped diagnostics that identify the malformed ONFI section.

In the Linux kernel, the following vulnerability has been resolved: batman-adv: mcast: linearize skbuff for packet generation batadv_mcast_forw_packet() and batadv_mcast_forw_scrape() is not only called (indirectly) by the unsharing+linearizing batadv_recv_mcast_packet() handler. When it is called (indirectly) by batadv_mcast_forw_mcsend() then it will be unshared but not linearized. The SKB_LINEAR_ASSERT() can therefore cause a fatal BUG(). The linearization should happen during the expansion of the head because the scrape function can be hit already during the initial batadv_mcast_forw_mode() selection code: * batadv_interface_tx * batadv_mcast_forw_mode * batadv_mcast_forw_mode_by_count() * batadv_mcast_forw_push() -> calls batadv_mcast_forw_expand_head() before everything else * batadv_mcast_forw_push_tvlvs() * batadv_mcast_forw_push_dests() * batadv_mcast_forw_push_adjust_padding() * batadv_mcast_forw_scrape()

In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: avoid unaligned fault in IP extraction Independent of the alignment of the ARP packet in the SKB, either the batadv_arp_ip_src or the batadv_arp_ip_dst will have an unaligned access (on HW without native unaligned read support). Use get_unaligned() to handle this properly on all architectures.

In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: fix freeing of claims on meshif deletion When the mesh interface is getting deleted, then batadv_bla_del_backbone_claims() (via batadv_bla_purge_backbone_gw()) could make sure that all claims gets removed. But this function is only executed when bat_priv->bla.claim_hash is not NULL. And since batadv_bla_free() is always setting it to NULL before it is (indirectly) called, it was never actually executed. But the batadv_bla_purge_claims() -> batadv_handle_unclaim() is at the moment too fragile because the BLA code is not handling the rehashing in batadv_bla_update_orig_address(). The stored backbone address doesn't have to be the one actually used for the hash bucket selection during the initial adding of the backbone. The batadv_handle_unclaim() can therefore fail to find the respective backbone for the unclaim and then stop the deletion. But the actual backbone_gw object is not needed for the unclaim because all relevant information is always provided by the caller. And the check for the existence of the backbone_gw doesn't provide any additional security check for the deletion of a claim.

In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l33: drain threaded IRQ before runtime suspend cs35l33_runtime_suspend() currently switches the codec into regcache_cache_only(true) and powers it down without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l33_irq_thread() can still run after suspend has closed off live register access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1/2 after cache_only has been enabled, ignores the regmap_read() failures, and can still drive the AMP_SHORT_RLS, CAL_ERR_RLS, OTE_RLS, and OTW_RLS release paths. Use disable_irq() before entering cache_only/power-off so any in-flight threaded handler is drained and no new IRQ thread can run during the suspended state. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only warns if devm_request_threaded_irq() fails, track whether the IRQ was actually installed before disabling or re-enabling it.

In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l34: drain threaded IRQ before runtime suspend cs35l34_runtime_suspend() currently switches the codec into regcache_cache_only(true), asserts reset low, and powers the device off without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l34_irq_thread() can still run after suspend has removed live hardware access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1..4 after cache_only has been enabled, ignores the regmap_read() failures, and can still execute the PROT_RELEASE_CTL release sequence or the BST fault power-down writes. Use disable_irq() before entering cache_only/reset-low/power-off so any in-flight threaded handler is drained and no new IRQ thread can run while the device is suspended. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only logs request_threaded_irq() failures and keeps going, track whether the IRQ was actually installed before disabling or re-enabling it.

In the Linux kernel, the following vulnerability has been resolved: ASoC: hdac_hda: Fix hlink refcount leak on component registration failure hdac_hda_dev_probe() gets the HDA link with snd_hdac_ext_bus_link_get() before registering the ASoC component. If component registration fails, the function returns without dropping the link reference. Always call snd_hdac_ext_bus_link_put() after the registration attempt so the reference taken during probe is balanced on both success and failure.

In the Linux kernel, the following vulnerability has been resolved: iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable atlas_buffer_postenable() acquires a runtime PM reference with pm_runtime_resume_and_get() but returns the result of atlas_set_interrupt() directly. If atlas_set_interrupt() fails, the runtime PM reference is leaked and the device can never autosuspend. Add pm_runtime_put_autosuspend() on the error path to balance the reference.

In the Linux kernel, the following vulnerability has been resolved: iio: chemical: sgp30: Handle IAQ thread creation failure kthread_run() can fail and return an error pointer, but sgp_probe() stores it and returns success, so the device is registered without its IAQ thread and sgp_remove() later passes the error pointer to kthread_stop(). Return the error from probe instead.

In the Linux kernel, the following vulnerability has been resolved: iio: dac: m62332: Fix regulator reference count imbalance m62332_set_value() enables the Vcc regulator on every write of a non-zero value and disables it on every write of zero, without tracking the channel's current state. Because the regulator is reference counted, changing a channel directly from one non-zero value to another enables it more than once, while a later write of zero disables it only once. The reference count never returns to zero and the regulator is left enabled indefinitely. Only enable the regulator on the transition from zero to non-zero, and only disable it on the transition from non-zero to zero, using the previously stored channel value to detect the edge. Balance the regulator on the I2C error path so the reference count stays consistent if the write fails.

In the Linux kernel, the following vulnerability has been resolved: iio: light: apds9306: fix PM reference leak in apds9306_read_data() apds9306_read_data() calls pm_runtime_resume_and_get() but several error paths return directly without calling pm_runtime_put_autosuspend(), leaking the runtime PM reference and preventing the device from autosuspending. Use PM_RUNTIME_ACQUIRE_AUTOSUSPEND() and PM_RUNTIME_ACQUIRE_ERR() to automatically handle runtime PM reference release on all return paths.

In the Linux kernel, the following vulnerability has been resolved: iio: light: ltrf216a: fix runtime PM reference leak in error path ltrf216a_get_lux() acquires a runtime PM reference by calling ltrf216a_set_power_state(data, true). However, if ltrf216a_read_data() fails, the function returns immediately without dropping the reference. This leaves the runtime PM usage count unbalanced, preventing the device from autosuspending after a failed read. Fix this by releasing the runtime PM reference before returning from the error path.

In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Ensure KVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit Always check and clear KVM_REQ_GET_NESTED_STATE_PAGES when emulating a nested VM-Exit to ensure the request is cleared, even when KVM was built with CONFIG_KVM_HYPERV=n, as KVM subtly relies on the "check" to clear the flag and thus avoid double-mapping the vmcs12 pages, e.g. if KVM manages to bail from VM-Enter without processing the request, and then emulates VMLAUNCH or VMRESUME.

In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix length check __import_wp_info() struct kvm_hw_breakpoint::len is a __u64 that is fully controlled by user space. This is then assigned to wp_info->len, which is an int. The bounds check is done on the truncated value while the allocation uses the untruncated one: wp_info->len = bp_data->len; [...] if (wp_info->len < 0 || wp_info->len > MAX_WP_SIZE) return -EINVAL; wp_info->old_data = kmalloc(bp_data->len, GFP_KERNEL_ACCOUNT); Use the validated value for the allocation as intended. Without this fix userspace can trigger >4GB allocations which will fail and result in a WARN due to MAX_PAGE_ORDER.

In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix memory leak in guest debug handling bp_data is freed only for the error case by kfree(bp_data). Every successful KVM_SET_GUEST_DEBUG will leak bp_data.

In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix old_data leak in guest debug error path __import_wp_info() allocates a per-watchpoint old_data buffer to back up the original guest memory contents. If a later watchpoint of the same KVM_SET_GUEST_DEBUG request fails to import, kvm_s390_import_bp_data() jumps to the error label, which frees the wp_info array but not the old_data buffers of the entries that were imported successfully. Up to MAX_BP_COUNT - 1 buffers of up to MAX_WP_SIZE bytes are leaked per failed request, and the request can be repeated. Create error handling for cleaning up all created old_data memory areas.

In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Zero initialize data structures for inject_pfault_token __kvm_inject_pfault_token() only sets .type and .u.ext.ext_params2 of the on-stack struct kvm_s390_irq but the full ext substructure is copied into the cpu local variable on inject. ext_params and pad contain stale stack values. Interrupt delivery only uses ext_params2, so nothing leaks to the guest, but a host user can use the migration ioctls to get to the data. Fix by zero-initializing the irq struct. Do the same for the inti data structure.

In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Handle VNCR TLB invalidation race with vcpu_put() VNCR unmapping While VNCR TLB invalidation always occurs under the MMU lock, vcpu_put() doesn't, while it unmaps the VNCR page. The problem is that the invalidation evaluates vncr_tlb::cpu to decide whether an unmapping needs to take place (cpu != -1) before performing it. On the other hand, this_cpu_reset_vncr_fixmap() unconditionally unmaps if L1_VNCR_MAPPED is set. These two obviously can race, with a TOCTOU pattern on the TLBI path, and a BUG_ON() on the vcpu_put() path. And the two can end-up calling vncr_fixmap(-1), with extra lethal effects. Move the reset of vncr_tlb::cpu to -1 to a common function, and make this update atomic so that only a single thread can reset the field and perform the corresponding unmap. The vcpu_put() still need to unconditionally unmap the current VNCR to close another ugly race. Finally, the assignment of vncr_tlb::cpu is moved to be kept in sync with the actual mapping, similar to L1_VNCR_MAPPED being set.

In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Free init resources if kvm_init() fails kvm_loongarch_init() calls kvm_loongarch_env_init() to allocate the per-CPU kvm_context (vmcs) and kvm_loongarch_ops and to register the perf callbacks, and then calls kvm_init(). If kvm_init() fails its result is returned directly, but since module_init() does not run the module_exit() stuff on failure, so kvm_loongarch_env_exit() is never called and those resources are leaked. So call kvm_loongarch_env_exit() when kvm_init() fails, matching the teardown-on-failure pattern used by riscv_kvm_init().

In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Move arena register slot below TCC context Currently, the stack layout places the optional arena register slot above the tail call counter context. When arena_vm_start is dynamically enabled, it shifts the relative offset of the tcc_ptr slot within the stack frame, causing hardcoded tracking macros to mismatch and leading to memory misalignment or corruption potentially. To fix this, move the arena register save and restore sequences below the tail call counter context slots in both build_prologue() and the epilogue. Update __build_epilogue() to insert a proper offset decrement to safely skip the unneeded tcc_ptr reading block while accurately aligning with the relocated arena slot at the very bottom. With this patch, the tcc_ptr slot is always positioned at a fixed distance directly underneath the base callee-saved registers that is independent of whether the arena features are on.

In the Linux kernel, the following vulnerability has been resolved: media: airspy: use vb2_video_unregister_device() on disconnect to fix NULL deref airspy_disconnect() clears s->udev under v4l2_lock, but airspy_stop_streaming() unconditionally calls airspy_ctrl_msg() and airspy_free_stream_bufs() afterwards. If a streaming user closes the device after disconnect, stop_streaming() runs and dereferences the NULL s->udev: airspy_stop_streaming() airspy_ctrl_msg(s, CMD_RECEIVER_MODE, 0, 0, NULL, 0) usb_sndctrlpipe(s->udev, 0) /* NULL deref */ airspy_free_stream_bufs(s) usb_free_coherent(s->udev, ...) /* NULL deref */ The airspy driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&s->vdev) with vb2_video_unregister_device(&s->vdev) and move it before clearing s->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs airspy_stop_streaming() if streaming is active, so the URBs, coherent DMA stream buffers and the hardware stop control message all execute while s->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&s->vb_queue_lock) / mutex_lock(&s->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around s->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/

In the Linux kernel, the following vulnerability has been resolved: media: cec: core: Fix kmemleak due to missed rc_free_device() call The commit dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") removed the implicit call to rc_free_device() from rc_unregister_device(). However, the commit missed to remove the NULL assignment of adap->rc that is now causing rc_free_device() to never be called on an allocated rc device. kmemleak reports following after e.g. dw-hdmi unbind: unreferenced object 0xffff00010ac10000 (size 4096): comm "kworker/u16:1", pid 39, jiffies 4294897739 hex dump (first 32 bytes): 20 23 4b 0a 01 00 ff ff 08 00 c1 0a 01 00 ff ff #K............. 08 00 c1 0a 01 00 ff ff 00 00 00 00 00 00 00 00 ................ backtrace (crc e11baccc): kmemleak_alloc+0x38/0x44 __kmalloc_cache_noprof+0x4a8/0x5e0 rc_allocate_device+0x48/0x2a0 cec_allocate_adapter+0x3ac/0x800 dw_hdmi_cec_probe+0x264/0x634 platform_probe+0xc0/0x188 really_probe+0x4a4/0x8e0 __driver_probe_device+0x2f8/0x440 driver_probe_device+0x60/0x160 __device_attach_driver+0x1a0/0x2a0 bus_for_each_drv+0x100/0x1a0 __device_attach+0x174/0x350 device_initial_probe+0x90/0xb0 bus_probe_device+0x4c/0x120 device_add+0xdec/0x116c platform_device_add+0x354/0x598 Remove the assignment of adap->rc to NULL to let cec_delete_adapter() free the allocated rc device after last user of the cec device exits to fix the kmemleak.

In the Linux kernel, the following vulnerability has been resolved: media: cedrus: fix memory leak in cedrus_init_ctrls() In cedrus_init_ctrls(), the V4L2 control handler is initialized before allocating memory for ctx->ctrls. If this allocation fails, the function returns -ENOMEM without freeing the previously allocated handler resources, leading to a memory leak. Fix this by calling v4l2_ctrl_handler_free() on the ctx->ctrls allocation failure path. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an Allwinner SoC or board with a Cedrus VPU available to test with, no runtime testing was able to be performed.

In the Linux kernel, the following vulnerability has been resolved: media: cobalt: Avoid freeing ALSA private data twice snd_cobalt_card_create() stores cobsc in sc->private_data and installs snd_cobalt_card_private_free() as sc->private_free. From that point, snd_card_free(sc) releases cobsc through the ALSA card cleanup path. If cobalt_alsa_init() fails after snd_cobalt_card_create(), the err_exit_free path calls snd_card_free(sc) and then kfree(cobsc). That second free releases the same object again. Remove the explicit kfree(cobsc) and leave ownership with the ALSA card. This issue was found by a static analysis checker and confirmed by manual source review.