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.

The commit implements multiple concurrency-related fixes in the libnvdimm/BTT area that address a race condition and related resource handling issues: - Rework of lane management from a per-CPU lock structure to a per-lane mutex array. This changes how lanes are allocated/released and ensures serialized access, reducing data races when multiple CPUs/contexts access the same BTT region. - Removal of per-CPU lane data paths and replacement with a simple mutex per lane, with explicit locking around acquire/release paths. This mitigates potential race conditions where per-CPU lane state could be accessed concurrently without proper synchronization. - Improved error-path cleanup in BTT initialization (freeing arena-related structures on failure) to prevent use-after-free or double-free scenarios during initialization/error handling. - Escalation of a resource-conflict log level from dev_dbg to dev_err to surface concurrency-related failures more clearly. - Minor adjustments to sysfs attribute emission (cpumask show) to use sysfs_emit, reducing risk of buffer misuse in sysfs callbacks. Overall, these changes tighten synchronization around BTT lane usage and resource management, addressing classic race-condition class vulnerabilities that could lead to memory corruption, use-after-free, or invalid state during concurrent IO/storage metadata operations.

The patch converts the LPG driver’s per-channel data to a flexible array member inside the main lpg struct and allocates the entire structure (including channels) in a single allocation. This replaces a separate allocation for the channels pointer, reducing the risk of memory misallocation or mismatches between reported channels and allocated space, which could lead to memory safety issues (out-of-bounds access or memory corruption) under certain conditions (e.g., larger num_channels). It also adds __counted_by annotations for runtime analysis.

The commit adds a configurable maximum number of scopes that can be attached to a single annotation and enforces this limit during creation and updates. It also validates the configuration to reject negative values and includes tests for both runtime behavior and settings loading. Previously, there was no upper bound on the number of scopes, which could allow an attacker to attach an excessive number of scopes to an annotation, potentially expanding access rights and enabling privilege escalation via scope manipulation. This fix introduces: (1) a default maxScopeCount (default 5) with 0 meaning no scopes allowed, (2) validation in the Kubernetes-backed adapter Create/Update paths, (3) plumbing to load the setting from configuration with non-negative enforcement, and (4) tests to verify the behavior. This is a targeted security improvement to prevent overly broad scope attachments in annotations and reduce escalation risk.

The commit adds a HasPendingDeleteLabel check and wiring to skip embedding resources that are labeled as pending-delete across the backfill and reconciler paths in Grafana's Unified Storage Vector. It also exports a PendingDelete feature and introduces tests to verify that resources marked with the pending-delete label are not embedded/published. This directly targets potential information disclosure where dashboards or resources scheduled for deletion could be embedded and exposed in search results or backfill output. The change is a real vulnerability fix (not merely a dependency bump or cleanup) and addresses a narrow, security-relevant data exposure path.

The commit adds an admission-time guard that prevents provisioning a GitHub Repository from referencing a Connection that has webhook.disabled=true unless the Repository itself also disables webhooks. Prior to this fix, it was possible to reference a webhook-disabled GitHub connection without enforcing the repository-level webhook setting, potentially leaving webhooks misconfigured or unprotected. The validator now enforces: if the referenced connection has webhook.disabled, then repository.spec.webhook.disabled must be true. This is an access-control/configuration-validation safeguard intended to preserve consistent security posture during provisioning.

The commit adds a fine-grained, read-only Administration permission for GitHub tokens used by the provisioning flow. Previously, tokens with Administration rights could be used to perform privileged actions (e.g., modifying repository settings or branch protections) during provisioning. By explicitly adding an Administration: Read-only permission for GitHub tokens (and gating its use to only the GitHub provider), the fix reduces the risk of privilege escalation when Grafana provisions dashboards by validating and/or modifying repository content. The change is complemented by UI/test updates to reflect and enforce the new permission model. The flamegraph change and some UI tweaks are non-security-impacting, but the primary security improvement is the token permission hardening.

This commit fixes a real prototype-pollution vulnerability in React Flight SSR serialization. Previously, the serialization path used a regular in-place property copy (resolved[key] = value) while walking the model. If an attacker supplied data containing an own __proto__ key, this could cause prototype pollution via the prototype chain of the object being built. The patch moves to a pure-JS recursive resolveModel step and handles __proto__ specially by creating an own property on the target object via Object.defineProperty, thereby preventing prototype mutation. It also avoids the C++ boundary overhead by not using JSON.stringify’s replacer for each key. Vulnerability type: Prototype Pollution Affected surface: React Flight SSR serialization path (server-to-client data rendering) Impact: If an attacker can influence the serialized data to include a crafted __proto__ payload, they could pollute the prototype of the resulting object, enabling downstream prototype pollution effects in client code that consumes the serialized data.

The commit implements a security fix for information disclosure in React Flight’s debug data handling. Previously, when a Flight chunk transitioned to the ERRORED state, in-flight debug information could remain in memory and be leaked if an error occurred after the consumer end time cutoff. The patch adds a pruning step (pruneDebugInfoAfterError) that truncates the chunk's _debugInfo array to remove entries with time stamps beyond the relative end time. This pruning is invoked during error handling (in DEV) and ensures that internal stack traces or debug frames aren’t exposed after an error cutoff. Additionally, the code adjusts the handling of _debugEndTime (null | number) and updates related logic to consistently apply the cutoff. The change is complemented by a test that asserts the filtering behavior when the Flight stream errors.

