Alerts

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).

The commit adds ListIndexKeys and GetIndexMeta to the RemoteIndexStore interface and introduces two dedicated errors (ErrSnapshotNotFound and ErrInvalidManifest) along with centralized manifest parsing in GetIndexMeta. It hardens manifest handling by validating structure, limiting manifest reads, and standardizing error propagation for invalid or missing manifests. DownloadIndex now relies on GetIndexMeta, which means malformed or oversized manifests are reported via ErrInvalidManifest (instead of generic parse errors). This reduces susceptibility to deserialization/manifest parsing issues, potential information leakage through error strings, and DoS risks from malformed manifests. It’s a vulnerability-hardening change focused on manifest processing and error handling, not a mere dependency bump or ancillary cleanup.

The commit fixes a security issue in Flask's copy_current_request_context decorator. Previously, the decorator captured a single copied request context (ctx) at decoration time and reused that same context for all invocations. This meant concurrent calls to a function wrapped with copy_current_request_context could operate on a shared copied request context, risking cross-call leakage of request/session data between concurrent executions. The patch changes the logic to capture the original (current) app/request context at invocation and creates a fresh copy for each call (with original.copy()). This ensures each worker/ invocation gets an isolated request context, reducing the risk of information leakage across concurrent requests. What changed (high level): - Store the active context at decoration time as original rather than a copied ctx. - In the wrapper, push a fresh copy of the original context for each call (with original.copy()) instead of reusing a single copied ctx. - Adjusts the guard to require an active request context via original (original is None check). - Tests were updated to exercise per-call isolation (thread-based test) and remove greenlet-based tests that relied on shared context across calls. Vulnerability type: Information Disclosure / Improper isolation in request context within copy_current_request_context (concurrent invocations may leak between calls). Affected scope: Pre-fix releases that used the older single-copy behavior (prior to this commit). Likely affects 3.1.x releases before this change (the commit targets 3.1.3 as tracked version).

The commit eliminates a bespoke shelf middleware that served the contents of dwds/src/injected/client.js by reading the file from disk and returning it in the HTTP response. This custom path could expose the contents of an internal injected client script if accessed by a client, constituting an information-disclosure risk. By removing the disk-read path and relying on the standard dwds handler, the fix reduces the surface for leaking internal assets. The change is accompanied by a dependency bump to dwds 27.1.1, indicating both a refactor and vulnerability-related hardening.

The commit adds a server-wide advisory lock around OpenFGA migrations to serialize them with Grafana's main migrator. OpenFGA's goose migrator opens its own DB connection and lacks cross-process locking, so concurrent pod startups could race to create/modify the database schema during migrations. By acquiring an advisory lock per database before running OpenFGA migrations and releasing it afterward, the change prevents concurrent migrations from interleaving, reducing the risk of an inconsistent or partially-initialized schema that could lead to security misconfigurations (e.g., incorrect access controls or initialization). This is a correctness/consistency fix with potential security implications rather than a traditional vulnerability patch.

The commit contains multiple security-relevant changes in the ARM64 KVM PKVM/hyp paths and related selftests. Key hardening points include: - Restricting SMCCC host calls depending on PKVM finalization state and introducing explicit min/max boundaries for privileged calls, reducing the risk that a non-finalized PKVM guest can reach privileged hypercalls. - Strengthening synchronization when publishing per-vCPU hyp structures (use of acquire/release semantics via smp_load_acquire and a new register_hyp_vcpu helper) to avoid races between initialization and publishing to the host-visible vcpu array. - Correcting initialization/finalization ordering and ownership fixups to avoid leaks, use-after-free, or out-of-order exposure of privileged state. - Minor hardening around memory/ID handling in VGIC paths to avoid exposing/using incorrect revision data. Collectively, these changes harden PKVM initialization, vCPU publishing, and host-call gating, reducing potential avenues for privilege escalation or information disclosure via race conditions or misordered state. This is not a simple dependency bump or test addition; it is a substantive code fix across several security-relevant areas of KVM PKVM/arm64, addressing race conditions and privilege boundaries.

Patch introduces UI-level read-only gating for editing alert rule groups that are plugin-provided, provisioned, or federated. getRulerGroupReadOnlyStatus/getPromGroupReadOnlyStatus are used to determine readOnly status; editing is blocked in the UI for such groups and informative alerts are shown instead. Additionally, failed update attempts log richer backend context for actionable debugging. This addresses an authorization/access-control concern where externally managed rule groups could be edited via Grafana UI (and potentially API paths) before the fix.

