Dashboard

The commit tightens access control for the /alerting/import-to-gma route by replacing a blanket Admin-only gate with a more granular evaluation that requires specific alerting permissions (AlertingRuleCreate, AlertingProvisioningSetStatus, AlertingNotificationsWrite). This prevents potential authorization bypass to the Grafana Migrate/Import to GMA flow by users who should not have access. The change includes code updates to routes, related components, and tests to verify permissions and feature flag gating. This is a genuine security improvement (authorization/authZ fix) rather than a mere dependency bump or cleanup.

This commit hardens Bitbucket webhook provisioning by gating the webhook enablement behind the presence of an Atlassian account email and by validating the email input. It introduces a UI rule that disables Bitbucket webhook integration when the Atlassian account email is not set, and adds an email field with proper validation for Bitbucket configurations. This reduces the risk of misconfigured or inadvertently enabled webhooks for Bitbucket repositories, addressing a security-related configuration issue (access control around webhook provisioning).

The commit fixes a memory-safety issue in the AMDGPU KFD CRIU restore path. Specifically, during kfd_criu_restore_queue, the code previously attempted to acquire queue buffers (kfd_queue_acquire_buffers) which could dereference null or invalid pointers if CRIU had not restored buffers or if MES pointers were not prepared. The patch adds a guard in init_user_queue: if MES is enabled and the queue’s wptr_bo is NULL, it logs a message and returns -EINVAL, preventing a potential null pointer dereference. It also removes the unconditional acquire_buffers call from kfd_criu_restore_queue, since acquiring buffers was only needed to prevent a dereference in init_user_queue and is no longer appropriate during CRIU restoration. In short, this is a targeted memory-safety fix to avoid NULL pointer dereferences in CRIU restore flows involving shared MES buffers. It is a real vulnerability fix (memory safety) rather than a pure refactor or test change.

The commit adds an RBAC translation for alert rule resources under rules.alerting.grafana.app. It introduces a per-object direct-scope for alert rules using the resource name alert.rules (prefix) and the UID, instead of a potential folders:uid:<uid> path. This, combined with folder inheritance (folderSupport: true), prevents a collision between rule UIDs and folder UIDs from causing an authorization bypass. Prior behavior could map per-object scope to a folder UID, potentially allowing access to alert rule resources when a user had folder-scoped permissions for a folder whose UID collided with a rule UID. The change is a genuine security fix to RBAC behavior for alert rules, not merely a dependency bump or a test addition. The changes are focused on authorization routing for alert rule resources (alertrules, recordingrules, rulesequences) and their mapping to alert.rules:* actions, with a dedicated per-object scope prefix to avoid collisions with folders.

The commit adds a cap on the number of buffered objects in the unified storage ingester. Previously, if a new object arrived and the in-memory buffer was at its max capacity but the object wasn't already buffered, the code could create a new buffer entry, potentially allowing unbounded memory growth and opening a Denial of Service via resource exhaustion. The fix enforces a hard cap on buffered objects and drops incoming events when the buffer is full, recording the number of dropped events via metrics. Tests were added to verify the cap behavior and that existing buffered objects can still accumulate where appropriate.

The commit adds a server-side check that restricts search facets to only facet-capable fields. Specifically, convertHttpSearchRequestToResourceSearchRequest now rejects facet requests for any field other than the predefined facet field (SEARCH_FIELD_TAGS), returning a BadRequest when an unsupported field is used. The Bleve-backed search path also maps facet request names to actual index fields and rejects unknown fields with a BadRequest, preventing facet queries on internal or non-facet fields. This mitigates information disclosure risks where an attacker could use the search API to enumerate or infer internal field mappings (e.g., labels.region, folder, etc.) by requesting facets on non-public fields. The fix thus closes a potential exposure surface by ensuring only known facet-capable fields (tags) can be used in faceting, and by validating facets against mapped, supported fields before constructing the Bleve query.