The patch adds a NULL guard in wm_adsp.c inside wm_adsp_control_remove to prevent a NULL dereference of the ctl structure. Prior to this fix, if cs_ctl->priv was NULL, the code would attempt to access ctl->work, potentially crashing the kernel (memory safety issue / NULL dereference). The change is a defensive hardening that reduces kernel crashes in certain code paths when removing a WM_ADSP coefficient control.

The commit fixes TLS option conflict resolution for routers on the same entrypoint, specifically handling routers with no host rules. Previously, a router without a domain could be treated as part of the SNI-based matching in a way that could lead to applying non-default TLS options or inconsistent conflict handling when multiple routers shared an entrypoint. The changes adjust the conflict detection and resolution so that routers without hosts are properly considered in conflicts, and when conflicts are detected, a dedicated router copy is emitted with default TLS options and a stable naming scheme. The log messages and tests were updated to reflect the new behavior. This mitigates edge-case TLS misconfiguration (e.g., weaker TLS options being used inadvertently) in multi-router scenarios. Overall, this is a TLS configuration edge-case fix with MEDIUM confidence.

This commit hardens alerting UI authorization by migrating from ad-hoc permission checks and an Authorize wrapper to centralized ability hooks. It adjusts the visibility and availability of actions in the alerting UI (Silence, Manage silences, See alert rule, See source) to be governed by centralized abilities (RuleAction.View, SilenceAction.Create/Update, ContactPoint.View, etc.). This reduces the risk of UI-based privilege bypass where UI controls could be shown to users who shouldn't have them due to inconsistent or scattered permission checks. It appears to be a security-relevant refactor toward consistent auth checks, rather than a mere dependency bump; however backend permissions remain the authority for actual actions, so server-side checks are still essential. Overall this is a legitimate security hardening/fix rather than a pure cleanup.

The commit changes how resource permission subjects are looked up for RBAC resource permissions. Previously, the code used a service identity to resolve subject details (users/teams), which could enable impersonation or leakage of subject identities during permission resolution. The fix switches to using the caller's user context to fetch user and team details, aligning permission resolution with the actual caller identity and reducing the risk of authorization bypass when querying RBAC data.

Summary: The commit implements a security-aware fix for dynamic SQL/DDL generation in the vector store by validating resource names used to create per-resource partitions and by providing idempotent backfill job creation. It adds EnsureResourcePartition and CreateBackfillJob to the VectorBackend, and guards the DDL against unsafe resource names via a sanitizeIdentifier check. This addresses a potential SQL Injection surface where resource names are interpolated directly into DDL (e.g., embedding_<resource> partition names) and used in partition creation statements. The patch includes tests that reject unsafe resource inputs and tests that ensure the resource partition is created safely and idempotently. It also introduces an ON CONFLICT DO NOTHING path for backfill job creation to prevent duplicate rows.

The commit adds proper reference counting for DRM property blobs (degamma_lut, gamma_lut, ctm, lut_3d) in intel_plane_state. Specifically, it calls drm_property_blob_get when duplicating state and drm_property_blob_put when destroying or clearing hardware state. Without these gains in reference counting, there is a risk of use-after-free or double-free of property blobs across duplicate, destroy, and clear_hw_state paths, leading to memory safety vulnerabilities in the i915 driver. The fix therefore addresses a potential memory safety vulnerability (use-after-free/double-free) related to DRM property blobs in the Intel i915 backend.

The commit fixes the IAM datasource permission mapping to Kubernetes-style scopes, explicitly handling wildcards and missing datasource types when converting legacy scopes to the Kubernetes form. This addresses potential authorization gaps where incorrect or inconsistent mapping could grant or deny access in unintended ways, particularly for wildcard scopes (datasources:*) and missing datasource types. The change reduces the risk of privilege escalation or improper access control arising from misinterpreted legacy IAM scopes.

The commit migrates silences-related UI to centralized ability hooks and replaces ad-hoc permission checks that relied on context_srv with a dedicated ability system (useSilenceAbility). It gates actions (e.g., creating silences) behind granted checks and disables or hides UI elements accordingly. This is an authorization/access-control hardening intended to reduce information exposure and improper actions. However, the enforcement semantics depend on backend authorization as well; if server-side checks were not updated to mirror the centralized UI permissions, an attacker could bypass UI restrictions via API calls. The change primarily covers frontend access control and may not fully mitigate backend-only abuse without accompanying server-side checks.

The change tightens the scope of the RuleSequence informer used by alerting rules. Previously, the informer could watch all namespaces (all-namespaces), which in cloud deployments could lead to information exposure across tenants by accessing alerting rule data from multiple namespaces. The fix fences the watcher to a single stack namespace in cloud environments (and uses all-namespaces only for on-prem). This reduces cross-namespace information disclosure risk and tenant isolation violations in cloud setups.