The commit fixes a null-dereference crash in SemanticsObject when the AccessibilityBridge is no longer alive. The patch guards all places that dereference the bridge (e.g., bridge->view()) by checking bridge liveness via isAccessibilityBridgeAlive and returns nil for UI focus targets or CGRectZero for frames when the bridge is dead. This prevents crashes that could be triggered by a stale bridge pointer, improving memory safety. A regression test was added to ensure no crash when the bridge is dead.

The patch fixes a memory-safety vulnerability in the HVC IUCV path. The function hvc_iucv_get_private previously used a bounds check that allowed an out-of-bounds access when the requested index num equaled the number of devices (num == hvc_iucv_devices). The code path returned hvc_iucv_table[num], which would access memory after the end of the hvc_iucv_table array. This could lead to out-of-bounds reads (and potentially writes) in kernel memory, depending on how the returned pointer is used. The fix changes the condition to if (num >= hvc_iucv_devices) to prevent the out-of-bounds access.

The patch fixes a race/liveness issue in zswap's per-CPU crypto accelerator context (acomp_ctx) lifecycle by tying the per-CPU acomp_ctx resources to the zswap pool lifetime. Previously, acomp_ctx resources could be allocated and referenced across CPU hotplug cycles and pool creation/destruction, which opened a window where CPU offline/online transitions and pool lifecycle could lead to use-after-free or inconsistent crypto state if acomp_ctx resources were freed or partially initialized during hotplug handling. The fix: - Allocates per-CPU acomp_ctx on pool creation (or CPU hotplug for CPUs online later) and keeps them allocated until pool destruction, preventing premature teardown during CPU offline events. - Introduces acomp_ctx_free() and moves cleanup logic there, ensuring proper deallocation of acomp_ctx resources even in migration scenarios. - Uses cpuhp_state to serialize pool preparation with CPU hotplug so CPUs aren’t offlined until the preparation completes. - Removes the old per-CPU acquire/release helpers in favor of direct mutex usage on acomp_ctx->mutex, and ensures proper cleanup paths on failures during pool creation. These changes mitigate a race between CPU hotplug, pool lifecycle, and per-CPU crypto context management, reducing the risk of use-after-free or memory/crypto state corruption during hotplug events.

The patch adds a global tracking mechanism (luo_preserved_files) to prevent the same file/resource from being managed by multiple LUO sessions by recording an identifier for each preserved file. It introduces a get_id callback to allow resources to define what constitutes a unique identifier. However, the implementation has a race-condition/chronic misbehavior: in luo_retrieve_file(), the code unconditionally calls xa_insert(...) and then uses WARN_ON(...) to report if the key already exists, but it does not enforce a failure when the insert fails. As a result, two LUO sessions could concurrently preserve the same resource (especially when get_id() provides a stable cross-process identifier), potentially leading to conflicting access, resource mismanagement, or use-after-free scenarios if the resources are finished/released concurrently. The guard in luo_preserve_file() would otherwise prevent a second preservation by returning -EEXIST, but the retrieve path path can bypass this protection due to its non-fatal handling of duplication.

The patch adds an RCU-protected path around accessing the memory cgroup from a folio in count_memcg_folio_events(). Previously, the code could read a memcg pointer (folio_memcg) and use it without preventing concurrent release of the memcg, creating a potential use-after-free or memory-safety race when a folio’s associated memory cgroup is released while being observed. The fix guards the access with folio_memcg_charged(folio) and an RCU read-side critical section, ensuring the memcg cannot be freed while its pointer is being used for event counting. This addresses a race condition that could have security implications if exploited during future LRU folio reparenting or memcg releases.

The commit fixes a potential use-after-free in the rxrpc receive path. Previously, when skb_unshare() could fail during in-place decryption, the parent skb pointer in the rxrpc_io_thread could be NULLed, which risked a downstream oops when trace_rxrpc_rx_done() accessed the skb. The patch moves the unsharing logic into rxrpc_input_call_event() where packets are processed for a given call, and adjusts the flow to avoid mutating the parent skb pointer on failure. It also removes the in-place unshare handling from rxrpc_input_packet(), and changes the skb handling API accordingly (no pointer-to-pointer updates). Additionally, some tracing/logging related to unshare is updated. Overall, this is a memory-safety fix in the RxRPC receive path to prevent a use-after-free/oops scenario caused by a failed skb_unshare().

