Dashboard

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.