This commit implements CI security hardening by replacing broad automation tokens with a dedicated GitHub App (grafana-pr-automation) and context-sensitive permission sets for actions such as tagging, PR migration, and security-mirror writes. Previously, CI workflows could rely on tokens with broader permissions (e.g., delivery bot or default GITHUB_TOKEN) to perform privileged tasks like creating annotated tags or writing to repos, which could be exploited if those tokens were leaked or misconfigured. The changes: - Switch token source from a generic/app with wide permissions to a GitHub App with restricted permission_set per action context (writer-release, writer-main, pr-writer-*, etc.). - Scope token usage to specific repositories (also enabling a dedicated security-mirror-writer for the security mirror repo). - Use app tokens for privileged steps (e.g., annotated tag creation) instead of the default GITHUB_TOKEN. - Remove some heavy release steps (publish-dockerhub, meticulous tests) that could broaden the blast radius of token usage during releases. The net effect is a reduction in privilege and blast radius for CI automation, mitigating a potential access-control/privilege-escalation risk in release workflows where leakage or misuse of automation tokens could lead to unauthorized tagging, PR migrations, or repository edits. While the fix is applied in CI configuration rather than in Grafana core code, it addresses a real security concern around CI token permissions and automated release artifacts.

The commit addresses TLS options resolution for entry-point based TLS configuration. Previously, a router that relies on entry-point TLS could publish a configuration where TLS options were not resolved, potentially allowing an attacker to negotiate a TLS version or configuration that did not reflect the operator's intended security posture. The patch ensures TLS options are resolved and applied even when the router derives its TLS config from the entry point, and includes a regression test (TestWithEntryPointTLSConfig) and a test asserting resolution in published configurations (TestEntryPointTLSResolvedOptions). This constitutes a TLS configuration correctness fix with security implications (misconfiguration could weaken TLS).

The commit contains multiple MPTCP fixes. The security-relevant portion is a race/TOCTOU hazard in the MPTCP read path (read_sock) where data/descriptor state could become inconsistent under concurrent reads, potentially allowing memory-safety issues (e.g., use-after-free or invalid access). Patch 9 specifically adds a check in the read loop: after consuming a received skb, if the read descriptor count (desc->count) is zero, the loop breaks, ensuring the code does not continue processing with an exhausted descriptor. This helps prevent a window where the kernel could operate on stale or freed data while another thread/process is draining data. The rest of the changes address related TOCTOU/race vectors and memory safety (e.g., rcv_wnd computation in DSS, cleared flags, and safer subflow signaling), collectively reducing security risk. Overall, this is a genuine vulnerability fix for a race condition in the MPTCP read path with MEDIUM confidence.

The patch mitigates a potential protocol misuse in MPTCP ADD_ADDR handling. Previously, ADD_ADDR (and its echo) could be prepared for transmission on a packet that was not a pure TCP ACK and, in some cases, would be retained in the options list while other suboptions (e.g., DSS) could be in flux, leading to mismatches in ADD_ADDR signaling and HMAC/dss handling. The change makes ADD_ADDR only eligible when the preceding ACK is a pure ACK and ensures other suboptions are dropped when ADD_ADDR is added, avoiding sending ADD_ADDR with stale or conflicting state. This reduces the risk of information leakage or spoofed/incorrect protocol state due to sending ADD_ADDR echoes in non-pure-ACK contexts. It is primarily a correctness/robustness fix with security relevance due to protocol misuse prevention.

The commit improves RBAC/datasource permission handling by mapping legacy datasource actions, including granular permissions (datasources.permissions:read and datasources.permissions:write), to their corresponding Kubernetes RBAC actions. It introduces legacyActionToK8s and expands LegacyDatasourceAction to handle both plain datasource verbs and the nested permissions verbs. This tightens authorization semantics and reduces the risk of mis-mapped permissions that could lead to unintended access (privilege escalation or information disclosure) through incorrect interpretation of datasource-related actions by the RBAC layer.

The commit fixes an information disclosure / insecure error handling path in plugin settings retrieval. Previously, requesting plugin settings for a plugin that is not installed could surface an error (e.g., Unknown Plugin) including error details or signaling a 404 condition to the UI, potentially enabling plugin-availability enumeration or unrelated error leakage. The fix changes usePluginSettings to swallow 404 errors by returning undefined instead of surfacing an error, effectively treating a missing plugin as a normal absence. Additional small hardening changes include guarding getAppPluginEnabled with an empty-pluginId check and correcting a log message typo. Collectively, these changes reduce information leakage about which plugins are installed and improve error handling for missing plugins.

The commit refactors authentication/authorization checks for Grafana alerting notification policies from scattered, separate permission lists (READ/READ_EXTERNAL and MODIFY) to centralized ability hooks. It introduces new ability hooks (useNotificationPolicyAbility, useTimeIntervalAbility, useAlertGroupAbility, etc.) and unifies route gating to rely on explicit abilities rather than legacy permission lists. This reduces the risk of authorization bypass due to inconsistent RBAC checks across routes and UI components. It is a real security fix addressing access control consistency for notification policies in the Alerting feature.

Root cause: A race condition (TOCTOU) in subPath directory creation for Kubernetes subPath volumes. The patch changes error handling to tolerate an already-existing subPath directory (ignoring ErrExist) and avoids leaking host filesystem details in user-facing errors. This reduces the window where a malicious actor with access to host paths could influence path resolution during mounting and potentially cause a subPath to reference an unintended host location. The exact code changes indicate an intent to make subPath directory creation idempotent when the directory already exists, rather than failing and exposing host FS details. Additionally, error wrapping was adjusted in subpath implementations to use proper error wrapping (%w) rather than exposing raw strings. Overall, this is a real TOCTOU mitigation in subPath directory creation for container mounts, addressing security concerns around host path leakage and path resolution races.