The commit addresses a potential path traversal vulnerability in on-disk storage handling for Bleve snapshot uploads and related index path construction. Previously, resource paths were assembled by joining the root with namespace/resource segments, which could be influenced by attacker-controlled resource identifiers. The patch introduces a sanitized path construction via resourceSubPath (which applies cleanFileSegment to Namespace and Resource/Group components) and guards staging paths with isPathWithinRoot to ensure the final path cannot escape the configured root. It also creates a bounded staging directory under Root/snapshots for uploads and updates remote/index path helpers to rely on the sanitized resourceSubPath. These changes reduce the risk of path traversal and unauthorized filesystem access during snapshot uploads and index storage.

The commit hardens input validation on the service account token APIs (create, delete, list) by adding field validation for the token-related queries and making UID mandatory in the Go layer. Previously, inputs to these endpoints (notably UID in paths/filters and token request bodies) could be malformed or omitted, increasing the risk of token leakage, misassociation, or improper authorization when managing tokens for service accounts. The change moves related types and validates fields to ensure tokens are created/listed/deleted only for explicitly identified service accounts, reducing the attack surface around token management. In short, this is a security-hardening change that fixes an input validation gap in token APIs rather than a pure refactor or test-only change.

The commit replaces usage of a dynamic Kubernetes client (unstructured path) in UserK8sService with a typed client generated via the Grafana App SDK (ClientGenerator). Previously, the code constructed an unstructured Kubernetes object and used a dynamic client to Create it, which can be prone to deserialization/type-confusion issues when handling Kubernetes resources. The change moves to a strongly-typed IAM v0alpha1.User object and uses a typed client, enforcing schema validation and reducing the risk of crafted or malformed payloads being misinterpreted during user creation. This addresses a potential deserialization-related vulnerability associated with unstructured Kubernetes resources and type conversion.

The commit hardens URL handling after stripping a configured prefix by trimming whitespace from prefixes and normalizing the remaining request URL via URL.JoinPath(), then updating ForwardedPrefixHeader and RequestURI. This addresses a potential path traversal / URL handling issue where crafted URLs containing dot-segments (e.g., "/api../secret" or "/api./foo") could bypass the prefix-stripping logic or leave the forwarded path in an unnormalized form. By canonicalizing the path after stripping, the risk of forwarding unsafe or unintended paths to the upstream service is reduced.

The commit prevents leaking internal/system dashboard variables (notably the ScopesVariable) through UI paths used for repeat blocks and conditional rendering. Previously, code paths derived available variables from the scene graph (including system variables) and surfaced them in UI elements like the variable selection Combobox. This could allow a dashboard viewer to discover internal configuration/state by listing or selecting system variables (and potentially exposing their values via UI rendering). The patch introduces filtering to only include user-defined variables in the relevant flows (via useUserDefinedVariables and keepOnlyUserDefinedVariables) and adds tests to ensure system variables are stripped away. This is a genuine information-disclosure fix.

The commit adds dynamic resolution for datasource migration resource groups and merges legacy groups with groups discovered in unified storage to ensure proper pre-authorization during bulk migrations. Previously, bulk migrations appeared to rely on a static or incomplete set of resource groups, which could create authorization gaps (e.g., missing groups from unified storage or stale groups) during migrations. By resolving PluginGroups dynamically and merging with storage-derived groups, the migration process can correctly scope authorization for all relevant datasource resources across groups. This mitigates a class of access-control gaps that could otherwise be exploited during bulk migrations.

The commit fixes a memory-safety issue in the Proxy Protocol v2 parser used by the lib/netutil code. Previously, the IPv6 address was taken directly as a subslice of a pooled buffer (bb.B[0:16]). Since bb.B comes from a sync.Pool and is reused after the function returns, the IP slice could alias the underlying pool buffer. Subsequent pool reuse could overwrite the memory backing the IP address, leading to data corruption or leakage when the parsed address is kept by the caller. The fix copies the IPv6 address into a new slice (ipv6Addr) and uses that as the IP value, preventing aliasing with the pooled memory. A regression test TestParseProxyProtocolIPv6DoesNotAliasPool was added to ensure the IP does not alias the pool across consecutive parses.

