Alerts

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.

This commit implements Declarative Validation (DV) for authorization review API paths (SubjectAccessReview, SelfSubjectAccessReview, LocalSubjectAccessReview). It introduces a scheme-aware DV flow by wiring REST storage with a runtime.Scheme, and by composing handwritten validation with declarative validation in the creation path (ValidateSubjectAccessReviewCreate, ValidateSelfSubjectAccessReviewCreate, ValidateLocalSubjectAccessReviewCreate). The storage REST constructors were updated to accept a scheme, and the authorization rest storages now invoke DV via rest.DeclarativeValidation. The net effect is tighter, scheme-backed validation for authorization requests, reducing the risk of bypassing input validation or misvalidating requests. This appears to be a real security fix rather than a mere dependency bump or test addition.

The commit enhances input validation during object creation by validating the object metadata (metadata.name) through a path-segment validator (validatePathSegment) via genericvalidation.ValidateObjectMetaAccessor. This change aims to prevent malformed or adversarial resource names from slipping through creation validation, addressing potential security or stability issues such as path traversal or invalid resource handling. It also preserves DeclarativeValidation integration. The update also slightly adjusts the validation ordering to ensure object metadata validation runs after initial strategy validation has passed. While Kubernetes names are generally constrained by DNS labeling rules, this patch adds an explicit name/path validation layer at creation time, which tightens security against edge-case or future-name-policy violations.

The commit adds a WebhookRoundTripLoadBalancing feature and a resolvingRoundTripper so admission webhook requests use the resolved endpoint IPs rather than reusing cached connections by service DNS. This mitigates a race between IP changes and cached connections that could cause requests to be routed to stale or unintended endpoints, reducing misrouting risk. It changes the webhook client to either dial the resolved endpoint each request or route via a custom RoundTripper that updates the request to the resolved endpoint, thereby improving routing correctness for webhooks.

This commit wires declarative validation into handwritten validation for SubjectAccessReview and related authorization reviews, updating REST handlers to pass scheme/context and composing handwritten validation with declarative validation. It hardens input validation for authorization reviews and reduces the risk of invalid inputs slipping through, thereby reducing potential authorization misconfigurations or bypasses.

The commit changes the Migrate() behavior so that the destination file permissions are derived from the source file permissions, masked to remove executable bits (sourceInfo.Mode().Perm() & 0666). Previously, the destination file was always created with mode 0666, regardless of the source, which made the migrated file world-writable. A world-writable config file can be tampered with by other users on the same host, potentially allowing an attacker to inject malicious configuration content and, in some scenarios, lead to privilege escalation when a process reads and uses that config. The new behavior reduces privilege risk by aligning the destination permissions with the source (and explicitly removing executable bits) and by ensuring permissions are controlled by the source, not a fixed permissive value. Tests were added to assert that destination permissions mirror source permissions (subject to the 0666 mask).

Summary: The commit implements a hardening to prevent server-only modules (notably the server-side implementation of unstable_rethrow) from being bundled into client-browser builds. Prior to this change, the client browser bundle could include server-oriented code paths (e.g., unstable_rethrow.server.ts and related server rendering checks), which risked information disclosure by exposing server internals to the client. The fix removes the server-specific module from the client bundle, introduces a browser-specific variant (unstable-rethrow.browser) and maps the client context to that variant, and deletes the server-only file. This reduces the attack surface by ensuring server internals are not present in client bundles. The triage notes align with this being a boundary/infosec hardening rather than a direct vulnerability in application logic, but it guards against information disclosure via bundled server code. What changed (high-level): - Deleted unstable-rethrow.server.ts and updated unstable-rethrow.ts to document that the browser bundle uses a browser-safe version and that the server logic should not reside in client bundles. - Updated import resolution/mapping to alias to a browser variant for client contexts (e.g., unstable-rethrow.browser) via get_next_client_resolved_map and other import-map style changes. - Adjusted tests to ensure server modules are not bundled into browser chunks. Security impact: By preventing server-only code from leaking into the client bundle, the risk of exposing server internals (error handling logic, server-side checks, dynamic rendering details, etc.) is reduced. This is categorized as Information disclosure related to server internals being surfaced to the client. The fix improves isolation between client and server code paths and reduces potential reconnaissance for attackers. Affected area: The Next.js client-side build and module resolution for unstable_rethrow and related server-side error handling, particularly around how server checks are or are not included in client bundles.

The commit fixes an authorization bug in Grafana's RBAC translation by aligning org.users:* actions with the global users:* actions for both read and write scopes. Previously, org-level user-management permissions (org.users:read, org.users:write, org.users:remove) were not consistently reflected in the legacy permissions (users:id:*), which could cause org-level grants not to propagate correctly and lead to misconfigurations or privilege inconsistencies. The patch updates isUserRBACAction and userScopeKind to treat org.users:* actions as org-scoped within the users kind and extends the translation table to include org.users:read, org.users:write, and org.users:remove. This ensures proper reflection of org-level grants back to legacy permissions, improving authorization correctness and reducing potential privilege misconfigurations.

The commit hardens multitenancy isolation in AccessControl UID->internal-ID resolution by: (1) caching UID->internal-ID mappings per tenant namespace, (2) using a per-key singleflight to collapse concurrent resolutions, (3) detaching the fetch from the caller context with a bounded timeout, and (4) avoiding caching of zero IDs. Previously, the resolution cache and singleflight key could be based on OrgID, which is not 1:1 with a namespace. Since multiple namespaces can map to the same OrgID (e.g., stacks-N namespaces mapping to OrgID 1), a shared cache/singleflight could collide resolutions across tenants, leading to information disclosure or privilege isolation risks during permission merges. The patch also ensures that failed resolutions and zero IDs are not cached, and that cancellation of one caller does not fail others sharing the flight.