This commit hardens kubeadm's dry-run handling of CA certificate materials during the init phase. Key changes include: (1) creating the destination dry-run directory with restrictive permissions (0700) before copying CA artifacts, and (2) copying the actual CA certificate and key from their source paths (rather than a fixed constant path) into the dry-run location. Prior behavior could leave CA material in a dry-run directory with permissive permissions or copy from a potentially incorrect fixed path, increasing the risk of information disclosure or improper access control. The added test verifies that the CA certs/keys are indeed copied into the dry-run directory. Overall, this appears to be a genuine security hardening fix around handling of sensitive CA material in dry-run mode.

The commit fixes a frontend authorization mismatch between alerting instance creation and silence creation permissions. Previously the UI gated the silence-creation action based solely on the alertingInstanceCreate permission. The backend gate can accept either action (alertingInstanceCreate or alertingSilencesCreate) for creating silences, but the UI did not consistently reflect that. The patch updates the UI to recognize both permission paths and to surface or suppress the silence-creation action accordingly, reducing the risk of authorization leakage or misrepresentation in the UI. This is an actual fix to access-control alignment between frontend and backend, not a pure cleanup or dependency bump.

The commit implements a safeguard to prevent main-thread stalls and potential denial-of-service via extremely large debug strings in React Flight server-client communication. Previously, very large debug strings (e.g., multi-megabyte values) could be reconstructed and processed on the client when replaying logs or debug info, potentially blocking the main thread and exhausting CPU time. The fix adds a threshold (1,000,000 characters) and replaces oversized strings with a placeholder message indicating omission. This reduces resource usage during server-to-client debug data transmission and log replay. It also normalizes long strings in performance tracking to avoid heavy processing.

The commit fixes a cryptographic padding handling issue in WireGuard's packet encryption path. Previously, the code could zero-padding and include the trailer (padding) in the skb in a way that could be bypassed if skb data allocation (reallocation) occurred before or during header expansion. This could result in padding not being properly zeroed or not being included in the encrypted trailer when reallocation happened, potentially leaking uninitialized data or compromising padding integrity. The fix changes the order of operations to append the trailer after expanding the head and to initialize padding at the end of the process, ensuring the padding zeros are preserved in all code paths and improving data integrity in the cryptographic padding process.

The commit adds a guard in arch/x86/kvm/svm/sev.c: setup_vmgexit_scratch to WARN_ON_ONCE when min_len is zero and to jump to the error path. This prevents configuring the vMGEXIT scratch area with a zero-length requirement. Previously, a zero min_len could lead to subsequent memory handling with an invalid scratch region, creating a potential memory-safety regression if the code path trusted a non-zero length. The patch ensures non-zero length for the scratch area and surfaces a warning rather than proceeding with a potentially unsafe setup. This is a defensive fix to guard against future bugs and misconfiguration in KVM SEV scratch handling.

The commit adds a guard to ignore MMIO requests with length 0 in the KVM SEV MMIO exit path. Prior to the patch, a length of 0 could lead to unsafe length-based calculations (e.g., computing end pointers or scratch area setup) that might underflow and cause memory corruption or other memory-safety issues. The patch returns early when len == 0, and continues using len for subsequent scratch setup and MMIO handling only when len is non-zero. This is a defensive fix for a potential buffer underflow in the SEV MMIO path and reduces the risk of memory corruption stemming from zero-length MMIO handling.

The commit hardens KV key construction and validation by replacing ad-hoc namespace/resource/group validation with apimachinery validators and by switching the per-resource KV path layout from <namespace>/<resource>.<group>/<index-key> to <namespace>/<resource>/<group>/<index-key>, using '/' as the separator. This addresses potential KV key integrity and path-traversal issues where crafted inputs could produce ambiguous or malformed keys, leading to incorrect parsing, leakage, or unintended access across namespaces. The changes also update ListNamespaceResources to parse the new two-segment data layout. Overall, this is a security-oriented hardening of input validation and key encoding rather than a mere dependency bump or test addition.

The commit hardens error handling in the dash validator and related Prometheus fetcher to prevent information leakage via user-facing error messages and logs. Previously, upstream error responses could include sensitive details such as the datasource URL and raw response bodies (e.g., Prometheus error messages or internal stack traces). The changes remove or mask these details from user-facing errors (e.g., omitting URL and response bodies in validation errors) and log internal data at DEBUG level for operators. This reduces information disclosure vectors (URLs, error payloads) while preserving enough context for debugging via internal logs.

Vulnerability: cross-tenant information disclosure via a shared metrics cache. Before this fix, MetricsCache cached results using only the datasource UID as the key. If multiple orgs used the same datasource UID, a cache entry could be reused across orgs, allowing one org to observe another org's metrics data from the cache. The patch scopes the cache per organization by including orgID in the cache key and in the singleflight key, effectively isolating cache entries per organization. This reduces the risk of information leakage between tenants when using the dashvalidator metrics cache.