The commit changes production error handling for all browser bundles to minify prod error codes/messages, reducing information leakage. It also expands the error code map (scripts/error-codes/codes.json) and flips minifyWithProdErrorCodes from false to true for multiple bundles. The resulting behavior is that production browser errors no longer expose verbose internal messages or stack traces, mitigating potential information disclosure about internal server/client boundaries and bundler details.

The commit changes the Data Hover UI rendering to sanitize and constrain link rendering in data-hover tooltips. Previously, values could be rendered as clickable links via a shared geomap/ui utility (renderValue) that wrapped URLs in an anchor tag without URL sanitization. The new approach introduces a dedicated renderValue implementation under data-hover that only renders http/https URLs and sanitizes the href via textUtil.sanitizeUrl, while leaving non-http/https values as plain text. It also adds an isHttpUrl helper and tests for it. In effect, this mitigates potential XSS via untrusted inputs in Data Hover tooltips by preventing execution of untrusted or malicious URLs and ensuring sanitized, safe anchor targets.

The commit adds an AllowsKind gate and configurable ScopeAttribute for ResourcePermission mappers, plus a storage backend exclusion of BasicRole for service accounts. Before this change, nil allowedKinds meant all permission kinds (including BasicRole) could be assigned to resources, enabling potential authorization bypass/privilege escalation by granting BasicRole to a ServiceAccount or other resource. The patch hardens RBAC by ensuring only whitelisted kinds are allowed for a given resource and scope, and by avoiding dangerous combinations in storage.

The commit moves BTF validation logic into a dedicated check_btf.c and wires it into the BPF verifier. It hardens handling of BTF-derived information for func_info, line_info, and core_relo, preventing malformed or inconsistent BTF attributes from bypassing the verifier's security checks. This is a genuine security hardening against potential verifier bypasses that could lead to code execution on crafted BPF programs. The change is not merely a dependency update or a cosmetic cleanup; it adds targeted validation paths and integrates them with the verifier flow.

The commit fixes a race condition in the pending-delete cleanup flow for tenants in Grafana's Unified Storage. Prior to this change, the pending-delete lifecycle could be mishandled during cleanup, potentially allowing a tenant to be recreated or left in an inconsistent state while the cleanup is in progress. The patch introduces a DeletedAt timestamp and an Orphaned flag to differentiate between orphaned and non-orphaned pending-delete records, and adjusts deletion logic to guard against reprocessing and unintended recreation. Key points addressed: - Added DeletedAt to PendingDeleteRecord. Non-orphaned records are marked DeletedAt after successful deletion, preventing reprocessing by the tenant deleter. - Reconciler now propagates Orphaned flag instead of Force, and clear logic skips orphaned records rather than forcing skip behavior. - Non-orphaned records are not re-created during cleanup because the tenant deleter will mark them DeletedAt and skip reprocessing. - Tests updated to reflect new behavior (DeletedAt set after expiry, orphaned records removed entirely, etc.). Affects scenarios where a tenant could be concurrently cleaned up and re-considered by the watcher, creating a timing window for inconsistent deletion state. The fix provides deterministic cleanup semantics by ensuring DeletedAt gates further processing and orphaned records are handled distinctly.

The commit standardizes NotFound error handling for annotations across in-memory, SQL, and Kubernetes adapters. It maps internal NotFound errors to API-level NotFound responses and avoids leaking whether a resource exists when access is restricted. Previously, error messages or HTTP statuses could disclose existence or details about resources, enabling resource enumeration. The changes aim to minimize information disclosure by returning uniform NotFound responses for missing resources (and related permission scenarios) rather than revealing existence through mixed error messages or statuses.

The commit adds an optimization in ActiveSupport::ParameterFilter to detect anchored exact-match regular expressions and treat those keys as exact matches to be masked. Specifically, it introduces extract_exact_key to derive a literal key from anchored patterns like /^token$/ or \Atoken\z and stores these in an @exact_keys hash. During filtering, if a key exactly matches one of these literals, or if a general regex matches the key, the value is masked. This reduces the risk of information disclosure by ensuring that sensitive parameter names that are intended to be masked (even when specified with anchored exact-match regex) are reliably hidden across both top-level and nested parameter structures. The change also adds a test for anchored exact-match regexp filters to verify the behavior.