The commit adds validation for the X-Forwarded-Prefix header in the API dashboard. Previously, a crafted value in X-Forwarded-Prefix could influence request routing or origin behavior via header/URL manipulation. The fix parses the header as a URL and rejects obviously absolute URLs (with a Host or Scheme), resetting the prefix to an empty value instead of trusting the client-provided value. This mitigates a potential header/URL injection attack that could cause misrouting or cross-origin concerns. The change is a concrete security fix (not just a dependency bump or refactor).

The commit adds safeguards for path normalization and X-Forwarded-Prefix handling in the dashboard and routing path. Specifically: - It validates X-Forwarded-Prefix, rejecting values that parse as an absolute URL (having a Host or Scheme). - It introduces path normalization checks in the replace-path-regex middleware: after normalizing the URL path, it rejects the request if the normalized path differs from the original path, preventing potential path-traversal or path-assembly bypass via unusual path constructs. These changes mitigate header-based attacks and path-traversal weaknesses that could occur when untrusted input influences URL paths processed by Traefik or downstream middlewares. Prior to this patch, crafted paths containing traversal sequences (e.g., ..) or manipulated URL joins could be forwarded to backends in a different form than originally requested, potentially bypassing access controls or exposing unintended resources.

The commit adds a wrapper around several Annotation-related API handlers to override 4xx error responses, ensuring proper access-control behavior. Specifically, it enforces 403 Forbidden for requests lacking the necessary organization-scoped permissions (e.g., annotations:read with organization scope) instead of leaking information via generic 4xx responses. This prevents unauthorized access or information leakage through ambiguous 4xx errors when accessing custom annotation routes.

The commit introduces a per-target override for max_scrape_size via the __max_scrape_size__ label in the Prometheus scraping flow. It parses the label value using flagutil.ParseBytes and, if positive, applies it to that specific scrape target instead of the global max_scrape_size. This serves as a configurational control to mitigate resource exhaustion by limiting per-target scrape payloads, addressing a potential DoS/memory exhaustion risk. However, the change does not enforce an upper bound on the per-target value, and an attacker who can influence label values could set a very large size, potentially causing memory pressure or DoS. The tests also illustrate that invalid values are ignored, and valid values override the target's limit.

The commit adds classic provisioning shim kinds (classic-file-provisioning, classic-api-provisioning, classic-converted-prometheus) and introduces an IsClassic() helper. It changes manager-property handling so that resources originating from legacy provisioning paths are reported as managed even when there is no stable identity. This addresses an authorization/immutability gap where classic-shim resources could be treated as unmanaged due to missing or unstable identity annotations, potentially allowing provisioning/update/delete operations to bypass intended protections. The fix also updates several provisioning/export/migrate paths to honor the managed flag for classic kinds. Overall, it is a real vulnerability fix addressing identity-immutability bypass for legacy resources, not a mere dependency bump.

The patch fixes a race between the data-write commit and the emission of the corresponding event in the unified storage backend. Prior to the fix, if a client canceled after the data write had been durably committed but before the event was emitted, the event could fail to be emitted, leaving the data write visible in the data store but missing an associated event (audit/integrity issue). The fix detaches the data-write commit from the client cancellation by invoking the data-write path (ExecWithRV) with a detached context (context.WithoutCancel(ctx)) so the data is committed even if the client cancels. After the data write commits, it continues to emit the event but uses a bounded persist deadline (10 seconds) to avoid indefinite blocking, ensuring the event emission is attempted and either succeeds or is recorded as an EventEmitFailure. The patch also introduces configurable per-resource lease TTL and auto-renew, and adds metrics for event emission failures, plus a unit test that simulates cancellation after data save to prove the event still persists. Overall, this is a real vulnerability fix addressing a race/integrity bug rather than a mere cleanup or dependency bump.

Summary of the observed security relevance in the commit: The DRM fixes include explicit memory-safety improvements, notably guards against NULL pointer dereferences in DMA fence handling. Specifically: 1) In dma_fence_dedup_array, a guard was added to return early when num_fences is 0, preventing an unsafe operation on an empty array. 2) In dma_fence_driver_name and dma_fence_timeline_name, the code now checks that the ops pointer is non-NULL before dereferencing it, avoiding a potential NULL pointer dereference when interacting with fences whose ops may be missing or uninitialized. These changes mitigate a class of memory-safety bugs that could cause kernel panics/OOPS or information disclosure via invalid dereferences in the graphics/subsystem fences path. The commit also contains broader driver cleanup and stability fixes across multiple DRM drivers, but the explicit vulnerability mitigation centers on these NULL-dereference guards in DMA fence code.