The commit fixes a race condition between pod nomination and moving a pod to the active scheduling queue. Previously, a pod could be moved to the active queue before its nomination was recorded, creating a window where the scheduler could pop the pod from the queue without an associated nomination, leading to timing-based misbehavior or inconsistencies in scheduling decisions. The patch ensures nomination is recorded before moving to the active queue by: - Recording nomination in Add() before moveToActiveQ() - Recording nomination in Update() before moveToActiveQ() - Documenting that queue signaling is the caller’s responsibility (no implicit wakeup signals inside add/moveToActiveQ) - Adding tests to verify that gated pods are nominated and that nomination happens prior to activation

The commit adds a wipe of object system fields on create-via-update and create-via-apply paths by calling rest.WipeObjectMetaSystemFields(objectMeta) during the Update flow. This hardens input handling by ensuring clients cannot set or contend with server-managed metadata (e.g., managedFields, creationTimestamp, resourceVersion) when performing certain update/patch pathways, aligning behavior with create requests. The change reduces the risk that client-supplied system fields could escape server sanitation and cause inconsistencies or race conditions. This is a defensive security hardening focused on metadata handling during specific update/patch flows; it is not a broad vulnerability in isolation but mitigates a class of metadata-tampering issues.

The commit refactors admission CEL object caching to introduce a LazyObject wrapper for VersionedObject and VersionedOldObject, ensuring that any mutation via Set() clears the cached CEL (ref.Val) representation. Prior to this change, the system cached the CEL representation (celVal) of an object and did not invalidate it when the underlying runtime.Object was mutated during admission. This creates a desynchronization risk between the object state and its CEL evaluation, which could lead to an authorization bypass or incorrect policy decisions during mutating admission. The fix enforces cache invalidation on mutation, causing CEL evaluations to reflect the latest object state, thereby stabilizing policy evaluations during admission and reducing the risk of policy desynchronization. In short: it changes caching of CEL representations from a separate cached field to a LazyObject that invalidates the CEL value on Set(), reducing the window where policy evaluations could run against stale object state.

The commit threads context through node shutdown paths in kubelet, propagating cancellation and timeouts into shutdown-related operations (pod termination, volume unmount waits, and node-status synchronization). Previously, shutdown routines could race or continue long-running operations without a shared cancellation context, potentially leaving resources in an inconsistent state or exposing sensitive information during teardown in edge cases. By passing a contextual ctx through killPods, WaitForAllPodsUnmount, and related shutdown flows (including Windows preshutdown handling), the shutdown process can be canceled promptly, reducing race windows and improving reliability and security during teardown.

The commit integrates declarative validation into REST create/update strategies by merging declarative validation with existing handwritten validation. Specifically, it updates validation flow so that when a strategy implements DeclarativeValidationStrategy, the runtime will first run handwritten validation (Validate/ValidateUpdate), then run declarative validation (ValidateDeclaratively) and merge the results, performing migration checks. It also wires declarative validation into BeforeCreate/BeforeUpdate paths and introduces configuration hooks (DeclarativeValidationConfigurer, DeclarativeValidationConfig) to tailor declarative validation per strategy. This reduces the risk that invalid configurations bypass API boundary validation, strengthening input/configuration validation and policy enforcement at REST boundaries. The change is a defensive hardening of input validation rather than a user-facing feature, and it affects internal API server validation flows across create and update operations. A real vulnerability analogous to this change would be a scenario where declarative validation could run independently of handwritten validation, or where its errors were not merged with handwritten validation errors, allowing invalid configurations to be accepted if only one validation path fired. By ensuring declarative and handwritten validations are merged, this patch mitigates that risk and tightens validation coverage across API boundaries. Affected behavior summary: - Before: If a strategy implemented DeclarativeValidationStrategy, declarative validation might not be consistently applied in conjunction with handwritten validation during create/update flows. - After: For create/update operations, handwritten validation results are computed and then declarative validation is invoked (when applicable), with merged errors returned to the caller. This ensures both validation sources contribute to the final decision. Security posture impact: improves input/configuration validation coverage, reducing chances of misconfigurations or invalid resources slipping through API validation. It does not introduce a new exposure and is aimed at reducing a potential validation bypass vector.

The commit fixes a potential command injection vulnerability in kubectl cp where the path inside the container could be interpolated into a shell command (tar pipeline) without proper escaping. Prior to this fix, paths containing shell metacharacters (e.g., spaces, quotes, semicolons) could terminate the tar command and inject arbitrary commands into the remote shell (e.g., uname -a) executed inside the pod/container. The patch adds proper quoting and escaping for the path and uses a remote executor to ensure safer command construction, reducing the risk of command injection when copying files to/from pods.

The commit implements a real security-oriented fix for endpoint spoofing by handling duplicate IPs across local and remote endpoints in the HNS-backed proxy. Previously, if two endpoints shared the same IP (one local, one remote), the system could end up with conflicting endpoint mappings, potentially allowing traffic to be misrouted or leaked between services. The fix introduces: (1) enhanced endpoint enumeration that returns a map of endpoints and a separate map of duplicate-IP remote endpoints, (2) logic to delete remote endpoints that share an IP with a local endpoint, and (3) integration with the proxy sync flow to clean up such duplicates and adjust refcounts. In addition, a new path in the proxier ensures that stale/remote endpoints with duplicate IPs are deleted during synchronization, preventing spoofing scenarios where a remote endpoint could shadow or conflict with a local one.