The commit fixes a race/resource-leak in the write concurrency limiter. Previously, Read() could decrease the available concurrency tokens (via DecConcurrency()) and, if IncConcurrency() failed, the token would not be re-acquired, potentially leaking a slot permanently. This could drain the concurrency limiter channel over time, eventually causing ingestion to deadlock when no slots remain. The patch adds per-reader tracking of whether a token has been obtained (increasedConcurrency) and ensures tokens are released correctly when the reader is returned.

The commit adds a validation guard in ParseDataKeyParts to ensure the resource version metadata (rvMeta) contains at least 3 tilde-separated parts before accessing rvParts[1] and rvParts[2]. Previously, crafted or malformed rvMeta values with only 1 or 2 segments could lead to an index-out-of-range panic when parsing storage KV keys, potentially crashing Unistore and causing a denial-of-service condition or information leakage. The change is accompanied by tests covering edge cases and panic avoidance.

The commit changes public dashboards to avoid reusing a session-scoped scene cache and to build the dashboard scene from API data instead of cached scene data. Before this fix, public dashboards could be loaded from a per-session cache, risking information disclosure or leakage across sessions if a cached scene containing user/session-specific data was reused for another user or session. The fix ensures public dashboards are not pulled from the session cache and are constructed from API data, reducing stale or cross-session data exposure and aligning authorization context with the API response. This is a genuine vulnerability fix for cache mishandling related to public dashboards.

The commit fixes a UI-driven information-disclosure risk in the Grafana Connections landing page. Previously, the landing page derived its cards from a hardcoded CardData.ts, which did not reflect actual backend visibility (RBAC) or plugin availability. This could cause a user to see cards for resources they should not access, effectively leaking the existence (and structure) of restricted plugins or data sources. The patch derives landing page cards from the backend-provided navIndex (which applies full plugin availability and RBAC checks) and enriches the card data via a metadata map. This aligns UI visibility with backend access control and edition-specific copy, reducing information disclosure and preventing exposure of inaccessible items.

The commit adds v2-specific sanitization for public dashboards to strip potentially dangerous fields from query specs for v2 dashboards, preventing injection or leakage of query expressions. It introduces isDashboardV2 and sanitizeDataV2 and uses them in GetPublicDashboardForView, so v1 dashboards continue using existing sanitization. This appears to be a security-conscious change aimed at avoiding execution or disclosure of user-provided query expressions in v2 dashboards when served via public dashboards.

The commit refactors RBAC checks for snapshot operations to use general dashboard actions instead of per-snapshot actions. Specifically, it replaces references to dashboardsnapshots.ActionSnapshotsCreate/Delete/Read with dashboards.ActionSnapshotsCreate/Delete/Read and adjusts evaluators to require both the create/delete/read action and the corresponding dashboards read permission with the correct dashboard scope. This aligns authorization checks across dashboards and snapshots, reducing the risk of misconfigurations allowing unauthorized access to snapshot functionality. In prior versions, mismatch between snapshot-specific actions and roles could permit unintended access or block legitimate access, depending on how roles were defined.

The commit removes legacy access control logic and related permissions imports used for annotation/dashboard access checks, replacing them with a newer access control path. Specifically, it eliminates the old RBAC filter (NewAccessControlDashboardPermissionFilter) insertion into SQL query construction and stops passing legacy Filters to the dashboard search. This appears to be an authorization hardening effort intended to unify access control checks under a newer mechanism (OpenFGA-based path mentioned in code comments). While the code changes suggest removing a potential bypass route from the legacy ACL checks, the exact security impact depends on the surrounding new authorization path being correctly enforced in all call sites. The triage notes indicate the intent to mitigate bypasses in legacy ACL checks for annotations and dashboards.

The commit contains a targeted fix in the Android binder driver related to VMA (vm_area_struct) handling and vm_ops identity checks. Specifically: - binder/page_range.rs wraps the static vm_operations_struct in a Sync-enabled wrapper (AssertSync) and adjusts the identity check to compare the vm_ops pointer against the inner value (BINDER_VM_OPS.0) rather than the wrapper object. - binder/rust_binder_main.rs defines a small AssertSync<T> wrapper and makes the inner type Sync, ensuring the global C binding type is treated as Sync, with a clarified safety comment. - These changes fix a potential memory-safety issue where an incorrect or non-atomic comparison of vm_ops could lead to misidentification of a VMA, potentially allowing use-after-free or memory misuse in binder IO/vma handling. The vulnerability is described as a memory-safety (use-after-free) risk in the kernel binder VMA handling, mitigated by making the vm_ops identity check precise and ensuring correct Sync semantics for a global C-binding struct. Affects pre-fix 7.0-rc6; fixed in 7.0-rc7 and related patches.