The patch changes how JWTs without a vm_access claim are handled by the vmauth request path. Previously, if a token had no vm_access claim and there was no DefaultVMAccessClaim configured, the request was rejected with 401 Unauthorized immediately. The change makes the JWT handling align with other authentication paths by deferring to the unauthorized_user flow in this case, allowing requests to be handled by the unauthorized_user backend if configured. This corrects an inconsistent authorization flow and reduces the risk of misrouted or prematurely rejected requests due to missing vm_access claims. However, in misconfigured environments, forwarding unauthenticated requests to unauthorized_user could expose backends that rely on additional claim checks. Overall, this is a security-relevant fix to access-control logic rather than a benign code cleanup.

The commit fixes an input validation bug in cacheHandlers keys. Previously the validation used /[a-z-]/ which only required at least one lowercase letter or hyphen anywhere in the key, so keys containing digits, underscores, dots, or other characters could slip through (e.g., 'abc123', 'abc_def', 'handler!'). The patch anchors the regex with /^[a-z-]+$/, ensuring the entire key consists only of lowercase letters and hyphens. This reduces misconfiguration risk and potential edge-case behavior stemming from malformed handler names.

This commit alters the segment explorer trie to use null-prototype objects for its children maps. The previous implementation used plain {} for child nodes, which can collide with Object.prototype properties (e.g., 'constructor', 'toString') when segment names are user-controlled. This change prevents those collisions by ensuring the internal maps do not inherit from Object.prototype, reducing the risk of prototype pollution or logic errors in the segment explorer when handling user-supplied segment names.

Summary: The commit introduces a hard limit on metric metadata fields (Help, MetricFamilyName, Unit) to 64 KiB (MaxUint16). It adds IsMetricMetadataExceeding and IsPrometheusMetadataExceeding checks and filters oversized entries before marshaling/inserting metadata, mitigating potential DoS/memory issues from excessively large metric metadata. The changes also update marshaling to fail gracefully when a field exceeds the limit and log warnings. Tests updated to cover oversized inputs. This is a genuine robustness/security fix, not merely a dependency bump or test-only change.

The health check subresource did not propagate the apiserver request context to the health-check path. It used req.Context() to derive the tracing span and health context, which lacks apiserver-request-scoped values such as the NamespaceValue(ctx). As a result, tenant isolation could be violated: health checks for a datasource could execute under an empty or incorrect namespace, potentially leaking or mixing tenant data across requests. The patch propagates the outer apiserver context (ctx) into the health check path, ensuring the namespace is preserved for proper multi-tenant isolation.

The commit adds a cascade cleanup for legacy team_member rows when deleting a team via unified storage. Prior to this change, deleting a team would remove the team row but could leave orphaned legacy membership records in the team_member table. Those leftover rows could allow users to retain access privileges associated with the deleted team, effectively enabling privilege retention/escalation. The patch introduces a DeleteTeamMembersByTeam SQL path and wires it into the DeleteTeam flow to ensure historical membership records are removed alongside the team, preventing privilege retention via orphaned entries.

Summary: The commit replaces the previous gzip writer flow for WatchList initial events with a perFlushGzipWriter that pulls a gzip.Writer from a pool, resets it for the current ResponseWriter, and releases it back to the pool after the initial events. The change also adds tests around perFlushGzipWriter behavior and explicitly releases the gzip.Writer back to the pool after initial events. Security impact: This addresses a potential information disclosure / cross-request data leakage risk where a gzip.Writer pool could retain state (buffers, headers, or compressed data) across requests if writers are reused without proper reset and release. By ensuring the writer is Reset with the current ResponseWriter and returned to the pool promptly after initial events, subsequent requests do not observe leftover gzip state from prior responses. Affected code path is in apiserver/pkg/endpoints/handlers/watch.go where gzip writers were previously tied more directly to response objects and could leak state between streaming/watch responses.