The commit changes the CronJob controller to validate and filter Jobs using an OwnerReference UID index, ensuring only Jobs owned by the CronJob are reconciled. Previously, reconciliation could include Jobs by matching OwnerReference.Name, which could allow a Job that pretends to be owned by a CronJob (via matching name) to be considered for reconciliation even when its actual owning UID did not match. The fix mitigates a potential authorization/safety bypass in the reconciliation loop by using a UID-based ownership check via an index (jobControllerUIDIndex) instead of solely relying on the Job's OwnerReference.Name.

The commit improves quoting of the source path used in a shell command when kubectl cp copies data to a pod. Before this fix, the code embedded the source path directly into a shell command (tar cf - <path> | tail -c+N) without proper quoting. If an attacker can influence the source path and inject special characters (notably a single quote), they could terminate the current quoted string and inject additional shell commands, potentially leading to arbitrary command execution (command injection) during the tar streaming step. The patch wraps the path in single quotes and escapes embedded single quotes inside the path, mitigating the injection risk by ensuring the path is treated as a literal argument to tar rather than executable shell code.

This commit appears to be a real security hardening fix rather than a mere dependency bump. It introduces a dedicated RBAC path for the API server to access the kubelet API: adding a specific ClusterRole (system:kubelet-api-admin) and a ClusterRoleBinding (kubeadm:apiserver-kubelet-client) bound to the API server's kubelet client certificate. This replaces a broader/unrestricted RBAC setup, tightening least-privilege access for the apiserver-to-kubelet communication. The patch also includes tests and constants to ensure the binding exists and is correctly named. Additionally, there is a small code cleanup that removes an Organization field from the kubelet client certificate config, aligning certificate attributes with the new RBAC controls and avoiding potential over-granting via certificate attributes.

This commit alters the declarative validation enforcement model from per-tag enforcement to lifecycle-based enforcement. It removes the DeclarativeEnforcement flag and relies on lifecycle prefixes (alpha/beta/standard) together with the DeclarativeValidationBeta gate to determine whether declarative validation is enforced. The changes aim to reduce the possibility of bypassing declarative validation by aligning enforcement with resource lifecycle, tightening input validation consistency across API server components. Overall, this appears to be a security-focused improvement to input validation and validation lifecycle handling, rather than a simple cleanup or dependency bump.

The commit introduces a per-tenant VectorSearch query embedding cache (FIFO eviction) and a per-tenant rate limiter (tumbling-window) to mitigate resource-exhaustion and DoS scenarios arising from abusive or heavy usage of VectorSearch. It also adds fail-closed behavior if the rate limiter is unavailable, and exposes new configuration knobs to enable/disable the features and tune caps (cache max per tenant, rate limit per tenant, and rate limit window). In short, this is a genuine security-related hardening aimed at preventing DoS via abuse of the VectorSearch backend.

Two memory-safety issues were addressed in this commit: 1) hist_field_name(): Previously, when the formatted histogram field name overflowed the local buffer, the function returned NULL, which could be passed to strcat and cause a crash or memory corruption. The fix changes the behavior to return a zero-length string (empty string) in truncation cases, avoiding NULL pointers being passed to string-ops and reducing crash risk. 2) tracing_map_elt_free on allocation failure: When elt_alloc() fails, the code previously attempted to call map->ops->elt_free(), which may not be safe since the allocation failed and the object isn’t fully initialized. The patch ensures elt_free is only invoked on successfully allocated elements by introducing a private __tracing_map_elt_free() helper and calling it in the failure path, while the public tracing_map_elt_free() wrapper only calls elt_free for fully initialized elements. Overall, these changes improve memory-safety in the tracing subsystem by avoiding NULL-dereference scenarios and unsafe cleanup paths during allocation failures.

The commit fixes a potential NULL pointer dereference in the ARM FF-A firmware (arm_ffa) bus/driver binding path. Previously, ffa_device_match would dereference the id_table pointer retrieved from the ffa_driver, even if that id_table was NULL. The patch adds a guard to return early when id_table is NULL and also requires a non-NULL id_table when registering a driver. This hardens against memory-safety issues (NULL pointer dereference) in the FF-A bus/driver binding code path, which could crash the kernel under certain firmware/client conditions.

The commit adds enforcement that global variable metadata.name must be derived from the variable's spec name and the folder scope, and rejects mismatches on create/update. Specifically, it derives a canonical name (status--<folderUID> when a folder is present) and validates any provided metadata.name against that derived value. This blocks a potential input validation vulnerability where an attacker could supply a mismatched metadata.name (or omit it to rely on server-side derivation) and cause inconsistent ownership/namespace mapping or misconfiguration. The change also tightens update behavior to prevent changing the effective name or folder scope of an existing variable. Overall, this is a real security-oriented validation fix, not just a dependency bump or test-only change.

This commit adds explicit overflow checks in time parsing to prevent int64 overflow when computing nanoseconds for relative times. Specifically, ParseTimeAt now computes nsec := currentTimestamp + int64(d) and if nsec < 0 it returns an error indicating the value is outside the allowed time range, instead of allowing wraparound. Additionally, relative duration parsing in ParseDuration is bounded by min/max valid values and returns an error when the parsed duration is outside those limits. These changes tighten input validation for time parsing, reducing the risk of negative or out-of-range timestamps being produced from crafted inputs, which could otherwise lead to incorrect time calculations, crashes, or logic errors in time-dependent components.