The commit adds a guard in When.__init__ to prevent internal keyword arguments (_connector, _negated) from propagating to Q(**lookups). If such invalid kwargs are present in the lookups passed to When, it raises a TypeError with a descriptive message listing the invalid kwargs. This is defensive input-validation hardening in query construction to prevent misuse of internal flags during query building. The change appears to be a genuine fix focused on validating inputs rather than a general code cleanup or a test-only change.

The commit hardens warning output by caching and reusing internal Django file prefixes and using skip_file_prefixes to suppress Django’s own filesystem paths from warning traces. Previously, certain warnings could leak internal Django file paths in stack traces (information disclosure). The change introduces django_file_prefixes() to return a tuple of internal Django prefixes and updates warning calls to pass these prefixes, effectively filtering out Django’s own path components from warning output. This reduces leakage of internal filesystem structure in error/warning messages.

The commit fixes a bug in multipart header parsing where the parser could be fed the entire header line (including the header name) instead of just the header value. This could lead to incorrect parsing or misinterpretation of header parameters for multipart requests. The change tightens input handling by splitting the header line at the first colon and only passing the value portion to parse_header_parameters, ensuring the header name is not mis-parsed as part of the value. A test asserting proper handling of malformed headers (e.g., spaces around the colon) was added to validate robust parsing.

The commit fixes an edge-case in ASGIRequest.path_info calculation. Previously, the code derived path_info by simply removing the script_name prefix from the request path (using removeprefix). This caused incorrect path_info for request paths that start with the script_name but do not have a slash boundary immediately after it. Example: path "/rootprefix/somepath/" with script_name "/root" would incorrectly strip "/root" and yield "prefix/somepath/". The new logic only strips the script_name when the path starts with script_name + "/" or when the path exactly equals script_name. Otherwise, it preserves the full path. This prevents miscomputation of path_info that could lead to unintended access to resources or leakage of path data, addressing a path handling vulnerability.

The commit implements propagation of the ORM's fetch_mode state across related objects when traversing relationships. Previously, fetch_mode restrictions applied to the top-level queryset but were not consistently propagated to related objects fetched via relationships (forward and reverse). The patch copies the fetch_mode from a source instance to related objects in multiple code paths (prefetching, related descriptors, and query iteration), and updates tests and docs to reflect that fetch modes apply to an entire object graph, not just the initial model. This reduces the risk of information disclosure or access-control bypass where related objects could be fetched under a different (potentially less restrictive) fetch_mode. The triage notes align with this being a security fix improving consistency and enforcement of fetch-mode-based access controls across related fetches, rather than introducing a new feature.

The commit introduces Action Text Markdown conversion and a safety mechanism for links during Markdown rendering. It adds to_markdown conversions across Content, Fragment, RichText, and Attachments, plus a new MarkdownConversion module that converts HTML to Markdown. Crucially, it enforces that Markdown links are filtered against Loofah's allowed URI protocols to prevent unsafe schemes (e.g., javascript:) from appearing in output. This mitigates a potential XSS/vector risk where attacker-supplied content could be transformed into unsafe Markdown links and rendered in a way that executes script code. The vulnerability is mitigated by disallowing dangerous protocols and stripping unsafe link representations during Markdown generation.

This commit implements explicit cleanup of environment variables to prevent ENV leakage across processes and test boundaries. Specifically, it changes the migrations task to delete ENV['FROM'] after use and uses the deleted value for logic, reducing the risk that the value remains in the process environment. It also strengthens test cleanup by removing or restoring ENV['RAILS_ENV'] (and related vars) in teardown and via helpers, ensuring environment vars are not leaked into child processes. Collectively, this reduces potential information disclosure where sensitive data or configuration exposed in ENV could be inherited by spawned processes or future operations.

The commit changes Rails' atomic file write to use a temporary file name that includes a random suffix. Previously the temporary file name was effectively predictable (based on the target file name) and could be pre-created by an attacker in the same directory, enabling a TOCTOU/race condition or a symlink-like interference during the atomic write. The patch mitigates this by appending a random suffix to the temporary file name, reducing predictability and lowering the likelihood of successful pre-creation or race attacks. Tests were added to verify that two atomic writes produce unique temp file names, reinforcing the security intent.

