Alerts

The commit fixes a memory-safety vulnerability in the LiquidIO CN23XX driver where a cached pointer to a VF PCI device (dpiring_to_vfpcidev_lut) could be dereferenced after the VF device was removed or its reference dropped. The previous code cached VF PCI device pointers without proper reference management and later dereferenced them during OCC/FLR handling (via OCTEON_VF_ACTIVE path). The patch removes the cache and replaces it with a runtime lookup that derives the VF from the DPI ring, validates it against the PF, and performs proper reference handling (pcie_flr then pci_dev_put). This reduces the risk of use-after-free or invalid dereferences when handling VF FLR requests.

The commit fixes an out-of-bounds read in the 802.11 IE parsing during Association Response processing in OnAssocRsp() for the rtl8723bs driver. Previously, the IE parsing loop advanced by (pIE->length + 2) for each IE but only guarded the loop with i < pkt_len. This allowed a malicious AP to craft an Association Response whose last IE ends near the frame boundary (e.g., with only one byte remaining), causing the code to read pframe[pkt_len] and read pIE->length from memory beyond the frame. Additionally, even when headers were within bounds, pIE->length could extend past pkt_len, allowing a truncated/invalid IE to be passed to handler code. The patch adds two guards at the top of the loop: (1) break if fewer than sizeof(*pIE) bytes remain (can't read header), and (2) break if the IE's declared data extends past pkt_len. This prevents out-of-bounds reads, improving memory safety and reducing potential information leakage or crashes from crafted 802.11 frames.

The commit fixes a potential NULL pointer dereference in the AMD XDNA GEM/BO handling path. After a BO handle is closed, abo->client may be cleared to NULL while the underlying GEM object can still be referenced by the kernel. Code paths that execute after the BO close could dereference abo->client (e.g., abo->client->xdna), leading to a NULL pointer dereference and possible kernel OOPS. The patch eliminates dereferencing abo->client after close by obtaining the device context via the object's gobj dev (to_xdna_dev(to_gobj(abo)->dev)) and by guarding access patterns in relevant helpers (e.g., amdxdna_gem_vmap, amdxdna_dev_offset calculations, and dma address handling). It also adds protective comments and guards in the HMM registration path to avoid using abo->client when the resource is already detached, relying on mem.dma_addr or UVA paths instead.

The commit fixes an information-disclosure vulnerability in the KVM arm64 FFA_VERSION host-call path. Previously, kvm_host_ffa_handler declared a local stack variable 'res' of type struct arm_smccc_1_2_regs without initializing it when the compiler did not automatically zero-initialize stack variables. The host call path could return residual data from the hypervisor stack to the guest via FFA_VERSION, leaking sensitive hypervisor/stack contents across the host-guest boundary. The patch changes the local 'res' declaration to zero-initialize it (struct arm_smccc_1_2_regs res = {0};), ensuring no residual data is leaked in the return data. This is a genuine security fix addressing information disclosure at the KVM/ARM64 host-guest boundary.

The commit fixes a race between device teardown (inetdev_destroy) and IGMP processing that could cause a use-after-free of struct in_device in the IGMP timer path. Specifically, igmp_gq_start_timer() and related timer arming paths could re-arm timers while the underlying in_device is being freed under RCU grace, leading to a dereference of freed memory when the timer fires. The fix adds in_dev_hold_safe() (wrapping refcount_inc_not_zero) and only arms the timer if a safe non-zero refcount increment succeeds; otherwise the timer is not armed. This prevents acquiring a reference to an in_device that is already being destroyed, eliminating the potential UAF. A similar issue was fixed for IPv6 MLD in a separate patch. Impact: Use-After-Free (UAF) in the IGMP timer handling code due to a race with inetdev_destroy. The vulnerability could cause kernel panics (DoS) and, in theory, memory safety issues if exploited in certain conditions. The commit is a genuine fix for this issue, not just a dependency or formatting change.

This commit applies a set of security-hardening changes to the ksmbd SMB3 server, addressing authentication/authorization flows and session/channel binding integrity. The patch touches session keys and signing keys, channel binding limits, reauthentication of bound sessions, cross-dialect binding validation, and error handling. Notable changes include deriving and using a per-session key for signing, enforcing a maximum number of channels per session, ensuring different-user reauthentication on bound channels is rejected with proper status codes, using signed responses where appropriate, and aligning error reporting (e.g., STATUS_ACCESS_DENIED vs. other codes) and cross-dialect binding handling with the session dialect. Collectively, these changes mitigate potential authentication bypasses, binding integrity issues, and information disclosure risks in SMB session establishment and channel binding flows.

The commit fixes an information disclosure risk where the caller's thread keyring could be kept alive longer than the caller's lifetime when opening a table device via the block dm subsystem. Prior to the patch, the backing device could be opened with the caller's credentials, potentially pinning the caller's thread keyring in memory and allowing leakage of sensitive key material (e.g., the LUKS volume key) during operations like luksSuspend. The fix ensures the backing device is opened with kernel credentials (scoped_with_kernel_creds), preventing the caller's credentials from being pinned in the file object, thereby avoiding leaking the thread keyring and making the key material discardable as intended. This mitigates an information disclosure vulnerability related to cryptographic keys in memory.

The patch fixes a memory-safety vulnerability in the device-mapper pcache target option parser. Previously, when parsing an option table that advertises an optional argument but provides only the option name (e.g., cache_mode) and no corresponding value, parse_cache_opts would consume the option name, decrement argc, and then call dm_shift_arg() to fetch the value. If no value existed, dm_shift_arg() could return NULL, and a subsequent strcmp() would dereference that NULL pointer, causing a NULL dereference. This could crash the kernel or potentially be leveraged for a DoS. The fix adds explicit checks to ensure an option has a value before consuming it, returning a proper error when a value is missing and avoiding the NULL dereference while preserving correct behavior for well-formed tables.

This commit fixes a deserialization/memory-safety issue in the CRIU restore path for AMDGPU's KFD queues. It adds bounds checks on the private CRIU restore data: (1) validates that the provided queue type is within the defined KFD_QUEUE_TYPE_MAX, and (2) validates that the provided mqd_size matches the expected size for that queue type via a new mqd_size_from_queue_type helper. Previously, crafted CRIU restore data could potentially instruct the kernel to restore queues with invalid types or mismatched MQD sizes, which could lead to out-of-bounds accesses or corrupted state during restoration. The changes are defensive input validation to prevent deserialization-related memory-safety issues in the CRIU restore code path.

The commit changes OFREP evaluation to filter results by public metadata, so unauthenticated requests no longer receive private flag information. It removes a previous hard unauthenticated allowance for non-public flags and introduces proxy-level filtering that only returns public flags to unauthenticated users, or a not-found response for non-public flags. This mitigates information disclosure and potential authentication-bypass via flag enumeration. The change includes test scaffolding and new helper logic to filter results based on flag metadata.

This Flutter iOS engine patch mitigates a potential memory-safety vulnerability in the SemanticsObject/AccessibilityBridge integration. Previously, code could hold a raw bridge pointer or dereference the bridge after the AccessibilityBridgeIos object had been destroyed (e.g., during engine teardown, view controller swaps, or shutdown while VoiceOver still references the accessibility tree). This could yield use-after-free or undefined behavior when calling bridge-related APIs (such as bridge->view(), DispatchSemanticsAction, hit-testing, or coordinate conversions). The patch replaces the internal bridge storage (fml::WeakPtr<AccessibilityBridgeIos>) with safe accessors (bridge and bridgeView) that return a raw pointer or UIView* only when the bridge is still alive, and updates call sites to fetch the pointer once and guard against nullptr, ensuring no access occurs after destruction. It also marks the relevant properties as nullable and wraps the corresponding access paths accordingly. A test was added to destroy the AccessibilityBridge and verify that semantics accessors, actions, geometry conversion, and hit-testing do not touch freed memory afterward.

The commit replaces a hard-coded Insecure TLS setup for the annotation service client with configurable TLSClientConfig usage. Previously, the REST config could enable Insecure (bypassing certificate validation) in Development environments, creating a potential MITM risk for TLS traffic between Grafana and the annotation API server. The fix introduces proper TLS configuration via TLSClientConfig, allowing a CA bundle to be specified or falling back to the system trust store, and preserves Insecure only in Development for local testing. This reduces exposure to MITM attacks in production and non-dev environments.

The commit adds path normalization checks in the rewrite target middleware (and related snippet rewrite action) to reject requests where path normalization would change the path. Specifically, it computes the original path, applies a normalization via req.URL.JoinPath(), and then rejects with 400 Bad Request if the normalized path differs from the original. This blocks potential dot-segment/dot-dot path traversal in rewrite targets (e.g., /foo../bar, /api../admin) that could otherwise allow access to unintended resources or disclose information when rewrites are evaluated. The changes are covered by tests that exercise traversal scenarios. In short, this is a genuine path-traversal prevention fix at the edge (rewrite/URL normalization), not a mere dependency bump or test-only change.

The commit tightens the token exchange namespace scoping used by the annotation API. Previously the token exchange requests could be issued with a wildcard Namespace ('*'), enabling tokens to be exchanged with broad, cross-namespace permissions. The fix introduces a NamespaceMapper derived from the requester context (stack namespace when a stack is present, or org/default namespaces otherwise) and uses it to set the TokenExchangeRequest.Namespace, thereby scoping token exchange to the requester’s stack/org context. This reduces the risk of privilege escalation via token exchange to resources outside the requester’s namespace. The change also updates the REST client construction to pass the Mapper to the token exchange wrapper and adds tests validating the namespace derivation logic.

The commit changes the runtime handling of search-field manifest ingestion from panicking on invalid declarations to returning an error. Previously, loading a bad manifest at runtime could crash the service, potentially enabling a denial-of-service if an attacker could supply a malicious manifest. The fix introduces error-returning constructors (newMapProvider/newManifestBackedProvider) and propagates these errors up to the caller (e.g., NewSearchOptions/SearchFieldProviders), with tests ensuring errors are surfaced instead of panics. This hardens the system against DoS via invalid manifests.

The commit gates the display and actions of homepage recommendations based on live plugin state and user permissions. This mitigates information disclosure and unauthorized access to plugin management features by ensuring that recommendations are shown and their actions are available only when the user has appropriate permissions and the relevant plugins are in a state that allows interaction. Prior to this fix, the Home page could surface plugin-related recommendations and actions to users without sufficient permissions, potentially revealing which plugins exist and enabling unintended plugin-related actions.

A data race exists in the OpenTelemetry metadata handling path of vmagent where metadata slices produced by the OTLP/OpenTelemetry stream parser are assigned directly to the WriteRequest.Metadata field. The parser reuses internal buffers, and the remote write path may still read the queued write request while the parser reuses its backing array, leading to concurrent mutations of the same underlying memory. The fix copies each metadata entry into a PushCtx-owned buffer (mmsDst) before assigning to WriteRequest.Metadata, eliminating the shared backing array and thus the race. This is a correctness/concurrency bug with potential memory-safety implications (crashes or inconsistent state) under concurrent OTLP streaming workloads. Affected code paths involve inserting rows for OpenTelemetry metadata and the remote write path; the fix brings them in line with how the Prometheus remote write path already handles metadata by copying to an independent buffer.

The commit migrates folder actions in the alerting unified UI to centralized ability hooks (FolderAction, useFolderAbility, useGlobalRuleAbility) instead of ad-hoc permission checks (e.g., contextSrv.hasPermission). This refactor enforces authorization decisions through a unified capability system, reducing the risk of inconsistent or bypassable frontend checks when performing folder-related actions (create, export, pause, delete). While server-side authorization remains essential, the frontend gating now routes through centralized abilities, addressing potential authorization bypass scenarios caused by scattered or duplicated checks across components.

The commit introduces safeguards around how folder titles are mapped to repository export paths during provisioning. Previously, a folder title could yield an unsafe or ambiguous path when deriving the export path directly from the raw title (e.g., titles containing characters outside the allowed path set). This could cause a write to fail and be recorded as FileActionIgnored, leading the job to report success with no changes while exporting nothing. The fix adds: (1) SanitizeSegment to convert a folder title into a single safe path segment (dropping unsupported chars, trimming leading/trailing spaces/dots, and falling back to UID when needed), and applies it to folderTree.dirPath; (2) a collision check to fail the export loudly if two distinct folders map to the same path; (3) adjusted error handling so genuine export failures are surfaced rather than discarded as ignored. Together, these changes prevent unsafe paths, surface failures, and ensure folder paths are stable and collision-aware. This addresses a path handling vulnerability and improves operability/visibility of provisioning exports.

The patch introduces server-side validation to bind provisioning job author annotations to the actual requester, preventing impersonation of other users when provisioning via Git-backed commits. Prior to this change, provisioning jobs could include author annotations (AnnoAuthor, AnnoAuthorEmail, AnnoAuthorID) that did not have to reflect the true requester, allowing an attacker to impersonate another user when provisioning resources or triggering commits. The fix enforces that, on create, the author annotations must either be empty (no attribution) or match the actual requester (unless the request is made with service identity), and on updates, author-related annotations become immutable. This reduces the risk of authorization bypass/privilege escalation through forged provisioning metadata and ensures commit signatures reflect the acting user. It also adds a dedicated author attribution helper and tests around author validation and immutability.

The Open Redirect vulnerability arises when the dashboard redirection logic uses the X-Forwarded-Prefix header to compose the redirect location without validating that the value is a relative path. An attacker could set X-Forwarded-Prefix to an absolute URL (including host and/or scheme) to redirect users to an external domain. The commit adds a validation check that rejects absolute URLs and resets to empty, preventing external redirects via this header.

The commit implements a real vulnerability fix by correcting how logging is performed across InfluxDB Flux/FSQL/InfluxQL components. Previously, debug logs could bypass the configured Grafana log level (GF_LOG_LEVEL) due to the use of a package-level or context-insensitive logger, potentially leaking sensitive information or flooding logs. The fix threads a logger through calls, replaces package-level log usage with context-aware loggers, and propagates per-request loggers (and dedicated subs loggers) through Flux/FSQL/InfluxQL pathways, health checks, and DS query handling. This ensures logs respect GF_LOG_LEVEL and reduces the risk of Information Disclosure via debug logs. Affected areas include flux/executor paths, flux/flux.go, fsql, influxql, fsql/fsql.go, health checks, and the main InfluxDB TSDB service wiring to pass logger instances properly.

The commit fixes a vulnerability vector known as prompt injection in the agent-rules block used by Next.js. Previously, the agent-rules block could be treated as an instructional directive that might persist or be re-added through automated generation, commits, or diffs, enabling an attacker to influence agent behavior or pull in untrusted content via automated tooling. The patch changes the content and generation flow so the block is verifiable and self-upgrading rather than a self-persisting, commit-bound instruction. Specifically, it: - anchors the docs path to the block file’s directory (instead of a repo-root reference), which helps ensure the generated guidance points to the correct location in monorepos; - replaces the imperative “Keep this block…” with a verify pointer to generate-agent-files.js and a rationale for why committing it keeps the tree clean; - updates the block content to indicate that it is generated and re-added by the dev tool, reducing the likelihood that a malicious patch can cause the block to persist or be trusted as an injected directive. This reduces the risk of prompt injection via the agent rules block in multi-repo or monorepo environments.

This commit implements browser-variant splitting to prevent server-only modules from leaking into client/browser bundles. Prior to this change, certain server-side modules (e.g., server/app-render/* and related instant-validation code) could be pulled into the browser bundle via dynamic requires or lack of proper .browser.ts/.browser.tsx separation, enabling potential information disclosure about server internals (module paths, server boundaries, implementation details) through the client bundle. The patch introduces explicit browser-variant modules, moves server-specific logic to client-safe variants, and updates imports to ensure browser bundles do not include server internals. It also removes a prior browser boundary implementation that relied on server-bound logic and replaces it with a browser-safe impl, along with a browser-only stub for certain validation boundary pieces. Overall, this is a hardening fix to reduce leakage of server internals into client payloads.

The commit patches a remote code execution (RCE) vulnerability stemming from evaluating user-provided filter expressions with JavaScript's Function constructor in the Table filter path. Previously, code in TableNG/TableRT FilterList used new Function with the user-supplied expression, effectively executing arbitrary JavaScript (including IIFEs) in the client context when evaluating a filter expression. This could allow an attacker with UI access to run malicious code in the victim's browser (e.g., admin). The fix replaces the dynamic evaluation path with a safe expression parser (parseExpression) and a predicate-based evaluation, memoizes the evaluation, and ensures invalid/unparseable expressions do not execute or fall back to unsafe behavior. Tests explicitly verify that arbitrary JavaScript IIFEs are not executed and that unparseable expressions yield no results, mitigating the RCE risk.

RBAC enforcement gap for serviceaccount operations in Grafana's unified storage layer. The commit adds 'serviceaccounts' to the iam.grafana.app allowlist in the RBAC-enabled access path, ensuring that serviceaccount search/list/read operations are subject to proper RBAC checks. This prevents unauthorized users from enumerating or accessing service account metadata. The change is a security fix addressing insufficient access control rather than a mere cleanup or dependency bump.

The commit fixes an information-disclosure risk where inline secure values created during a failed guaranteed update could be left orphaned if the update encounters a conflict. Previously, when a guaranteed update conflicted (HTTP 409), the code would retry the read/update without cleaning up any inline secure values created during that failed attempt. This could allow leakage of sensitive inline secrets (tokens) that were generated during the failed attempt to persist, potentially exposing them to subsequent operations or access controls. The fix ensures that on a conflicting update, the inline secure value is cleaned up (finish/delete) before retrying, preventing leakage of secrets.

Security fix: The commit adds 'teams' to the iam.grafana.app allowlist in the authzLimitedClient, ensuring RBAC checks are applied to team search/list/read in unified storage. Prior to this change, any resource not explicitly on the allowlist defaulted to allow-all, which allowed users to enumerate or view all teams in unified storage (specifically in dual-writer mode 4/5). This created an information disclosure vulnerability where unauthorized users could discover team names (and potentially associated metadata) they should not have access to. The fix ensures that team-related operations are evaluated by the real access control client, aligning teams with users, dashboards, and folders in RBAC. The production impact is mitigated by migrating teams to unified storage and by ensuring authorization is consistently enforced for teams as with other resources.

The commit introduces RBAC-based gating for the Dashboard Templates UI. It adds DashboardTemplatesRead/Write to AccessControlAction, introduces canReadDashboardTemplates/canManageDashboardTemplates helpers, and hides custom template UI elements (including the custom templates tab, the save-as-template action, and related modal mounts) unless the user has the appropriate permissions. The changes ensure the UI does not present actions that would be rejected by the backend authorizer, replacing previous behavior where certain template actions could be exposed in the UI without confirming the user has the necessary backend permissions. This addresses potential authorization bypass/privilege escalation vectors via the UI by aligning frontend visibility with API permissions. The changes touch multiple UI paths (QuickAdd, NewActionsButton, DashboardScenePage) and include test updates to reflect the gating logic.

The commit implements a fix for a race/authorization bypass in provisioning job mutual exclusion. Prior to this change, ownership of a provisioning job was inferred from a claim timestamp label alone, with no worker identity. Because job names are deterministic (repository + action), a worker could lose ownership (e.g., the job is reaped and re-created under the same name) but still renew or complete the job, potentially causing two workers to execute the same job or allow a worker to delete a job it no longer owns. The patch introduces a per-claim owner token (provisioning.grafana.app/claim-owner) and verifies both the owner token and the object UID before renewing or completing a lease, making a lost lease effectively a hard failure (ErrLeaseLost). It also adjusts claim/rollback behavior and adds tests. Overall, this is a real vulnerability fix addressing a race-condition/authorization bypass risk around mutual exclusion for provisioning jobs.

The commit adds strict validation for time-series limits to prevent out-of-range values that could lead to data corruption during ingestion. Specifically, maxLabelsPerTimeseries, maxLabelNameLen, and maxLabelValueLen must be within the inclusive range [1, 65535]. The patch introduces a MustInit function that validates these inputs and logs a fatal error if they are out of range, then initializes the limits. This addresses a potential data integrity risk from invalid configuration inputs, by failing fast instead of proceeding with corrupted/unsupported limits.

The commit fixes undefined pointer arithmetic in lib/bootconfig.c: xbc_snprint_cmdline() when the function is called with a NULL buffer and size 0. The original code computed end = buf + size and used buf in pointer arithmetic, which is undefined when buf is NULL. The patch introduces a local length accumulator (size_t len) and avoids performing pointer arithmetic on buf. It uses len to track the written length and updates snprintf calls with a conditional buf ? buf + len : NULL and rest(len, size), ultimately returning len. This prevents build-time UBSan/FORTIFY_SOURCE failures and reduces risk of memory-safety issues in edge cases where a caller queries the required length (buf=NULL, size=0). While primarily a correctness/memory-safety fix, it addresses a class of undefined behavior that could otherwise crash or destabilize builds or runs under instrumentation.

The commit removes per-object create permission for the team type in Grafana's Zanzana authorization engine. Previously, a user who was an admin of a team could leverage a per-object create relation (team:create) on a specific team to create or list per-object team resources, effectively allowing a privilege escalation that could enable unauthorized creation/list results for teams. The fix enforces that team creation is governed at the namespace level via group_resource (e.g., teams:create translates to group_resource:iam.grafana.app/teams) and removes the per-object create relation from the team type and related guards. This aligns with the semantic that teams are not containers and prevents admins from exploiting per-object create paths. Tests were updated to reflect that team admins no longer get per-object create permissions and are denied for per-object creation/listing; creation flows must go through group_resource instead.

This commit implements a real security fix: when creating folders via Grafana's app platform Kubernetes-based folder API, root-level folders are now assigned the grafana.app/grant-permissions annotation with the value 'default'. This ensures that Kubernetes RBAC default permissions are written for those resources. Prior to this change, folders created through the app platform API at root could lack the grant-permissions annotation, potentially leading to misconfigured authorization and either exposure of resources or unintended access due to missing default RBAC grants.

The commit removes the SSO auto-login feature toggle (frontendServiceSSOAutoLogin) and related gating logic. Previously, bootdata would include an AutoLoginRedirectURL only when the SSO auto-login flag was enabled. After the change, bootdata generation unconditionally populates AutoLoginRedirectURL for unauthenticated users, effectively exposing auto-login flow configuration in bootdata without a toggle gate. This can lead to information disclosure about the SSO auto-login mechanism and potentially enable unintended automatic authentication flows if an IdP session exists, creating an avenue for automatic login without explicit user action. In short, removing the toggle appears to re-enable or escalate auto-login exposure rather than securely deactivating it, depending on how getAutoLoginRedirectURL behaves when no flag guard is present. The change also removes the feature flag from the registry and related codegen artifacts, removing a guardrail that previously prevented bootdata-based auto-login info from leaking to clients.

The commit adds an authorization wrapper to the /api/library-elements/name/:name endpoint, requiring ActionLibraryPanelsRead permission. Prior to this change, the endpoint was not protected by the per-route RBAC check, enabling potential information disclosure of library element names to users without the read permission. The change also includes a test that verifies the route now enforces the read permission. This is a genuine vulnerability fix: it closes an authorization bypass and reduces information leakage by ensuring only users with the proper permission can query library element names.

The commit fixes an authorization vulnerability caused by misaligned per-type relation sets for IAM resources in the OpenFGA-based authorization logic. Previously, flat IAM types shared a full per-object RelationsTyped set (renamed to RelationsFolder) and did not correctly reflect per-type capabilities (e.g., create on users/service-accounts, and subresource relations). This led to incorrect IsValidRelation checks during List/Check/BatchCheck, which could cause invalid calls to fail the entire operation or poison other results in a batch (dropping valid wildcard grants). The patch introduces precise per-type relation sets (RelationsFolder, RelationsTeam, RelationsUser, RelationsServiceAccount, RelationsSubresourceTyped) and adjusts the gating logic so subresource checks are evaluated independently and before base relations. It also restructures checkTyped/listTyped to gate only the direct per-object checks, ensuring valid subresource grants are correctly honored. Added unit tests cover per-type sets and List/Check/BatchCheck interactions, including subresource create behavior and ensuring invalid per-call-site relations no longer break batch processing.

The commit fixes a race condition in param resolution for ValidatingAdmissionPolicy. When evaluating a policy-binding, the param (e.g., a ConfigMap) is resolved via an informer cache. If the param is created concurrently and the informer cache has not yet observed the new object, CollectParams may treat the param as NotFound, triggering the ParameterNotFoundAction (which can cause an admission denial or incorrect evaluation). The patch adds a direct API fallback using a dynamic client and RESTMapper to fetch the Param resource when the cache misses, ensuring correct policy evaluation even under race conditions. This is a real vulnerability fix in admission control logic.

The commit fixes a potential Denial of Service (crash) in ResourceSlice validation by validating that CapacityRequestPolicyRange.validRange.step, when present, is strictly greater than zero. Previously, a zero or negative step could lead to a runtime panic during validation (or related processing), risking a crash or DoS of the API server. The patch adds a guard to reject non-positive steps with a validation error and accompanies tests for zero and negative step values. This indicates a security-hardening fix rather than a mere dependency bump or refactor.

The commit fixes a race condition in the watch cache where the indexer could be mutated outside the synchronization lock while constructing or returning the latest snapshot. The patch adds a locked/safe path for obtaining the latest snapshot (getLatestSnapshotLocked) and introduces a read-only snapshot wrapper that derives from the indexer without mutating it. This prevents concurrent writers from corrupting the snapshot or readers from observing partially-mutated state, reducing the risk of data corruption, inconsistent reads, or leakage in concurrent scenarios.

This commit hardens handling of TerminationGracePeriodSeconds (TGPS) on Pods. Previously, negative TGPS values could slip through conversion paths or rely on implicit defaults, potentially causing incorrect pod lifecycle behavior during termination. The fix moves defaulting out of conversion and into Pod defaults, adds non-negativity validation for TGPS in Pod validation, and ensures decode-defaulting clamps negative values to 1 when reading from storage. It also adds tests for: (a) nonnegative TGPS validation, (b) defaulting behavior in Pod defaults, and (c) compatibility behavior that clamps negative TGPS to 1 when decoding from etcd. Overall, this is a security-hardening input-validation fix to prevent misconfiguration from leading to unpredictable pod termination behavior and potential denial-of-service-like issues.

The commit implements API-layer validation for MT annotations to bound timestamp data. It introduces maxFutureWindow (7 days) and retentionTTL-based past-time bounds, and validates timeEnd relationships. It also moves validation into the API path (Create), with explicit checks for future times, past retention, and timeEnd ordering. Additionally, it adjusts how names are validated and removes in-store implicit name generation. This reduces the risk of accepting invalid or malicious timestamp data that could affect retention, data integrity, or edge-case behavior in annotation handling.

The commit extends the Zanzana authorization schema to include create permissions for user and service-account resources. Previously, create operations on these resources were not defined in the authorization checks, which could allow a user with read/list permissions to trigger creation of users or service accounts without proper authorization. This patch ensures that create actions are evaluated by the authorization layer, addressing an authorization/access-control vulnerability related to resource creation.

The commit fixes a use-after-free condition in the thermal subsystem by ensuring testing module code cannot be executed after the module is removed and by flushing/ordering work items and resources during cleanup. It additionally fixes dangling resources in the Intel thermal_throttle driver by guarding the resource acquisition path and returning the correct error path, preventing use-after-free or use-after-uninit usage. The net effect is removal of a window where testing code or scheduled work could dereference freed objects, i.e., a classic use-after-free risk in the thermal testing path and a safer failure path in the Intel thermal_throttle path.

The commit merges Samba SMB3 client fixes into the Linux kernel SMB/CIFS client and includes multiple security-related memory-safety improvements. The changes address several potential vulnerabilities in the SMB3 client stack, notably: - Removal of potential double-free conditions in replay paths (e.g., query directory replay, change notify replay, SMB2_open/_ioctl/close/flush replay paths) and corresponding memory-management hygiene in receive_encrypted_standard and related code paths. - Correction of memory leaks by properly handling dynamic/buffered responses (dynamic buffers for querydir/readdir, and safe freeing paths for various buffer types). - Safer handling of buffers and error paths when processing compound responses, including proper initialization and reinitialization of response buffers across replay branches. - Improvements to security descriptor/ACL handling in id_mode_to_cifs_acl and related ACL copy/replace logic, including a more robust handling of owner/group SIDs and a guard to avoid applying ACL changes when none are needed, plus better flag management (aclflag) during ACL updates. - Minor fixes around dynamic buffers, error printing, and POSIX extensions handling to prevent incorrect privilege manipulation or misapplied security descriptors. Collectively, these changes reduce risks of memory corruption (double-free/use-after-free), memory leaks, and incorrect ACL/security descriptor handling in SMB3 client operations.

The commit enforces service identity authorization when resolving display metadata (createdBy/updatedBy) by obtaining the requester and using a service-scoped context for the user lookup. This prevents callers without proper permissions from triggering user display-name resolution via ListByIdOrUID, reducing potential information exposure (who created/updated an object) and potential privilege misuse. Prior to this change, display-name resolution could be performed with a less-privileged context, allowing leakage of user identities or names through internal metadata enrichment.

The commit fixes an information disclosure vulnerability where non-user identities could list preferences beyond namespace (org) preferences. Prior to the fix, non-user identities (e.g., service accounts, image renderers) could view user and team preferences as well. The new logic restricts access so that non-user identities may only retrieve namespace preferences, while user identities can view their own user and team preferences. This reduces potential exposure of user and group-level preferences.

The commit fixes RBAC/authorization behavior for user-management actions in the Zanzana resolver. Previously, scope translation for user-related actions could be mis-scoped due to hardcoded group/version/resource and simplistic UID-to-ID translation. The patch derives IAM GVRs from resource info (avoiding drift from hardcoded iam.grafana.com) and adds explicit handling to map user-related actions to the correct legacy RBAC scope (global.users vs users), including a special case for users.permissions:read (org-level) and a UID-to-ID translation path for users actions. Tests accompany the change to validate correct scoping and translations. This reduces the risk of over-privilege or incorrect access via mis-scoped permissions in legacy RBAC.

The commit Adds ignore-listed stack frame disclosure in React DevTools by introducing an ignore-list mechanism for stack traces and a UI toggle to show/hide ignored frames. It adds StackTraceGroup and related changes to only render internal frames when the user explicitly opts in, and to hide frames that are marked as ignored by the symbolication layer. This mitigates an information-disclosure risk where internal implementation details and file paths could be visible inDevTools stack traces. By default, suppressed internal frames are not shown, reducing leakage of internal paths and module structure.

This commit adds strict caps on embedded panel content and dashboard descriptions that are stored via the unified storage embedding path. It introduces maxItemContentBytes (4 KiB) for the combined panel content and maxDescriptionBytes (2 KiB) for panel descriptions, plus a UTF-8 safe truncation helper (truncateUTF8). The goal is to prevent unbounded growth of payloads (e.g., giant SQL queries or verbose descriptions) from being embedded into items, which could otherwise lead to Denial of Service / resource exhaustion scenarios. The changes are accompanied by unit tests verifying that content is truncated to the defined limits and that truncation respects UTF-8 rune boundaries. This is a genuine vulnerability fix, not just a dependency bump or a non-functional cleanup.

The commit fixes an authorization-related error handling bug in which a forbidden user lookup could yield HTTP 500 Internal Server Error instead of HTTP 403 Forbidden. The code now detects Kubernetes-style Forbidden errors (k8s.io/apimachinery/pkg/api/errors.IsForbidden) and returns a proper 403 with a clear message ('Access denied to user') instead of leaking internal error information via a 500 response. This reduces information disclosure and ensures correct signaling of access control failures for user lookups. The change touches both middleware (middlewareUserUIDResolver) and specific user endpoints to consistently map forbidden errors to 403.

The commit replaces direct webhook processing with a provider-agnostic WebhookHandler and a RequestProcessor interface, introducing signature validation (ValidatePayload) and replay protection (seenOrAdd) for inbound GitHub webhooks. Prior to this change, webhook deliveries could potentially be processed without proper authentication and without protection against replayed payloads, enabling spoofed webhook events or repeated triggering of provisioning jobs. The patch enforces HMAC-based signature validation using a configured secret and blocks replayed deliveries, mitigating authentication bypass and replay attack risks. It also refactors the code to normalize inbound webhook events into internal WebhookEvent structures.

This commit hardens access controls for PCIe P2PDMA by blocking DMA provider creation and CPU access for non_mappable BARs. Specifically: - In pcim_p2pdma_init, if the PCI device has non_mappable_bars set, the function now returns -EOPNOTSUPP, preventing P2PDMA initialization for that device. - In pcim_p2pdma_provider, if non_mappable_bars is set, no provider is created for the given BAR. - The device whitelist is updated to include Intel DSA, IAA, and QAT devices, presumably to permit P2PDMA usage for these devices while still enforcing non_mappable_bars restrictions. - The non_mappable_bars documentation is clarified to indicate that CPU or peer access is restricted, reinforcing that such BARs should not be materialized for DMA by either CPU or P2PDMA. Overall, this is a real vulnerability fix addressing improper DMA access to non-mappable PCI BARs, tightening memory safety and access control for DMA pathways.

The ReleaseAssetServer in flutter_tools previously scanned three roots (build output, Flutter SDK root, and the project root) to resolve each request. Because the project root and the Flutter SDK root were included in the search without restricting file extensions, arbitrary files under those roots (for example, .env, keystore/signing configs, or SDK internals) could be exposed via the web asset server. The patch tightens these roots to only serve source-map related files (.dart and .map) from the project and SDK roots, while the build/web output remains unrestricted. This fixes an information-disclosure vulnerability where sensitive project/SDK files could be exposed to remote clients when serving release/profile/wasm web builds.

The commit adds logic to strip folder-related annotations from V2 resource exports when sharing externally, mitigating an information disclosure risk where internal folder metadata (e.g., AnnoKeyFolder, AnnoKeyFolderTitle, AnnoKeyFolderUrl, and related permission annotations) could be leaked to external consumers. Prior to this change, V2 resource exports could include folder metadata in metadata.annotations, potentially revealing folder structure and access controls. The fix ensures such folder annotations are removed from exported dashboards/resources, thereby reducing leakage of internal folder metadata.

The commit adds support for PeerCertSANs and deprecates PeerCertURI to tighten TLS peer certificate verification for backend connections. Previously, backend TLS policy could rely on legacy or insufficient validation (e.g., using PeerCertURI and/or CN) without explicit SAN verification, creating a potential TLS/MITM bypass where a certificate could appear valid despite SANs not being properly validated. The fix introduces explicit SAN-based matching (PeerCertSANs) and deprecates the older PeerCertURI path, updating defaults/docs to ensure SANs are explicitly verified during TLS handshakes.

The commit patches potential path traversal during restore. It validates every source part against the configured storage directory (storageDataPath) to prevent crafted backup object names from writing outside the destination. It also adds a defensive panic in NewDirectWriteCloser if a part would be written outside the storage directory. This addresses a local file write vulnerability via crafted object names in backups (path traversal during restore).

The commit implements a security fix by adding a configuration flag http.header.disableServerHostname to disable the X-Server-Hostname header in HTTP responses. Previously, VictoriaMetrics components always included X-Server-Hostname with the server's hostname in responses, which leaks internal host information. This patch mitigates the information disclosure risk by allowing operators to suppress the header. Tests were added to verify the option's behavior. This is a targeted fix for information disclosure via an HTTP response header.

The fix mitigates a potential XSS in the standalone DevTools error rendering by replacing innerHTML-based HTML construction with DOM nodes and textContent. Previously, error messages were interpolated directly into an HTML string and assigned to innerHTML, which could allow HTML/JS injection if the error message came from an untrusted source. The patch now builds the error box using DOM elements and sets textContent for header and content, ensuring any embedded HTML is treated as text.

The commit fixes an authorization bypass by restricting creation of the per-org Alerting Config singleton to the service identity only. Previously, non-service actors with create permissions could create or seed the singleton via the API, potentially enabling unauthorized configuration of per-org alerting settings. The patch seeds the singleton via the sync worker when the UID is not configured and denies create for non-service identities; only the seeder (service identity) may create, while humans/GitOps can only update an already-seeded object. It also introduces a NotConfigured state for the sync path and updates tests accordingly.

The commit adds folder-scoped authorization checks for resources that are not present in the RBAC mapper (mapper miss). Prior to this patch, wildcard resource grants (scope: "*") could be used to bypass folder-scoped access control on unmapped resources, enabling privilege escalation. The fix introduces a dedicated path listPermissionWithFolderAuthz to enforce that access is granted only when both a resource-level stack role (scope: "") exists and the user has appropriate folder grants. It prevents wildcard grants from automatically authorizing access to folder-scoped resources that are not mapped in the RBAC mapper.

The commit patches a potential Denial of Service (resource exhaustion) in Grafana provisioning. Previously, selective export (push and migrate) would fetch each explicitly listed resource individually, which meant that an unbounded or very large resources list could cause unbounded per-resource lookups and heavy CPU/memory usage. The fix caps the number of explicitly requested resources to 100 and validates this cap at admission time, preventing oversized provisioning jobs from entering processing and thereby mitigating DoS risk. Tests were added to verify behavior at and beyond the limit.

The commit fixes an authorization/batch-check bug in user search. The code previously included access-control checks for verbs that are not defined on the authz model's user type (e.g., org.users:add / VerbCreate and users.permissions:read / VerbGetPermissions). When performing batch access-control checks for user search, evaluating an unsupported verb can cause the batch to fail (e.g., reporting that a relation is not found) and blank out AccessControl metadata for results. This could lead to incorrect authorization decisions or information disclosure during user search. The patch removes unsupported verbs from the batch checks, guards the tests to only use verbs defined for the user type, and introduces a test ensuring only supported verbs are used.

The commit adds a canonical alias for the default routing tree name and canonicalization helpers, wiring them into authorization/identity checks and API responses. It ensures that the default routing tree can be referenced via both the legacy name and the new alias without changing the underlying RBAC identity, and it reserves both names to prevent creation as managed routes. This addresses potential RBAC/name-based authorization inconsistencies where clients could refer to the default routing tree using different names, leading to inconsistent authorization behavior or unintended access. The changes stabilize RBAC scopes by enforcing a single internal identity for the default routing tree while preserving the canonical input/output experience for clients.

The commit fixes an authorization bypass / RBAC misconfiguration in provisioning resources and repository subresources. It replaces lax checks that could let mis-scoped roles (e.g., editors) perform admin-level provisioning actions by borrowing the jobs resource as a proxy, with semantically correct RBAC checks using explicit resources and verbs (e.g., repositories:write for admin actions, jobs:create for editors). It also expands service identity permissions (provisioning.*) to align delegated permissions, and adds tests to cover the new authorization logic. In short, it tightens access control for provisioning and repository subresources to prevent privilege escalation and incorrect access, and adds coverage to ensure future changes don’t regress this behavior.

This commit fixes an authorization/access-control issue in Grafana's Zanzana translation and tuple generation related to team permissions. The changes introduce unscoped mappings and skipScope handling for certain team actions, ensuring proper scoping when translating permissions to access-control tuples. Prior to this fix, some team-management actions could be translated without a concrete scope or could be mapped in a way that bypassed per-team scoping, potentially enabling privilege escalation or unauthorized access across teams. The update reworks how team actions (including teams:create and teams.roles:* related mappings) are translated to the underlying IAM resources, and clarifies which actions require per-team scope versus which can be treated as global. As a result, authorization checks should enforce correct scoping, reducing the risk of improper privilege assignments.

The commit implements folder-scoped authorization (RBAC) for Kubernetes-native resources and adds a path to enforce a 'stack role AND folder permission' model for K8s-native resources not present in the mapper. Prior to this fix, such resources could fall back to a K8s-native mapping, which could allow a user with a wildcard/stack-role permission to access resources without proper folder-scoped authorization, potentially enabling privilege escalation or access to folders the user should not reach. The changes explicitly introduce folder-context checks for mapper-miss resources and add tests around K8s-native fallback behavior, effectively closing a gap where folder-scoped permissions were not consistently enforced for K8s-native resources.

The commit fixes a memory-safety vulnerability in the Linux FlAccessibleTextField implementation by adding explicit bounds checks when computing substrings and when deriving string bounds from ATK client requests. Specifically: - get_substring now clamps start and end to [0, length] and enforces start <= end before calling g_utf8_substring, preventing out-of-bounds memory access if an ATK client passes offsets beyond the text length. - get_string_at_offset clamps start and end to [0, max(n_attrs - 1, 0)] before accessing the PangoLogAttr array, mitigating potential out-of-bounds access when ATK/granularity requests refer to attributes beyond the available attributes. The patch also adds tests covering offset-beyond-end, empty text, and offset-at-end boundary scenarios. This is a genuine memory-safety vulnerability fix rather than a pure dependency bump or cosmetic cleanup. In short, external ATK clients that query text with out-of-range offsets could previously trigger undefined behavior or memory access violations; the fix ensures all indexing is bounded and safe.

The commit fixes a DoS vector where a non-RSC HTML request bearing the Next-Router-Prefetch header could be treated as a prefetch, entering a partial prefetch tree and causing HTML rendering to suspend until a timeout. The fix ensures isRSCRequest is determined before parsing prefetch modes and requires isRSCRequest for prefetch values 1, 2, and 3, including route-tree prefetch classification. It also adds a dedicated regression fixture that exercises non-RSC prefetch handling to ensure HTML responses are not blocked and that RSC prefetches remain functional.

The commit adds per-resource authorization checks for the Promote operation of merged Alertmanager import configurations. It evaluates permissions for each resource type that could be added by a promotion (receivers, routes, templates, time intervals, and inhibition rules) and requires the caller to hold the corresponding permissions for all resources included in the merge. This prevents unauthorized privilege escalation via promoting merged configurations. The change also includes tests validating various authorization scenarios for promote. The vulnerability being addressed is an authorization bypass/privilege escalation risk where promotion could otherwise modify main configurations without granting all necessary per-resource permissions.

The APNG image decoder in Flutter was vulnerable to a memory-safety/integer-overflow issue when parsing malformed APNG chunks. Before the fix, the code path could call GetChunkSize on a chunk without first validating that the chunk's declared data length would fit in the remaining buffer. If a chunk contained a corrupted data_length (for example, a large 32-bit value like 0xFFFFFFFF) and the size_t on the platform was 32-bit, the size calculation could overflow, leading to an incorrect end-position and potential out-of-bounds access or a crash during parsing. The change adds explicit bounds checks before using the chunk data length, ensures the header fits within the remaining buffer, validates the remaining space for the data and CRC, and refrains from performing pointer arithmetic using an unvalidated length. The unit tests added (e.g., FdATWithOverflowDataLengthIsRejected) exercise a fdAT chunk with an overflow-inducing declared length and verify the parser rejects it without crashing. In short, this is a real memory-safety vulnerability fix in the APNG chunk length handling.

The commit fixes a race between cgroup_writeback_umount() and inode_switch_wbs()/cleanup_offline_cgwb() in the VFS writeback path that could lead to a use-after-free on percpu counters and 'Busy inodes after unmount' during unmount of a superblock. The race arises in a window between inode_prepare_wbs_switch() returning true (after SB_ACTIVE check and grabbing the inode) and the subsequent wb_queue_isw() call. If cgroup_writeback_umount() observes a non-zero isw_nr_in_flight while flush_workqueue() finds nothing queued yet, it would drop its reference to the inode and later iput would hit freed percpu counters. The patch closes the window by wrapping the critical region in RCU read-side critical sections and synchronizing the umount path with per-superblock in-flight counters (s_isw_nr_in_flight) and pin/unpin/drain helpers. It also removes an obsolete rcu_barrier, and introduces per-sb in-flight tracking and targeted writeback handling to improve safety and correctness of the writeback code under cgroup churn. This is a genuine memory-safety race fix with security implications, not merely a dependency bump or code cleanup.

The commit fixes how edge sandbox timer callbacks bind their this value. Previously, the edge timer polyfills bound this to globalThis (the outer Node global), which could allow sandboxed code running in the Edge Runtime to capture the outer global (including require) and potentially access restricted APIs (e.g., fs). The patch binds this to the edge runtime global object instead of globalThis, preventing the sandboxed callback from reaching into the outer Node environment. Tests accompany the fix, guarding against sandbox escapes.

This commit fixes an authorization bypass in the provisioning workflow by wiring explicit RBAC checks for the Playlist resource. Previously, provisioning could export/sync playlists without proper RBAC checks because the Playlist resource (playlists) did not have a defined mapping to the two-action model (read/write) and the provisioning identity could bypass checks. The patch adds: (1) service identity permissions for playlists (playlists:read, playlists:write), (2) provisioning identity token permissions to include playlist-related scopes, (3) an RBAC mapper entry for playlist.grafana.app mapping verbs to playlists:read / playlists:write, with create treated as write and scope skipping for creates, and (4) tests validating the provisioning identity carries and enforces the correct permissions. In short, this closes an access-control gap that could allow unauthorized export/sync of playlists during provisioning.

This commit fixes a CSP/unsafe-eval vulnerability in the DataFrames join materialization path. Previously, joinTabular used runtime code generation via new Function(...), which creates a function at runtime and can trigger CSP violations or be exploited if input data could influence the generated code. The patch removes the unsafe-eval usage by replacing the dynamic codegen path with a column-major, precomputed per-row source plan for materialization. This preserves behavior while eliminating the runtime code generation step that posed a CSP/code execution risk.

This commit fixes a vulnerability where a package-level logger for the Pyroscope datasource was constructed before the in-process logger override is installed. As a result, debug-level JSON logs could be emitted to stderr regardless of GF_LOG_LEVEL, potentially leaking sensitive information from log payloads. The logger is now created inside ProvideService and threaded through to the datasource and helpers, ensuring logs respect the configured log level.

The commit adds explicit input validation when constructing CloudWatch Logs queries from data sources. It introduces validation for logDataSources entries (ensuring non-empty name/type, allowed characters, uniqueness, and a maximum of 10 selections) and builds a sanitized query plan. This mitigates potential injection or malformed-input risks when users supply data source identifiers that could influence the CloudWatch Logs query string.

The commit re-enables forwarding of Azure managed identity related environment variables from the host to plugin processes, gated on the Azure settings and plugin allowlist. Specifically, when Azure managed identity or workload identity is enabled and a plugin is on the forward list, the provider now forwards environment variables such as IDENTIY_ENDPOINT, IDENTITY_HEADER, IDENTITY_SERVER_THUMBPRINT, IMDS_ENDPOINT, MSI_ENDPOINT, MSI_SECRET, AZURE_TENANT_ID, AZURE_CLIENT_ID, AZURE_FEDERATED_TOKEN_FILE, and AZURE_AUTHORITY_HOST to the plugin process. This restores proper credential discovery for Azure plugins by the azidentity SDK, which can rely on these env vars to locate the local managed identity endpoint. The fix addresses a regression introduced in 12.4.0 that stopped forwarding host env vars, which could cause plugins to fail authentication or fall back to less secure/default endpoints. While this improves correct authentication flow for plugins, it also expands the surface area exposed to plugins by handing them potentially sensitive identity-related environment data. The change is gated by an allowlist and enabled identity modes, aligning with a prior AWS fix that forwards similar host vars to plugins.

This commit fixes a potential access-control vulnerability in RBAC permission lookups by ensuring that permission lookups (subject resolution for resource permissions) are performed using a service identity context rather than the caller's user context. Previously, the code resolved subject information (users/teams) using the requesting user's context, which could allow information disclosure or authorization bypass when the caller lacked certain permissions to read subject data. The patch introduces a service-identity lookup context (lookupCtx) and uses it for fetching user and team details, mitigating authorization bypass risks and ensuring permission data is retrieved under a trusted service identity.

The patch fixes a security vulnerability related to permission subject resolution in Kubernetes-backed user lookups. Previously, resolution of user/team subjects when listing resource permissions could rely on the caller's identity and, in some configurations (especially multi-instance deployments with unified storage and per-instance SQLite), fall back to the legacy SQL store. This could lead to incomplete or incorrect permission data being exposed or leaked, or legitimate subjects being hidden (e.g., empty userId/userLogin fields) due to a 403 from accessing principals or silent fallback. The commit threads the request context through Kubernetes-based lookups (GetByUID) so that the k8s lookup uses a proper request-scoped identity, and resolves subjects using a service identity instead of the caller's identity, aligning with the legacy behavior and preventing information leakage or authorization bypass when enumerating or displaying resource permissions. It also adds a Kubernetes GetByUID implementation to avoid falling back to legacy stores entirely in the k8s path.

The commit fixes an information disclosure risk in Grafana where search results could reveal dashboards that reside in the root/general folder to users who should not have access. The change unifies handling of the root folder sentinel ("" vs "general"), ensures root dashboards are treated consistently, and filters out root dashboards from being surfaced as shared when the requester lacks permissions. It also updates permission instrumentation for root dashboards to ensure correct access control. Collectively, these changes reduce leakage of dashboard existence/metadata via search results and align root-folder handling across search backends and API surfaces.

The commit fixes case-sensitivity handling for secret fields in alerting contact point settings. It introduces case-insensitive field lookup for secret values, ensures secret keys are moved/encrypted consistently even when keys differ only by case, and rejects duplicate secret keys that differ only by casing in provisioning and receiver services. This prevents ambiguous secret processing that could lead to partial redaction/encryption or plaintext leakage of secrets. The changes include: a MapGetCaseInsensitive helper, extractFieldCaseInsensitive logic, updated encryption paths to use case-insensitive lookups, and added validations to reject mixed-case duplicates. Tests covering case-insensitive extraction and duplicate-detection were added/updated.

Summary of the issue: - The commit fixes an authorization propagation gap in the Zanzana translation layer by adding missing mappings for permission-management actions (folders.permissions and dashboards.permissions). - Prior to this change, granting permission-management actions could be ignored by the translation logic, causing get_permissions/set_permissions relations not to be created for folders and dashboards. This could lead to improper access control or privilege escalation because permission changes were not propagated to the underlying authorization relations. What the fix does: - Adds mappings for folders.permissions:read/write and dashboards.permissions:read/write to translate into the appropriate OpenFGA relations (get_permissions / set_permissions) either at the folder level or scoped within the dashboard-subresources as appropriate. - Extends tests to cover the new translations, including both per-resource and scoped (folder/dashboard) cases. Impact: - Restores proper propagation of permission-management actions to the underlying permission relations, ensuring that granting those actions correctly updates get_permissions/set_permissions tuples. - This is a targeted security fix for authorization propagation and is accompanied by tests validating the mappings.

The commit implements a config-driven, capability-based provisioning resource model and gates provisioning actions behind an enabled/disabled flag per resource. It replaces hardcoded, per-resource flags with a shared, config-derived set of resources and enforces authorization boundaries by: - Computing the effective set of resources from configuration (and registered extras) and exposing an Enabled/Disabled state per resource. - Routing requests for non-built-in groups to an aggregated API server only if a valid aggregated_server_url is configured, otherwise failing fast at startup. - Providing ResourceClients abstraction to ensure only enabled resources are acted upon by provisioning consumers (authorizer, folder-annotation writer, export, migrate, quota, etc.). - Rejecting write/act requests for resources that are not enabled or not supported, via startup validation and gate checks. - Surfacing the full declared set (including disabled ones) through the settings endpoint for frontend visibility, while ensuring the provisioning pipeline only processes enabled resources. This addresses an authorization/access-control risk where provisioning endpoints could be invoked for resources that should be disabled or misrouted to inappropriate API servers. The new gating and validation reduce exposure by ensuring that disabled resources cannot be acted upon and that routing is explicit and config-driven. Impact: prior to this patch, resource enablement was less explicit and could permit unintended access or misrouting under certain misconfigurations. The patch fixes this by introducing strict, config-driven controls and centralized resource gating.

The commit fixes an access-control reliability bug where in-place mutation of List response identity strips caused by the list helper functions could mutate the cached ListObjectsResponse slice owned by the query cache. When query caching is enabled (CheckQueryCacheEnabled), a List call would downgrade the cached full object idents to bare ids. A subsequent BatchCheck query reads the same cache entry and matches on the full idents (FolderIdent/ResourceIdent). The mutated cache leads to membership lookups failing, potentially hiding resources the user directly has access to (RBAC/authorization decisions become incorrect). The fix makes the strip helpers return a new slice, preventing mutation of the cached response. This is a real vulnerability fix affecting authorization behavior and ensuring correct access decisions. Tests were added: TestStripHelpersDoNotMutateInput (unit) and TestIntegrationListDoesNotPoisonBatchCheckCache (integration).

The commit patches a real vulnerability where a request path, after being processed by StripPrefix or StripPrefixRegex, could be normalized to a different path than the one used for stripping. An attacker could craft a path that, after normalization, bypasses the intended prefix stripping and potentially access resources beyond the allowed path. The fix stores the original stripped path, runs path.JoinPath() to canonicalize, then rejects the request with 400 if the canonicalized path differs from the original stripped path. This prevents bypass via URL normalization differences (e.g., dot segments like . or .. or similar manipulations) after prefix stripping.

The commit fixes a Denial of Service vector in the BR/EDR signaling path of Linux Bluetooth (L2CAP). Prior to this patch, the BR/EDR signaling channel allowed packets larger than the BR/EDR signaling MTU (MTUsig, defined as 48 octets) to be accepted and parsed. An attacker in radio range could send a single oversized BR/EDR signaling packet (e.g., ~681 bytes) on the fixed-channel CID 0x0001 containing many L2CAP_ECHO_REQ commands. If processed, this could trigger a flood of L2CAP_ECHO_RSP frames (e.g., 168 responses) in a short time, causing CPU/L2CAP stack churn and a DoS. The patch enforces MTU for BR/EDR signaling by rejecting oversized signaling packets with a L2CAP_REJ MTU_EXCEEDED, before any command processing, using the first command header's identifier for the rejection. This fixes the DoS vector by eliminating the processing of oversized packets and preventing echo floods. The patch also defines L2CAP_SIG_MTU as 48 bytes.

The patch strengthens VMA state validation during UFFDIO_COPY retries in userfaultfd. Previously, mfill_copy_folio_retry() only compared the VMA's uffd_ops before and after the retry. If a VMA was replaced or its mapping changed (e.g., MAP_PRIVATE vs MAP_SHARED) while the VMA lock was released, the replacement could go undetected, leading to incorrect folio handling and potential memory-safety issues (including triggering a BUG() via folio_add_new_anon_rmap or enabling unintended folio injection into the page cache). The fix introduces a new mfill_retry_state struct and helper functions (mfill_retry_state_save, mfill_retry_state_changed, mfill_retry_state_put), and uses DEFINE_FREE to manage cleanup. It saves relevant VMA state before releasing the lock, compares state after reacquiring the lock, and retries or aborts if a change is detected. This mitigates a race condition that could otherwise lead to memory safety vulnerabilities in userfaultfd managed memory operations.

The commit introduces a sanitization step for headers derived from plugin rule metadata (specifically X-Rule-* headers) and propagates origin information via an X-Rule-Origin header. Before this change, plugin-derived metadata could be used to construct HTTP headers that were forwarded to data sources without stripping control characters, potentially enabling header injection or information leakage. The patch adds sanitizeHeaderValue to remove ASCII control characters (including CR and LF) and truncate values to 128 bytes, and applies it when building datasource headers. It also augments the GetEvalCondition to include an Origin metadata key (as '<origin>|<uid>') when available, and updates allowlists so X-Rule-Origin is forwarded consistently across eval paths. Overall, this is a defensive fix to prevent header manipulation and limit header sizes, reducing the risk of header-based attacks and information exposure from plugin-originated metadata.

This commit fixes a credential disclosure risk in Grafana provisioning. Previously, when a provisioning git repository URL used http:// and a token was configured, the token could be sent in cleartext during Git operations because git.NewRepository would attach basic auth unconditionally for HTTP. The validators did not reject this combination. The change adds an allowInsecure flag and updates validation to reject http:// URLs when a token is configured, except when running in development mode (app_mode=development) or when provisioning.allow_insecure is explicitly enabled. It also normalizes the URL scheme to lowercase to catch cases like HTTP://. The behavior for https:// URLs remains unchanged, and http:// is still allowed without a token. This reduces the risk of token leakage over non-TLS transport during provisioning.

The commit implements explicit recursion depth limits when computing dashboard summaries to prevent denial-of-service via crafted dashboards with deeply nested specs/panels. It introduces maxSpecDepth and maxPanelDepth, guards recursive reads for spec and panels, and logs when limits are hit. Tests were added to verify recursion bounds. This changes the parsing/processing code path that could previously recurse without bounds, thereby enabling resource exhaustion under crafted input.

The commit fixes an input validation/authorization edge-case by increasing the maximum length for role identifiers (role UID and role name) and expanding the storage column for role.uid from 40 to 253 characters. Previously, long role UIDs could be truncated by the storage layer (e.g., MySQL) or by API boundaries, potentially causing mismatches in access-control decisions and allowing misauthorization. The changes unify and enforce a clear maximum length (253) to prevent silent truncation and ensure proper validation before authorization checks.

The commit fixes a potential use-after-free race in l2tp_session_get_by_ifname. Previously, the function took a reference to a session by calling refcount_inc() after matching the session by its ifname. Between the string comparison (strcmp) and the refcount_inc(), another CPU could drop the session's refcount to zero and free the object, yet the reader would continue using the stale pointer. This could result in use-after-free when the caller dereferenced the returned session. The fix switches to refcount_inc_not_zero() and, if the increment cannot be performed (i.e., refcount is zero), it continues walking the list instead of returning a possibly freed object. This brings the ifname getter in line with the other session getters in the file that already use refcount_inc_not_zero().

The commit adds a per-skb tc_depth field (2 bits) and uses it to bound and detect recursion/duplicate processing in mirred and netem paths. Before this change, crafted traffic containing mirred/netem redirects could loop across devices or back through the backlog, leading to infinite processing, excessive CPU usage, or kernel instability (a Denial of Service). The patch stops duplicate recursion using tc_depth (with a limit MIRRED_DEFER_LIMIT = 3) and increments tc_depth along redirected paths, effectively capping the recursion depth and dropping packets that would cause loops. It also adjusts netem duplication logic to depend on tc_depth and removes a stricter check that prevented certain legitimate multi-netem configurations. Overall, this is a real vulnerability fix for a DoS via packet loops/recursion in netem/mirred.

Security fix verified. The commit adds per-request authorization filtering when retrieving datasources by type, ensuring that only datasources the caller has read access to are returned. This mitigates an information disclosure/authorization bypass path where unauthorized users could learn about datasources they should not see. The patch implements filtering in GetDataSourcesByType by enumerating the results and validating each datasource against the caller's read permissions. It also highlights a potential risky code path in ListConnections where a plugin-type query could bypass service-level authorization if not carefully wired, which the tests exercise to confirm proper behavior. Overall, this is a genuine vulnerability fix for information disclosure via datasource-type queries.

The commit fixes an authorization mapping issue around legacy role-management permissions (roles:read, roles:write, roles:delete) by introducing explicit reconciliation logic for these permissions into Zanzana tuples. It adds dedicated translation paths (RoleManagementToTuples) and safeguards to drop scoped role-management permissions that cannot be safely expressed (e.g., per-role scoped permissions). The changes also include tests that verify the exact tuple mappings for legacy permissions (get on roles and globalroles for read; edit on roles for write; delete on roles for delete) and ensure that unsafe/scoped permutations are omitted. This reduces the risk of privilege misconfigurations or unintended escalation due to improper translation of legacy RBAC permissions into the Zanzana access-control model.

Summary: The commit adds validation of the request key across all resource server endpoints in the unified-storage component. Prior to this change, a misconfigured client sending a nil request key could trigger an unvalidated code path in the storage-api server, potentially causing a crash (Denial of Service). The patch introduces verifyRequestKey and verifyRequestKeyCollection checks in Create, Update, Delete, Read, List, and Watch handlers, and surfaces invalid input as gRPC InvalidArgument errors instead of panicking or crashing. This is a real security hardening aimed at preventing crash-induced DoS caused by nil/invalid request keys. The accompanying tests also assert that InvalidArgument is returned for invalid keys. Impact: - Vulnerability type: Denial of Service (crash) via nil/invalid request key in resource API - Affected: Grafana Grafana 12.4.0 and earlier (the fix targets 12.4.0 and prior releases) - Fixed by: Input validation on request keys across resource server endpoints, replacing potential panics with structured errors. Rationale: - The storage server previously could crash if a nil or improperly formed request key was processed without validation. By validating at entry points for all relevant RPCs, the server avoids dereferencing nil pointers or entering invalid code paths. The change also standardizes error handling to return InvalidArgument rather than a crash, reducing the attack surface for DoS via malformed requests.

The commit adds panic recovery interceptors for the gRPC server to catch panics in unary and streaming RPC handlers, log a stack trace, and return a generic Internal error to clients instead of crashing the process. This mitigates a recovery-related crash/DoS vulnerability and reduces potential information leakage by ensuring panics are contained within the RPC handling path. The change wires the new interceptors into the server and also applies them to in-process channels used by some internal clients, with unit tests validating both unary and streaming panic handling.

The commit adds defense-in-depth authorization checks on internal delegated RPCs of the unified-storage resource server (PutBlob, GetBlob, ListManagedObjects, CountManagedObjects, RebuildIndexes). Previously, these internal RPCs could be invoked without validating the originating user's identity or namespace alignment, enabling potential cross-tenant access or information disclosure if the gRPC surface was reachable without the calling service in the request path. The fix introduces a requireUserNamespace gate and enforces resource-level access checks before performing actions, ensuring only properly authenticated/authorized users in the correct namespace can access or modify resources.

Summary of fix: - Introduced centralized git ref validation in apps/provisioning/pkg/repository/git with IsValidRef and commitHashRegex. An empty ref is allowed (defaulted to configured branch); a non-empty ref must be either a valid git branch name or a 7–40 character hex commit SHA. - Added ErrInvalidRef in the repository package to represent invalid refs. - Enforced validation at HTTP boundaries for provisioning endpoints: files and history connectors now reject unvalidated refs before reaching backends (local/git/github). - Updated tests to cover IsValidRef, RefValidation at files parsing, and history boundary checks. What vulnerability was fixed: Before this change, the provisioning API could forward an unvalidated ref value to backends (local, git, GitHub). This opened potential attack surfaces around input validation, including path/ref manipulation or injection risks when refs were concatenated into backend commands or data fetches. The commit explicitly moves ref validation to the HTTP boundary and centralizes ref validation logic, reducing the likelihood of unsafe input propagating to lower layers. Vulnerability type: Input Validation / Boundary validation for git refs (branch names and commit SHAs). Impact pathway: Unvalidated ref values could be forwarded to provisioning backends, enabling injection/manipulation of how refs are resolved by downstream systems.