The patch adds explicit validations in the folder update/move workflow to prevent interacting with the special K6 folder. Specifically, it blocks updating (moving) the K6 folder itself and prevents moving any other folder into the K6 folder. Prior to this patch, a user with folder-move permissions could relocate the K6 folder or place other folders under K6, which could bypass intended boundary protections around a privileged/legacy folder and potentially enable privilege escalation or information exposure. The fix enforces a dedicated protection boundary around the K6 folder at the API validation layer and updates tests to cover these scenarios, indicating a security-focused constraint rather than a generic refactor.

Root cause: The datasource proxy previously accepted and threaded the global Grafana settings (*setting.Cfg) through the data source proxy path into the token provider. This could allow the data source proxy to touch and potentially expose sensitive Azure configuration (e.g., client secrets, Azure-specific settings) when building an access token, especially when DataProxyLogging was enabled or an Azure-authenticated route was used. The commit introduces a focused DataSourceProxySettings struct and lazy-loading of Azure settings via a resolver callback, replacing direct usage of *setting.Cfg with this narrower structure. This hardening reduces exposure by restricting what the proxy can see and by deferring access to Azure config until actually needed. It also reduces the surface area through which sensitive config could be disclosed or misused in proxy/auth flows.

The commit adjusts error handling and redirect logic in Grafana's Kubernetes short URL goto flow to minimize open redirect risk. It differentiates 404 errors from the API group and other 404 scenarios to avoid permanent redirects in misrouted error cases, prevents caching of misdirected redirects, and generally ensures error paths redirect back to the application URL rather than issuing redirects to user-supplied or external targets. This reduces exposure to open redirects and unintended information disclosure via the short URL service.

The commit adds explicit bounds/overflow checks in the QAIC mmap path (drivers/accel/qaic/qaic_data.c) to prevent out-of-bounds remapping when mapping a QAIC buffer into user space. Specifically, qaic_gem_object_mmap now computes remap_start, remap_end, and length with overflow-safe helpers (check_add_overflow, check_sub_overflow) and clamps the remapped length to fit within the user VMA. If the computed remap would overflow the VMA, it returns an error (-EINVAL). This mitigates a memory-safety vulnerability where an mmap remap could run beyond the user’s VMA, potentially corrupting kernel or DMA memory or leaking information. The triage notes list other changes (reservation handling, cleanup, etc.) as stability/correctness fixes; the security-relevant portion is the QAIC mmap bounds/overflow fix.

The commit fixes a potential information disclosure by wrapping internal errors from batch authorization checks in an internal server error type. Previously, when a batch authz check failed, the server could propagate the underlying internal error details back to clients (e.g., via the error message 'batch authz check failed: <inner-error>'). The change wraps the inner error with an internal error, reducing leakage of sensitive internals and standardizing error handling for authorization failures.

The commit implements a security-hardening: it validates that the Authenticate request contains a non-empty Namespace and propagates that namespace into the request context. If the namespace is missing or empty, the function now returns an AUTHENTICATE_CODE_FAILED with an error (errExpectedNamespace) and does not dispatch to downstream authn clients. This prevents potential mis-scoping of authentication/authorization flows that could occur if the namespace context were absent or defaulted. Prior to this fix, an Authenticate request without a valid namespace could be processed further, potentially leading to ambiguous or insecure authentication context.

This commit implements a security-oriented change to error handling for Kubernetes NotFound errors when dealing with folder resources referenced by dashboards. Specifically, when the Kubernetes apiserver returns NotFound for the folders resource, the code now maps that condition to the legacy /api/dashboards/db behavior by returning a 400 Bad Request with a generic folder-not-found message, instead of propagating internal NotFound details. This reduces information disclosure about internal Kubernetes/folder structures to API clients. The change is complemented by tests covering folder-not-found mappings and unrelated-NotFound cases, indicating intentional handling to avoid leaking internal error information while preserving expected behavior for non-folder NotFound.

This commit adds a compatibility gate for Bleve index formats when loading remote snapshots. It introduces a maxSupportedIndexFormat value (derived from the Bleve scorch format versions the process can read) and a check to drop any remote snapshot whose IndexFormat is unknown or newer than what is supported. This hardening prevents potential unsafe/deserialization-related handling of untrusted snapshots by ensuring only supported index formats are processed. The change is focused on input validation and deserialization safety for remote snapshots rather than adding a new feature or performance improvement. It also surfaces a warning if the format cannot be detected.

The patch adds guards and behavior changes around public dashboards to prevent unintended data fetches and potential information disclosure. Specifically: - publicDashboardQueryHandler now returns an empty result and does not trigger a backend fetch when panelId is undefined or NaN, guarding against broken or malicious requests to /api/public/dashboards/{token}/panels/{panelId}/query. - In the v2 serialization path, public dashboard mode forces QueryVariable refresh to never, preventing automatic data fetches from variables when exposed publicly. These changes address edge cases where public dashboards could inadvertently query data and expose information, or where invalid panel identifiers could invoke unintended backend behavior. Overall, this is a vulnerability fix intended to prevent information disclosure via public dashboards by avoiding unnecessary/invalid queries and by freezing variable refresh in public mode.