This commit centralizes the protected_environments API by moving it from ActiveRecord::Base to ActiveRecord, defaulting to production, and introducing deprecation warnings for older usage. This hardens protection against destructive migrations by ensuring a single, canonical source of truth for environment-based restrictions and guiding developers to migrate usage. It reduces the risk of accidentally allowing destructive actions in non-production environments due to API scoping mistakes or legacy code paths. The tests are updated to reflect the new API usage and to signal deprecation for the old path.

The commit adds guard_load_hooks in ActionPack Railties to guard/whitelist the loading of hooks for ActionController and ActionDispatch. This hardening mitigates potential code execution paths via user-controlled or misconfigured load hooks during Rails initialization. By restricting which hooks can be loaded (and likely when), it reduces the risk that arbitrary code could be executed at boot or during initialization from external components. The fix appears to be a defensive measure to prevent abuse of Rails' hook-loading mechanism, rather than a fix for a widely-known external vulnerability; its impact depends on whether untrusted code can register or inject load hooks that Rails would execute during startup.

The patch targets a potential information disclosure during middleware stack construction by altering how the Flash middleware attaches its request methods. It moves the inclusion of Flash::RequestMethods behind an ActiveSupport.on_load(:action_dispatch_request) callback and removes an eager require of action_dispatch/request/session. This lazy-loading approach prevents early exposure or leakage of request/state objects while the middleware stack is being built, reducing the risk of information leaking across requests via the request object.

The commit refactors File.atomic_write to reduce TOCTOU/race-prone behavior and preserve permissions when writing a file atomically. The previous approach relied on a Tempfile-based path and a prior permission probing mechanism. The new code: - Uses a securely named temporary file with a random hex suffix (SecureRandom.hex) in the destination directory, avoiding deterministic names that could be guessed by an attacker. - Creates the temp file with exclusive creation (EXCL) to prevent races where a file could be created between checks and use of a non-unique name. - Captures the original file's permissions (old_stat) beforehand and applies them to the new file, ensuring the destination ends up with the intended permissions. - Cleans up on error (closes and unlinks the temp file) to prevent leaks. - Removes the previous probe-based permission check (which created a temporary file in the target directory to infer default permissions), reducing side effects and potential information disclosure. This addresses race conditions in atomic writes by ensuring the temporary file is securely created, with proper cleanup and permission handling, and by avoiding a race-prone path that could leak information or grant unintended permissions.

The commit adds escaping of CommonMark markdown metacharacters in Action Text markdown generation to ensure text nodes are treated as literal text by Markdown renderers, reducing the risk of XSS via injected markdown formatting. It introduces ActionText::MarkdownConversion.escape_markdown_text, updates Content#to_markdown to wrap attachment markdown in an action-text-markdown element (so content is passed through without escaping), and adjusts how markdown links are rendered to escape their text. Overall, it hardens markdown rendering against user-supplied content that could otherwise be interpreted as formatting (e.g., headings, links, or other markdown constructs) and potentially lead to XSS when rendered by a Markdown processor.

The commit changes the default middleware stack to only insert Rack::Sendfile when x_sendfile_header is configured. Previously Rack::Sendfile could be added to the stack with a nil header, which risks misconfiguration and potential information disclosure or exposure of internal file handling details. The fix ensures Rack::Sendfile is not in the stack unless a valid x_sendfile_header is set, reducing the chance of unintended file serving or exposure of internal paths.

The commit hardens parsing of sourceMappingURL for dynamic imports. Previously, code resolved the source map URL using new URL(sourceMappingURL, sourceURL).href, which could incorrectly accept malformed URLs and proceed to load source maps, potentially leading to crashes or unsafe behavior during dynamic imports. The fix introduces a dedicated URL parser (URLParse) and a null-check to reject invalid URLs early, preventing processing of invalid source maps and reducing attack surface. An accompanying test validates that invalid URLs are tolerated rather than causing crashes.