The patch fixes an inverted comparison in ipmi_bmc_gone(): the loop originally skipped the matching interface and instead acted on the first device whose ipmi_ifnum was not equal to iface. This could cause the wrong ACPI IPMI interface to be torn down when an interface goes away, potentially leaving the management path in an inconsistent or misconfigured state. While primarily a correctness bug, mishandling of IPMI interfaces can have security implications in terms of access/controls over IPMI interfaces, hence a potential privilege escalation or authentication bypass path under specific conditions.

The commit adds security-oriented hardening for Grafana's HTTP client used by the settings service. It introduces an IdleConnTimeout to cap how long idle keep-alive connections are pooled, and it forces HTTP/1.1 when HTTP/2 is disabled by setting NextProtos to http/1.1. These changes reduce the risk of resource exhaustion and protocol downgrade issues caused by idle connections or improper ALPN negotiation. Tests were added to exercise protocol negotiation behavior, reinforcing the mitigation.

The commit mitigates a memory-safety vulnerability in the page isolation scanner. Previously, page_is_unmovable() could inspect compound pages by using a folio pointer without holding a folio reference or any lock. The folio could be freed, split, or reused while the scanner was still examining it, leading to reads of potentially invalid folio metadata and incorrect calculations. In particular, the original code derived the hstate from folio_size() and computed the scan step from folio_nr_pages() and folio_page_idx(), which assume the folio remains a valid folio head. If the folio changes concurrently, the scanner can read inconsistent metadata and compute a wrong step, and folio_nr_pages() could underflow when the tail/page counts change. There were also risks for non-Hugetlb compound pages where folio_test_lru() could observe a stale folio pointer and trigger VM_BUG_ON_PGFLAGS(). The fix reads the compound order once via compound_order(&folio->page), rejects obviously bogus orders, and derives the hstate and scan step from that order instead of querying folio size information again. It also uses PageLRU(page) (safe for the page being scanned) instead of folio_test_lru() on a potentially stale folio pointer. Additionally, unknown HugeTLB hstates are treated as unmovable so the scanner does not attempt to skip over unstable HugeTLB folios. Overall, this is a defensive memory-safety fix intended to prevent use-after-free/invalid-access scenarios during page isolation scanning.

The commit fixes an information disclosure vulnerability related to reading resource history at a deletion resource version (RV). Prior behavior could expose the last pre-delete state of a resource when reading at the RV corresponding to a deletion event. The patch adds handling to treat a deletion event as not found, returning a NotFound error instead of leaking resource data, and it updates tests to cover edge cases around reading at exact RV boundaries (including deletion). This tightens access semantics for historical reads.

This commit adds a tlsErrorSkipLogger to suppress noisy TLS handshake errors in logs originating from health-check probes. The intent is to mitigate log flooding and potential resource exhaustion (DoS) caused by repeated TLS handshake failures, which can occur when health probes repeatedly connect to the TLS port and fail the handshake. The filter inspects log messages and drops those containing "TLS handshake error" when accompanied by EOF or "connection reset by peer". This is a logging-level mitigation rather than a fix to TLS negotiation itself. It reduces log spam and possible DoS caused by log processing, but could obscure legitimate TLS handshake problems if they produce similar log lines. In short, it’s a defensive change to reduce log-based DoS risk without altering TLS behavior.

Summary: The commit fixes incorrect tenant filtering when long tenant regular expressions are used, which could lead to information disclosure across tenants due to improper tenant isolation. The root cause was that tenant filters were converted to a human-readable string via TagFilter.String(), and for long regexes this representation could be truncated to an ellipsis (...). Such truncated filter representations could be interpreted incorrectly during evaluation, causing tenants to be matched inaccurately and potentially exposing data to unintended tenants. The fix stops relying on the truncated, human-readable form and builds the filter terms using explicit operator handling (equality, inequality, regex, and negative variants) so the full semantics of the filter are preserved regardless of length. It also extends parsing logic (ParseFromMetricExpr) to better preserve filter semantics when converting from metric expressions. Impact: If unpatched, a long tenant regex could cause incorrect tenant matching, exposing data to tenants that should not have access. The patch improves tenant isolation and access control by ensuring long filters are interpreted correctly. This aligns with information-disclosure prevention in multi-tenant contexts.

The commit introduces a centralized helper isItemManagedByRepository and replaces ad-hoc checks (e.g., folder.managedBy, AnnoKeyManagerKind annotations) across provisioning-related UI and API paths with this helper. This rework fixes potential authorization/privacy gaps where resources could be misclassified as repository-managed, leading to incorrect visibility or provisioning permissions. By consolidating the authorization logic for determining whether a resource (folder/dashboard) is managed by the repository, the patch reduces the risk of bypasses in provisioning flows and access control decisions.

The commit implements a feature flag (frontendService.reducedBootDataAPI) to control whether the frontend receives the full frontend settings. Previously, Grafana shipped full frontend settings to the frontend by default (via window.grafanaBootData.settings), which could leak sensitive configuration and build/license information. The fix moves the full settings behind a feature flag and defaults to sending reduced boot data, mitigating information disclosure. The changebase also wires the flag through the request/config path and adjusts the HTML boot data accordingly.