The commit adds support for GitHub Enterprise Server (GHES) connections and hardens the handling of GitHub App credentials used in provisioning connections. It introduces new validation to ensure a privateKey is provided, forbids a clientSecret, and enforces that appID is numeric. These changes reduce the risk of credential leakage or misconfiguration when configuring GitHub App-based provisioning against GHES, addressing a potential credential handling/input validation vulnerability. The patch also adds GHES-specific repository/connection types and wires them into the provisioning API. Overall, this is a real hardening/change to credential handling for GHES provisioning and a functional extension to support GitHub Enterprise alongside GitHub.com.

Summary of the issue: - The patch fixes a memory-safety race in the handling of reuseport BPF programs (both classic BPF and eBPF for reuseport) under concurrent detach/usage. Previously, when detaching a reuseport program (via reuseport_attach_prog or reuseport_detach_prog) the code could free the program data structures too early, potentially while other threads were reading the program (in the reuseport select path). This could lead to use-after-free and memory-corruption scenarios, evidenced by a KASAN report showing vmalloc-out-of-bounds in reuseport_select_sock and related call paths. What the fix does: - Introduces an RCU-based defer for freeing reuseport BPF programs. Specifically, sk_reuseport_prog_free() now defers freeing for classic BPF programs by scheduling an RCU callback (sk_reuseport_prog_free_rcu) that ultimately calls bpf_release_orig_filter() and bpf_prog_free(). Non-classic (eBPF) reuseport programs are freed via bpf_prog_put() as before. - The deferral ensures that any in-flight readers of the reuseport code paths do not encounter freed memory, addressing the race between detaching a program and concurrent UDP lookups/packet delivery. Vulnerability type and impact: - Type: Use-after-free / memory safety issue in reuseport BPF handling under concurrent access (RCU-related). - Impact: Potential memory corruption or kernel crash under adversarial timing of reuseport program detach while traffic is being processed. This is a security-relevant bug due to kernel memory safety, which could be exploited to crash the system or leak/reuse freed memory under specific conditions. - Affected versions: prior to this commit (7.0-rc6 and earlier in the v7.0-rc6 track). Rationale for the assessment: - The commit explicitly defers freeing the cBPF/eBPF reuseport program until after an RCU grace period and adjusts the free path to avoid prematurely freeing memory accessed by readers in reuseport_select_sock. The repro described in the message (a thread sending UDP traffic while the program is detached) aligns with a classical UAF risk. The KASAN report cited in the commit notes the vmalloc-out-of-bounds access in reuseport_select_sock, consistent with a use-after-free related issue that the RCU-based fix addresses. The fix is a targeted memory-safety correction rather than a mere code cleanup or dependency bump. Is this a real vulnerability fix? Yes. - is_real_vulnerability: true - is_version_bump: false - vulnerability_type: Use-after-free / memory safety race in reuseport BPF handling (RCU-related)

The commit fixes a DoS/resource exhaustion risk in app/vmauth by decoupling request buffering from the retry cap. Before this change, the maximum request body size to retry (-maxRequestBodySizeToRetry) and the in-memory request buffering size (-requestBufferSize) were effectively coupled via a “larger of the two” policy. This meant that attempting to disable retries (e.g., maxRequestBodySizeToRetry=0) could be ineffective if requestBufferSize was non-zero, potentially allowing large request bodies to be buffered in memory and retried across backends, leading to uncontrolled memory growth under load. The patch updates the buffering/retry logic (canRetry) to honor the -maxRequestBodySizeToRetry limit independently of -requestBufferSize and ensures retry capability is controlled by the explicit maxRequestBodySizeToRetry value. It also updates tests to cover scenarios where retries can be disabled regardless of buffering configuration. This mitigates a DoS/vector where a client could cause excessive in-memory buffering and retries.

The patch fixes a potential memory-safety vulnerability (ADE) in the Loongson GPU DMA hang fixup for Loongson LoongArch. Previously loongson_gpu_fixup_dma_hang() derived a regbase address from a base that could be miscomputed when a discrete PCIe GPU is present, leading to an invalid address being read via readl/ioremap in a switch-case path, causing an ADE (address error) and kernel crash. The fix adds a default case to the switch that unmaps regbase and returns early, preventing invalid memory access when the PCI device is not one of the expected Loongson GPU devices. This reduces risk of a memory-safety crash during PCI device setup.

Summary: This commit hardens InlineSecureValue handling by improving input validation and error reporting. It introduces strict validation to prevent ambiguous/misconfigured secure values and blocks legacy datasource references. Specifically, it: - Adds a dedicated error constructor newSecureValueError that returns a 400 Bad Request with a structured field error (secure.<key>), improving consistency and avoiding leaking internal state. - Enforces that only one of name, create, or remove is provided per secure value entry. If multiple are provided, it returns a BadRequest error indicating the invalid combination. - Rejects secure values referencing legacy datasource values (prefix check) with a clear error. - Reworks the handling of Remove to be explicit and non-conflicting with Create/Name, reducing the risk of saving or interpreting insecure/invalid configurations. Impact: The change is a hardening of input validation for secure values. It mitigates potential misconfigurations that could lead to insecure value handling or ambiguous behavior, which could in turn pose security risks (e.g., leakage or misinterpretation of secrets) when saving or interpreting secure values. It is not a remote code execution or direct exposure vulnerability, but a hardening of configuration input that reduces attack surface due to misconfiguration. Affected area: InlineSecureValue handling in pkg/storage/unified/apistore/secure.go (and related tests in secure_test.go).