This commit upgrades undici to 7.22.0 and includes several security-relevant changes that address proxy boundary handling, credential parsing, and websocket upgrade handling. Key points: - EnvHttpProxyAgent no_proxy handling: improved logic to avoid proxying requests when the destination hostname matches the no_proxy rule or is a subdomain, reducing information disclosure and unintended proxy usage for internal hosts. - includesCredentials fix: in fetch/util.js, the function now treats a URL as containing credentials if either the username or the password is present (previously required both). This fixes incorrect handling of URLs like http://user@host/ and http://user:pass@host/, which could affect credential handling in cross-origin contexts or proxy scenarios. - Other related fixes in cache/deduplicate/web fetch code and websocket upgrade handling were also touched. Collectively, these changes address potential security issues around proxy usage leakage and credential handling, rather than being purely cosmetic or dependency version bumps. Affected attack surface includes proxy boundary bypass (information disclosure) and credential handling in URLs (security policy correctness).

The commit hardens Node.js embedding path by enabling embedder-specific handling for dynamic module loading. It adds an embedder module descriptor (embedder_module_hdo) and a new SourceTextModuleTypes with kEmbedder, and switches embedder-run modules to compile with a dedicated type (kEmbedder). The embedding flow now restricts dynamic module imports in embedder context to built-in modules only, via getBuiltinModuleWrapForEmbedder/loadBuiltinModuleForEmbedder, preventing embedder-supplied code from loading arbitrary or external modules. This appears to be a real security hardening rather than a mere cleanup or test addition. It affects the embedder path of dynamic module loading and import.meta initialization, reducing the attack surface where an attacker could influence module loading from an embedder-supplied module.

The commit hardens input validation for the internal stack-calling utility by enabling V8 internal checks (-DV8_ENABLE_CHECKS) and constraining frameCount to be an integer within [1, 200]. It changes: (1) lib/util.js to use validateInteger for frameCount instead of validateNumber; (2) GetCallSites path in src/node_util.cc to require an unsigned 32-bit frameCount value (IsUint32) and enforce the range; (3) tests to require integer frameCount (non-integers like 3.6 now throw ERR_OUT_OF_RANGE); (4) minor type-correctness fixes in several files to align with strict input handling. The net effect is to prevent non-integer or out-of-range inputs from being treated as valid, which reduces the risk of memory-safety issues or crashes due to invalid stack-capture inputs. This is a hardening of input validation and runtime checks rather than a feature addition. It addresses security-relevant input validation and memory-safety concerns.

The commit implements memory-allocation failure handling for ArrayBuffer BackingStore usage across several Node.js internals (encoding_binding.cc, node_blob.cc, node_buffer.cc). Previously, allocation failures could result in unchecked pointers or crashes due to relying on an assumption that a backing store (bs/store) would always be non-null (e.g., CHECK(bs);). The patch adds OnFailureMode for backing stores, checks for null returns, and throws a memory-allocation error (ERR_MEMORY_ALLOCATION_FAILED) which is now a RangeError to align with V8's OutOfMemory error type. It also updates ERR_MEMORY_ALLOCATION_FAILED in node_errors.h from a generic Error to a RangeError. This reduces the risk of memory-safety issues (null dereferences or use-after-free) when memory allocation fails during operations like Encoding to UTF-8, Buffer.concat, or ArrayBuffer creation. While not a classic security flaw like XSS/SQLi, it mitigates memory-safety vulnerabilities that could be exploited via resource exhaustion or crashes under memory pressure, which can have security implications in production environments.

The commit introduces stricter HTTP token validation in undici (token character whitelist, updated isValidHTTPToken, and related utility changes). This hardens header-token handling and input validation to reduce the risk of malformed header values or token-based injection in HTTP requests. In particular, it adds a validated token character map, replaces per-character checks with a mixed per-char/regex approach, and tightens what is considered a valid HTTP token. These changes address potential weaknesses where previously permissive token parsing could allow anomalous tokens to bypass validation, potentially enabling header injection or related attacks via crafted header tokens. The upgrade to undici 7.18.2 includes this hardening alongside other stability fixes.

The commit includes a real code fix in the undici fetch path: when handling a 401 authentication scenario in browsers, the fetch logic now returns a network error instead of retrying, to prevent an infinite loop of re-sending requests after browser prompts for credentials. This mitigates a potential Denial of Service due to looping retries, and is accompanied by a dependency bump from undici 7.19.0 to 7.19.1. While the core change is a robustness guard, it targets a security-sensitive control flow and reduces the risk of resource exhaustion in adversarial or misbehaving environments.