Alerts

The commit fixes a Denial of Service vector in the BR/EDR signaling path of Linux Bluetooth (L2CAP). Prior to this patch, the BR/EDR signaling channel allowed packets larger than the BR/EDR signaling MTU (MTUsig, defined as 48 octets) to be accepted and parsed. An attacker in radio range could send a single oversized BR/EDR signaling packet (e.g., ~681 bytes) on the fixed-channel CID 0x0001 containing many L2CAP_ECHO_REQ commands. If processed, this could trigger a flood of L2CAP_ECHO_RSP frames (e.g., 168 responses) in a short time, causing CPU/L2CAP stack churn and a DoS. The patch enforces MTU for BR/EDR signaling by rejecting oversized signaling packets with a L2CAP_REJ MTU_EXCEEDED, before any command processing, using the first command header's identifier for the rejection. This fixes the DoS vector by eliminating the processing of oversized packets and preventing echo floods. The patch also defines L2CAP_SIG_MTU as 48 bytes.

The patch strengthens VMA state validation during UFFDIO_COPY retries in userfaultfd. Previously, mfill_copy_folio_retry() only compared the VMA's uffd_ops before and after the retry. If a VMA was replaced or its mapping changed (e.g., MAP_PRIVATE vs MAP_SHARED) while the VMA lock was released, the replacement could go undetected, leading to incorrect folio handling and potential memory-safety issues (including triggering a BUG() via folio_add_new_anon_rmap or enabling unintended folio injection into the page cache). The fix introduces a new mfill_retry_state struct and helper functions (mfill_retry_state_save, mfill_retry_state_changed, mfill_retry_state_put), and uses DEFINE_FREE to manage cleanup. It saves relevant VMA state before releasing the lock, compares state after reacquiring the lock, and retries or aborts if a change is detected. This mitigates a race condition that could otherwise lead to memory safety vulnerabilities in userfaultfd managed memory operations.

The commit introduces a sanitization step for headers derived from plugin rule metadata (specifically X-Rule-* headers) and propagates origin information via an X-Rule-Origin header. Before this change, plugin-derived metadata could be used to construct HTTP headers that were forwarded to data sources without stripping control characters, potentially enabling header injection or information leakage. The patch adds sanitizeHeaderValue to remove ASCII control characters (including CR and LF) and truncate values to 128 bytes, and applies it when building datasource headers. It also augments the GetEvalCondition to include an Origin metadata key (as '<origin>|<uid>') when available, and updates allowlists so X-Rule-Origin is forwarded consistently across eval paths. Overall, this is a defensive fix to prevent header manipulation and limit header sizes, reducing the risk of header-based attacks and information exposure from plugin-originated metadata.

This commit fixes a credential disclosure risk in Grafana provisioning. Previously, when a provisioning git repository URL used http:// and a token was configured, the token could be sent in cleartext during Git operations because git.NewRepository would attach basic auth unconditionally for HTTP. The validators did not reject this combination. The change adds an allowInsecure flag and updates validation to reject http:// URLs when a token is configured, except when running in development mode (app_mode=development) or when provisioning.allow_insecure is explicitly enabled. It also normalizes the URL scheme to lowercase to catch cases like HTTP://. The behavior for https:// URLs remains unchanged, and http:// is still allowed without a token. This reduces the risk of token leakage over non-TLS transport during provisioning.

The commit implements explicit recursion depth limits when computing dashboard summaries to prevent denial-of-service via crafted dashboards with deeply nested specs/panels. It introduces maxSpecDepth and maxPanelDepth, guards recursive reads for spec and panels, and logs when limits are hit. Tests were added to verify recursion bounds. This changes the parsing/processing code path that could previously recurse without bounds, thereby enabling resource exhaustion under crafted input.

The commit fixes an input validation/authorization edge-case by increasing the maximum length for role identifiers (role UID and role name) and expanding the storage column for role.uid from 40 to 253 characters. Previously, long role UIDs could be truncated by the storage layer (e.g., MySQL) or by API boundaries, potentially causing mismatches in access-control decisions and allowing misauthorization. The changes unify and enforce a clear maximum length (253) to prevent silent truncation and ensure proper validation before authorization checks.

The commit fixes a potential use-after-free race in l2tp_session_get_by_ifname. Previously, the function took a reference to a session by calling refcount_inc() after matching the session by its ifname. Between the string comparison (strcmp) and the refcount_inc(), another CPU could drop the session's refcount to zero and free the object, yet the reader would continue using the stale pointer. This could result in use-after-free when the caller dereferenced the returned session. The fix switches to refcount_inc_not_zero() and, if the increment cannot be performed (i.e., refcount is zero), it continues walking the list instead of returning a possibly freed object. This brings the ifname getter in line with the other session getters in the file that already use refcount_inc_not_zero().

The commit adds a per-skb tc_depth field (2 bits) and uses it to bound and detect recursion/duplicate processing in mirred and netem paths. Before this change, crafted traffic containing mirred/netem redirects could loop across devices or back through the backlog, leading to infinite processing, excessive CPU usage, or kernel instability (a Denial of Service). The patch stops duplicate recursion using tc_depth (with a limit MIRRED_DEFER_LIMIT = 3) and increments tc_depth along redirected paths, effectively capping the recursion depth and dropping packets that would cause loops. It also adjusts netem duplication logic to depend on tc_depth and removes a stricter check that prevented certain legitimate multi-netem configurations. Overall, this is a real vulnerability fix for a DoS via packet loops/recursion in netem/mirred.

Security fix verified. The commit adds per-request authorization filtering when retrieving datasources by type, ensuring that only datasources the caller has read access to are returned. This mitigates an information disclosure/authorization bypass path where unauthorized users could learn about datasources they should not see. The patch implements filtering in GetDataSourcesByType by enumerating the results and validating each datasource against the caller's read permissions. It also highlights a potential risky code path in ListConnections where a plugin-type query could bypass service-level authorization if not carefully wired, which the tests exercise to confirm proper behavior. Overall, this is a genuine vulnerability fix for information disclosure via datasource-type queries.

The commit fixes an authorization mapping issue around legacy role-management permissions (roles:read, roles:write, roles:delete) by introducing explicit reconciliation logic for these permissions into Zanzana tuples. It adds dedicated translation paths (RoleManagementToTuples) and safeguards to drop scoped role-management permissions that cannot be safely expressed (e.g., per-role scoped permissions). The changes also include tests that verify the exact tuple mappings for legacy permissions (get on roles and globalroles for read; edit on roles for write; delete on roles for delete) and ensure that unsafe/scoped permutations are omitted. This reduces the risk of privilege misconfigurations or unintended escalation due to improper translation of legacy RBAC permissions into the Zanzana access-control model.

Summary: The commit adds validation of the request key across all resource server endpoints in the unified-storage component. Prior to this change, a misconfigured client sending a nil request key could trigger an unvalidated code path in the storage-api server, potentially causing a crash (Denial of Service). The patch introduces verifyRequestKey and verifyRequestKeyCollection checks in Create, Update, Delete, Read, List, and Watch handlers, and surfaces invalid input as gRPC InvalidArgument errors instead of panicking or crashing. This is a real security hardening aimed at preventing crash-induced DoS caused by nil/invalid request keys. The accompanying tests also assert that InvalidArgument is returned for invalid keys. Impact: - Vulnerability type: Denial of Service (crash) via nil/invalid request key in resource API - Affected: Grafana Grafana 12.4.0 and earlier (the fix targets 12.4.0 and prior releases) - Fixed by: Input validation on request keys across resource server endpoints, replacing potential panics with structured errors. Rationale: - The storage server previously could crash if a nil or improperly formed request key was processed without validation. By validating at entry points for all relevant RPCs, the server avoids dereferencing nil pointers or entering invalid code paths. The change also standardizes error handling to return InvalidArgument rather than a crash, reducing the attack surface for DoS via malformed requests.

The commit adds panic recovery interceptors for the gRPC server to catch panics in unary and streaming RPC handlers, log a stack trace, and return a generic Internal error to clients instead of crashing the process. This mitigates a recovery-related crash/DoS vulnerability and reduces potential information leakage by ensuring panics are contained within the RPC handling path. The change wires the new interceptors into the server and also applies them to in-process channels used by some internal clients, with unit tests validating both unary and streaming panic handling.

The commit adds defense-in-depth authorization checks on internal delegated RPCs of the unified-storage resource server (PutBlob, GetBlob, ListManagedObjects, CountManagedObjects, RebuildIndexes). Previously, these internal RPCs could be invoked without validating the originating user's identity or namespace alignment, enabling potential cross-tenant access or information disclosure if the gRPC surface was reachable without the calling service in the request path. The fix introduces a requireUserNamespace gate and enforces resource-level access checks before performing actions, ensuring only properly authenticated/authorized users in the correct namespace can access or modify resources.

Summary of fix: - Introduced centralized git ref validation in apps/provisioning/pkg/repository/git with IsValidRef and commitHashRegex. An empty ref is allowed (defaulted to configured branch); a non-empty ref must be either a valid git branch name or a 7–40 character hex commit SHA. - Added ErrInvalidRef in the repository package to represent invalid refs. - Enforced validation at HTTP boundaries for provisioning endpoints: files and history connectors now reject unvalidated refs before reaching backends (local/git/github). - Updated tests to cover IsValidRef, RefValidation at files parsing, and history boundary checks. What vulnerability was fixed: Before this change, the provisioning API could forward an unvalidated ref value to backends (local, git, GitHub). This opened potential attack surfaces around input validation, including path/ref manipulation or injection risks when refs were concatenated into backend commands or data fetches. The commit explicitly moves ref validation to the HTTP boundary and centralizes ref validation logic, reducing the likelihood of unsafe input propagating to lower layers. Vulnerability type: Input Validation / Boundary validation for git refs (branch names and commit SHAs). Impact pathway: Unvalidated ref values could be forwarded to provisioning backends, enabling injection/manipulation of how refs are resolved by downstream systems.

The commit adds a destination-folder permission check to PatchLibraryElement to prevent an authorization bypass where an editor of a library element could relocate it into a folder they cannot access or write to. Previously, the route-level guard only verified library.panels:write on the element itself, which could allow moving the element to a folder without validating the caller's permissions on that destination folder. The patch introduces a check that resolves the destination folder scope and requires library.panels:create permission on that folder (with a fallback to the general folder if the destination UID is empty). This is complemented by a unit/integration test that exercises the scenario where a user has edit rights on the element but only read/view rights on the target folder, ensuring relocation is blocked. This constitutes a real vulnerability fix for authorization bypass/privilege escalation related to library element relocation across folders.

Root cause: When updating a provisioning repository, if the repository URL changes and a new token is not supplied, the code could copy the existing secure token from the old repository to the new one and allow access to the new URL with the old token. This enables credential reuse across a URL change and could lead to unauthorized access to the newly pointed repository. What changed: The patch adds a guard RequiresNewTokenForURLChange that detects a URL change between old and new repository objects and requires a new token to be provided. If no new token is present, the update is rejected with an error indicating that a new token is required when changing the repository URL. This check is wired into the admission validator and complemented by tests verifying the behavior. Impacted area: repository provisioning (authentication/authorization path for Git sources).

Root cause: Prior to this patch, when updating an existing resource, the authorization check used the folder where the resource currently exists (source) and did not consistently validate the destination folder when the resource was moved across folders. This allowed a user with write access to the source folder to move a resource into a destination folder they could not access. The commit changes the authorization flow to: (1) derive the destination folder from the file path (not from user-supplied JSON), (2) for moves across folders, check permissions on both the source and the destination folders, ensuring the user has the required verb on both. As a result, cross-folder moves are blocked unless the user has access to both folders. This fixes a potential authorization bypass in provisioning resource moves. Vulnerability type: Access Control / Authorization Bypass via folder moves Affected behavior: Moving a resource from a permitted folder to a restricted folder could succeed under older logic; now moves require permissions on both source and destination.

The commit fixes an authorization bypass in no-op updates. Previously, when a client sent an update whose payload was identical to the latest stored value, the storage/update path could bypass RBAC checks, potentially allowing a caller with insufficient permissions to trigger a write without proper authorization. The patch adds a server-side guard for no-op updates: if the incoming value equals the latest value, the server now performs an RBAC check (VerbUpdate) for the target resource before returning. If allowed, it returns the current resource version without mutating data; if not allowed, it returns Forbidden. This enforces access control consistently even when no actual data changes occur, mitigating privilege escalation risk in no-op update scenarios.

RBAC enforcement for the iam.grafana.app/users resource in the unified storage search path was missing, allowing potential authorization bypass via /api/users/search. The commit enforces RBAC by extending the access control allowlist to include iam.grafana.app: { users: nil } and adds tests that verify correct authorization behavior for global admin, org editor, and scoped user scenarios. This addresses an authorization bypass risk where users could enumerate other users through the unified storage search filter.

The commit implements a server-side access-control fix for the folder hierarchy by introducing an AccessControl map and a batch RBAC-based permission calculation that resolves inherited permissions from parent folders. It adds a per-user permission tier (viewer/editor/admin) and derives an explicit AccessControl map reflecting only the actions granted to the user, intended to mitigate authorization bypass or leakage due to mis-handled inherited permissions. Additionally, it exposes this AccessControl field via the API (FolderAccessInfo.AccessControl) and updates the OpenAPI schemas to document it. The change also includes unit tests that validate the new access calculation logic. The problem this fixes is an authorization weakness where inherited permissions and per-folder access could be inconsistently computed or exposed, potentially allowing leakage or mis-privileged actions if parent-chain inheritance was not properly accounted in the previous flow. The patch moves authorization checks to a batch RBAC path, derives a consistent tier, and returns a restricted AccessControl map mirroring the user’s granted actions.

This commit implements frontend URL sanitization and encoding to fix potential XSS and URL injection in provisioning UI. It introduces safe rendering for profile URLs, encodes usernames for profile links, and sanitizes all externally provided URLs used in provisioning components (PullRequestButtons, RepositoryActions, RepositoryOverview, ResourceTreeView, and HistoryView). Specifically, it adds getAuthorProfileUrl with encodeURIComponent, uses textUtil.sanitizeUrl on server-provided URLs (newPullRequestURL, compareURL, sourceURL, webhook URLs, and constructed repo links), and switches author rendering to a safe link path (TextLink) when a profile URL is present. It also adds tests to verify sanitization of javascript: URLs and proper encoding. Overall, this addresses input validation and potential XSS/URL-injection vectors via crafted URLs or usernames in the provisioning frontend.

The commit fixes a latent memory-safety vulnerability in Turbopack's ReadRef<T> IntoIterator implementation. Previously, the IntoIterator path was implemented by fabricating &'static references via transmute (transmute_copy) to expose items through the standard Iterator trait. Those fabricated references were only valid while the ReadRef lived; once the backing storage could be evicted, dropped, or moved (e.g., due to async work, futures, or caller-side drops), the lifetime constraint could be violated, leading to a use-after-free when iterated items were later dereferenced. The patch replaces the unsafe by-value iterator with a sound, clone-free variant (ReadRefIter) and adapts all call sites to avoid exposing &'static references. This eliminates the lifetime hoisting that previously allowed references to escape into futures, Vecs, or serialization code, thereby preventing potential memory corruption or panics (e.g., during JSON serialization as observed in the bug report).

The commit changes the unsafe-delete path for corrupt objects to ensure corruption is detected at the latest revision. Previously, there existed a path (IgnoreStoreReadError) that could skip transform/decode and allow deletion of a corrupt object without performing full validation, potentially bypassing admission checks and finalizers. The new implementation (ExpectTransformOrDecodeError) always attempts to transform/decode and only proceeds with delete if that attempt fails; if the object turns out to be decodable after all, the delete is rejected with an InvalidObj error. This mitigates a security edge case that could have allowed tampering or bypass of security controls via corrupt object deletion.

The commit fixes a vulnerability where resources could leak or inherit sensitive system metadata when created via update (create-via-update) or create via apply. Specifically, during update-based creation paths, the API server could carry over or reflect system fields such as UID, CreationTimestamp, SelfLink, DeletionTimestamp, and DeletionGracePeriodSeconds from the input ObjectMeta, or from an existing resource, into the newly created object. The patch wipes these system fields before finalizing the creation, ensuring that new objects receive fresh identity information and do not disclose potentially sensitive metadata from an existing resource or from the payload. The accompanying test suite asserts that after creation via POST, PUT (create-via-update), and SSA apply, these fields are cleared, and new governance metadata is assigned by the server.

The commit adds per-item maxBytes validation for device attribute strings in ResourceSlice validation. Specifically, each string value in a DeviceAttribute.StringValues list is now validated against a per-item maximum length (DeviceAttributeMaxValueLength, 64 bytes). The validation results are annotated with origin 'maxBytes' and marked as covered by declarative validation. This hardens input validation to prevent potential resource exhaustion or abuse from excessively long string values in device attributes. Tests have been updated to enforce the boundary behavior and to reflect the maxBytes constraint.

The commit adds per-item maxBytes validation for DeviceAttribute.StringValues and annotates errors with origin 'maxBytes'. This enforces a maximum length for each string value in resource attributes to prevent resource exhaustion or validation bypass caused by oversized inputs. Tests were updated to cover boundary conditions. This constitutes a genuine security fix for DoS/Resource exhaustion via oversized input in resource validation.

This commit adds explicit HTTP method restrictions on kubelet endpoints to harden access control for read-only paths. Specifically: - kubelet_server_journal.go now rejects methods other than GET and POST for journal-related queries, returning 405 Method Not Allowed and an Allow header listing GET and POST. - Additional read-only endpoints registered via the RESTful server are wrapped with a GET-only filter (GETOnlyRestfulFilter) so that only GET requests are processed; non-GET requests receive 405 with an Allow header indicating the permitted methods. The change reduces the attack surface by preventing abuse of unsupported HTTP methods (e.g., PUT, DELETE, PATCH) against kubelet read endpoints that could otherwise trigger unintended behavior or side effects. Tests were added to verify the method-gating behavior for journal endpoints and other read-only endpoints. Overall this is a security hardening fix rather than a dependency or cleanup only change.

The commit adds explicit IP validation for the IP address used by the apiserver endpoint reconciler. It introduces a ValidateIP(ip net.IP) error method on endpoint reconcilers and calls this validation during CompletedConfig.New to ensure that the public address (advertise-address) is valid for endpoint reconciliation. This prevents invalid or misconfigured IPs from being embedded into the endpoints managed by the reconciler, addressing a robustness/input-validation weakness that could lead to misrouting, service disruption, or potential information disclosure when endpoints contain unusable or non-routable addresses. The change also adds a safety net in test setup to disable endpoint reconciliation for loopback/external addresses unless explicitly overridden, further hardening configuration paths. In short: before this patch, misconfigured advertise-addresses could propagate into Endpoints, enabling disruption or misrouting; after the patch, invalid IPs are rejected at startup via IP validation.

The commit fixes an authorization graph update path in the Kubernetes node authorizer graph populator. Previously, when a Pod’s NodeName and UID were preserved, there were rare cases where ExtendedResourceClaimStatus (the synthesized resource claims for extended resources) could change after a pod was bound, but the fast-path in updatePod would incorrectly skip rebuilding the authorization graph if PodStatusResourceClaimStatuses remained unchanged. This could leave the authorization graph stale, causing incorrect access decisions for nodes attempting to read synthesized ResourceClaims. The patch adds a check to also compare the PodExtendedResourceClaimStatus (ExtendedResourceClaimStatus) and updates tests to cover the scenario where ExtendedResourceClaimStatus changes to reflect newly synthesized claims. As such, it prevents an authorization edge from being omitted and ensures proper access control for synthesized resource claims.

The commit fixes a real vulnerability where ephemeral-storage eviction logic did not account for restartable init containers (sidecars) in InitContainers. Previously, only certain per-container thresholds were checked, allowing a restartable init container to exceed its ephemeral-storage limit without triggering eviction, risking resource exhaustion/DoS on the node. The patch enumerates restartable init containers and adds their ephemeral-storage limits to the eviction threshold map so the existing per-container comparison can enforce the limit on these containers as well.

The commit fixes an authorization bypass in the initial-events backfill path for the Watch RPC in Unified Storage. Prior to the fix, when a client subscribed to Watch with SendInitialEvents=true, the backfill emitted every item from the backend without consulting the per-item authorization checker. This allowed an attacker with restricted permissions to enumerate or infer the existence of items they should not have access to, via the initial events stream. The patch applies the same ItemChecker used for streamed events to the initial backfill during ListIterator processing, ensuring backfilled items respect per-item permissions. The change also includes tests (e.g., TestWatchInitialEventsRespectsItemChecker) to validate that backfill respects the item checker.

This commit bundle hardens several DRM memory-management and buffer-export paths, addressing use-after-free (UAF) and memory-safety issues observed in previous code paths. Key changes include: 1) AMDXDNA: prevent exporting private buffers via DMA-Buf by adding a private_buffer flag and returning -EOPNOTSUPP if an export is attempted on such buffers, reducing the risk of leaking internal buffers or lifetimes. 2) DRM GEM LRU/locking refactor: replace per-LRU locks with a device-wide gem_lru_mutex to guard LRU manipulations, reducing races that could lead to use-after-free or premature object reuse. 3) V3D: fix UAF in error-code paths and ensure proper GEM object reference handling on error. 4) Misc driver hardening and cleanup (bridge reset GPIO handling, IRQ cleanup paths, etc.). Overall, the fixes target use-after-free and memory-safety vulnerabilities in the DRM/GEM stack rather than a simple dependency bump or test-only change.

The commit fixes a real TOCTOU race and MAC address validation flaw in the ENETC PF/ VF mailbox path. Previously, enetc_msg_pf_set_vf_primary_mac_addr() read the VF-provided MAC directly from the DMA buffer, validated it, and then re-read the same DMA buffer to program hardware. Between validation and programming, a malicious VF could overwrite the DMA buffer, bypassing validation and causing the PF to program an arbitrary MAC (multicast, broadcast, or all-zero), enabling MAC spoofing. The patch introduces two mitigations: - It snapshots the message content into a private kernel buffer (via kzalloc and memcpy) before processing, eliminating the TOCTOU window. - It validates the MAC address with is_valid_ether_addr() on the snapshot and rejects invalid addresses, preventing spoofing vectors like all-zero or multicast MACs. These changes apply to the ENETC PF MAC-set path and address the specific TOCTOU race reported by Sashiko. The fix thus hardens VF-to-PF MAC configuration against spoofing and race conditions.

The commit fixes an information disclosure vulnerability in ADM1266 GPIO accessors under hwmon/pmbus. Previously adm1266_gpio_get() and adm1266_gpio_get_multiple() performed a 2-byte block read and combined read_buf[0] and read_buf[1] without ensuring two bytes were actually returned. If the I2C device returned 0 or 1 bytes (short block-read), read_buf[1] could be uninitialized stack memory, and the resulting pins_status/status value would leak kernel stack bits to userspace via gpiolib (sysfs or ioctls). The patch adds a check for ret < 2 and returns -EIO, preventing use of potentially garbage data and eliminating the leak.

The commit targets a use-after-free in the TLS over sockmap verdict receive path. Specifically, when a receiver socket is inserted into a sockmap with a BPF_SK_SKB_VERDICT program and TLS RX is configured after insertion, sk_psock_verdict_data_ready() could call tcp_read_skb() and drain the receive queue without advancing copied_seq. This could leave tls_decrypt_sg() walking a dangling frag_list, resulting in a use-after-free. The regression test added in this commit exercises the full vulnerable sequence and asserts that after the fix, data is decrypted correctly. The fix introduces a guard (tls_sw_has_ctx_rx) to sk_psock_verdict_data_ready(), mirroring the existing behavior for the non-verdict path, so that when a TLS RX context is present, the code defers to the saved_data_ready path (sock_def_readable) instead of draining the queue directly. This prevents the UAF and ensures correct TLS data processing.

The commit fixes a race in the net_shaper data path where a reader could observe a valid entry and then the entry could be replaced/freed by a writer, leading to a use-after-free (UAF). The previous implementation relied on XA marks (VALID) to gate access, but marks are not stored atomically with the entry, allowing a reader to continue using a pointer that has been replaced and potentially freed. The patch introduces an explicit valid field with acquire/release semantics, checks validity before dereferencing, and frees entries via kfree_rcu, thereby eliminating the race window and preventing UAF on readers.

The commit fixes a vulnerability where PUT /api/datasources/uid/:uid used the payload UID to identify the target datasource, enabling an attacker to update a different datasource by mismatching the UID in the URL and the payload. Before the fix, the handler constructed the target datasource from the payload UID (cmd.UID), allowing unauthorized cross-resource updates if the payload UID did not match the URL UID. The patch adds a validation that returns 400 when the payload UID (cmd.UID) is non-empty and does not equal the URL UID, and then uses the URL UID to fetch the datasource for the update. This enforces consistency between the URL and payload UIDs and prevents IDOR/parameter-tampering in this endpoint.

The commit adds enforcement to ensure vmselect/victoriametrics does not serve queries outside configured retention boundaries when the -denyQueriesOutsideRetention flag is enabled. Specifically, it introduces a storage-level checkTimeRange that validates a query's time range against both -retentionPeriod and -futureRetention, and wires this check into the query paths used by vmselect (e.g., SearchTSIDs and related metric/name searches). In addition, the HTTP error response for violations is changed from 503 to 400. Previously, some code paths did not uniformly enforce the future retention window and relied on limited checks, which could allow querying data outside retention boundaries. The patch thus closes that gap, reducing information-disclosure / access-control risks by preventing queries whose time ranges lie outside the allowed retention windows.

The commit fixes a memory-safety vulnerability in the APNG (animated PNG) decoder related to parsing fdAT chunks. Previously, the demux/decoder could underflow/overflow when handling malformed fdAT data because it unconditionally subtracted a 4-byte sequence number from the fdAT chunk data length, without verifying that the chunk contained at least 4 bytes. The patch adds explicit bounds checks for fdAT (kFrameDataSequenceNumberSize = 4) and for fcTL, and ensures the CRC/data handling logic operates only on valid ranges. As a result, malformed APNG data that would have caused a buffer overflow or memory corruption is now rejected gracefully (returning null or skipping invalid chunks) instead of corrupting memory. This addresses a potential memory-safety vulnerability in the APNG decoder.

The commit adds a targeted fix to Turbopack's subpath resolution for exports and imports. It introduces a distinction between Export and Import resolution paths (ExportImport enum) and enforces that exports subpath resolutions are treated as relative exports (prefixing with "./"), while imports may map to external packages. This prevents subpath entries in the exports map from resolving to external packages or unintended paths, addressing a class of mis-resolution vulnerabilities where an attacker could influence which module gets loaded via a subpath. The change aligns with Node.js exports/imports semantics where exports must be relative (starting with ./) and imports may reference external packages. Overall, this is a genuine security fix for improper package resolution and path traversal risk within turbopack.

The commit adds RegisterSecretFlag for several *headers flags in vmalert components (datasource.headers, notifier.headers, remoteRead.headers, remoteWrite.headers). This hardening prevents sensitive header values from being exposed in logs or outputs when flags are dumped or printed for debugging/config purposes. Prior to this change, header flag values could be disclosed if the application logged or displayed flag values during startup or error handling, representing an information-disclosure vulnerability.

The commit fixes a cross-parameter information disclosure in the segment cache that occurs when using prefetch={true} with cachedNavigations and pages with param fallback. Previously, a Full prefetch could cause the cache to be re-keyed using a potentially incomplete set of varyParams, potentially combining param-specific content into a single cache entry keyed by a vary path with Fallbacks. A subsequent lookup for a different param value could read content from this mixed cache entry, leaking information across param values. The fix pins the cache entry to its concrete vary path for Full fetches (i.e., skips re-keying when fetchStrategy === FetchStrategy.Full), aligning Full prefetch behavior with the non-Full (cachedNavigations-disabled) path where the server does not provide varyParams. This mitigates cross-param information disclosure. The change also adjusts test coverage to validate non-leaking behavior.

The commit aggregates Ceph client fixes that address memory-safety issues in kernel Ceph client code, including potential null pointer dereferences and out-of-bounds accesses. Specific fixes cover: null-checks and safer decoding paths in decode_choose_args (crush map), safer osdmap_decode paths, a guard in __ceph_x_decrypt to validate plaintext length, handling of NULL i_snap_realm in quota checks, adjustments to xattr preallocation logic to avoid blob size miscalculations, and general memory-management hardening in the crush/xattr/osdmap paths. Collectively, these changes reduce crash conditions and potential exploitation from malformed Ceph map/xattr data or edge cases in quota handling.

The commit is marked as addressing a TOCTOU (time-of-check-to-time-of-use) race condition in the dashboard/global template variables service, including guard changes for folder handling, access checks, and limiting mutations to Admins/Editors. The diffs show additions aimed at guarding access (guard folder handler, check for accessClient) and changes to how global variables are handled across v2beta1, plus tests around folder access. The presence of a specific TOCTOU fix in the changelog and the accompanying code changes (guarded access paths, permission checks around mutations, and tests) indicate this is a genuine vulnerability fix addressing a race condition rather than a mere dependency bump or non-security code cleanup.

The patch addresses an information-disclosure risk in ptrace access for tasks that have no associated memory management (mm == NULL), i.e., kernel threads. Previously, ptrace_may_access could grant access to such tasks more permissively, potentially leaking details about kernel threads and their memory-dumpability state to unprivileged or insufficiently privileged callers. The fix adds a new per-task flag (user_dumpable) to cache the last known dumpability and introduces task_still_dumpable() to decide if a task is still dumpable for ptrace checks. For tasks without an MM, access now requires either CAP_SYS_PTRACE (via the caller’s privileges) or the task having been dumpable in the past, preventing leakage of kernel-thread details in common scenarios. This aligns with the Qualys advisory and hardens ptrace-related information disclosure.

The commit fixes an off-by-one in how the sg_chain length is computed when a sk_msg scatterlist ring wraps (end < start) in TLS SK_MSG handling. Previously, the code used MAX_SKB_FRAGS - start + 1 as the chain length and started chaining from data[start], which could place the chain pointer at data[MAX_SKB_FRAGS] − effectively an off-by-one that risks reading/writing beyond the intended sg array during the wrap scenario. The patch converts to ARRAY_SIZE(msg_pl->sg.data) for the chain length and removes the start-offset, ensuring the entire sg.data array is considered when wrapping. This addresses a subtle memory-safety vulnerability in the wrap path for TLS SK_MSG, preventing potential out-of-bounds access and related memory corruption or disclosure via the chained scatterlist structure.

The commit fixes an authorization check bug in K8s Dashboards folder permission verification. Previously the code checked the folder access subresource and interpreted CanEdit (mapping to folders:write) as the gate for creating dashboards. This excluded users who only had dashboards:create permission on the folder but lacked folders:write, effectively denying legitimate dashboard creation for those RBAC configurations. The patch replaces the folder subresource check with a direct dashboards:create permission check scoped to the target folder via the accessClient.Check mechanism. This aligns permission semantics across enterprise custom RBAC and OSS resource permission levels and ensures that dashboard creation is allowed when dashboards:create is granted, even if folders:write is not.

This commit appears to fix a genuine use-after-free vulnerability concern. The race occurs when evicting a blocked client during an unblock and re-executing a pending command. Previously, the engine could access a client after it had been freed during processCommandAndResetClient. The fix guards against this by checking the return value of processCommandAndResetClient; if the client was freed, it exits the execution unit and returns early, preventing use-after-free in subsequent logic. The accompanying test case exercises eviction of a blocked client to ensure no use-after-free occurs during unblock.

Summary: - The commit fixes a use-after-free vulnerability in Redis replication when a full synchronization (FULLSYNC) happens while a timed-out script is still running on a replica. The scripting engine could be freed during FULLSYNC (due to emptyData/scriptingReset) while a script was still executing, leading to a use-after-free and potential memory corruption or crash. - The fix adds a guard at the start of readSyncBulkPayload to delay processing of the FULLSYNC payload if a long-running command (script) is yielding, ensuring the scripting engine is not freed while a script is still using it. - This is a real vulnerability fix (CVE-2026-23631). The change is not a mere dependency bump; it addresses a race between replication and the scripting engine. The repository shows the patch in replication.c and accompanying integration tests to validate the scenario. Impact: - Affected versions: Redis 8.6.x prior to 8.6.2 (i.e., versions that include the vulnerable behavior but not this fix). - Vulnerability type: Use-After-Free in the scripting engine during FULLSYNC on replicas. - Severity: HIGH (memory-safety issue with potential crash or memory corruption under exploitation conditions). - Affected scenario: A replica running a long-running or timed-out script experiences FULLSYNC, during which the scripting engine could be freed while still in use by the script. Root cause analysis: - FULLSYNC processing could free the functions engine (scripting engine) as part of the sync flow. If a long-running script was still executing, this could result in a use-after-free. - The fix ensures that readSyncBulkPayload returns early when inside a yielding long command, effectively delaying FULLSYNC processing until the script completes. Verification rationale: - The commit includes a guarded check in readSyncBulkPayload to skip processing when isInsideYieldingLongCommand() is true, preventing the premature freeing of the scripting engine during FULLSYNC. - The accompanying integration test extends replication scenarios to explicitly cover the case where a long-running script is present during fullsync, verifying that the replica remains responsive post-fullsync once the script ends. - The CVE identifier provided in the commit (CVE-2026-23631) aligns with a memory-safety use-after-free scenario.

This commit implements a real security fix for a Denial of Service (DoS) scenario caused by an infinite forward loop in server action handling when middleware rewrites a POST to a route that doesn’t bundle the action. The changes add: (1) a guard in action forwarding that prevents forwarding a request that already carried x-action-forwarded, avoiding repeated forwards across workers; (2) logic to propagate a not-found header and 404 response so the client gets a proper UnrecognizedActionError instead of a generic error. Together these prevent resource exhaustion (memory/time) from forwarding loops.

A double-free memory safety vulnerability exists during RDB/RESTORE loading of a stream when a consumer's Pending Entries List (PEL) contains a duplicate entry for the same pending ID. In the flawed path, if inserting into the consumer's PEL fails (due to a duplicate), the code would call streamFreeNACK(s, nack) even though the NACK is already owned by the group's PEL (cgroup->pel). This could lead to freeing the same object twice during stream/group teardown, causing a crash or memory corruption. The fix modifies the error path to stop freeing the NACK in this case and rely on decrRefCount(o) for cleanup, consistent with ownership where the NACK belongs to cgroup->pel. This eliminates the double-free scenario and resolves the vulnerability in affected versions.

This commit addresses a security vulnerability in Impeller's shader registry where user-supplied shaders (Flutter GPU user shaders, FragmentProgram/RuntimeEffect shaders, and Impeller's own shaders) were registered into a shared ShaderLibrary keyed only by (entrypoint name, stage). If a user shader exposed an entrypoint with the same name as an engine-internal entrypoint, a collision could occur, enabling eviction or shadowing of engine-internal pipelines via the hot-reload/dirty-stage path. The fix namespaces user shader entrypoints with a scope-prefixed name (MakeUserScopedName) and routes all RegisterFunction / UnregisterFunction / GetFunction calls through this scoped key. It also caches the scoped name per RuntimeEffectContents and ensures engine-internal entrypoints (which are compile-time constants) remain unscoped. Tests are added for MakeUserScopedName and GetLibraryId to validate behavior. In short, this is a hardening against spoofing/collisions in the shader registry that could otherwise allow a user shader to evict or shadow engine internals.

The commit fixes the resolution of identity scopes for id-scoped mappers (e.g., users, teams, service accounts) by introducing a UIDScope(name) method on the Mapper and using UIDScope(name) when translating scopes for write operations. Previously, resolveScope could pass an id-scoped form (serviceaccounts:id:<uid>) into ResolveUIDScopeForWrite, which is fragile and may mis-resolve the identity scope, potentially causing incorrect permission assignments. The patch ensures that id-scoped resources are consistently translated to the UID-based scope (serviceaccounts:uid:<uid>) for the identity store lookup, preventing mis-granting or mis-application of permissions. Additional tests for service accounts were added to validate the authorization behavior.

The commit adds strict validation to admission handling of ResourcePermission objects. Previously the code only checked that the group/resource was registered and enabled, and for duplicates, but did not validate that the requested permission Kind and Verb were actually allowed for the target resource. The fix introduces: - Retrieval and verification of a mapper for the target group/resource and guards against missing mapper after the IsEnabled check. - Per-permission validation that the Kind is allowed by the resource's mapper (AllowsKind) and that the Verb is valid (ActionSet returns no error). - Early rejection with clear BadRequest errors when Kind or Verb are not permitted or when a mapper is missing. This hardens admission validation against misconfigurations that could otherwise grant or imply permissions that are not enforceable by the resource’s mapper, reducing the risk of authorization bypass or privilege escalation via crafted ResourcePermission objects. Tests were added to cover these validation rules. In short: this is a real security fix for access control validation in the IAM/resourcepermission admission flow.

The commit implements a fix for an authorization boundary issue related to ServiceAccount resource permissions by (a) wiring a RestConfigProvider into the SA permissions flow and (b) preserving the user-visible UID across translation for authorization checks while using an internal numeric ID for RBAC decisions. Specifically, it translates the resource UID to an internal ID for permission checks, but preserves the original UID in the request (via :resourceUID) for the Kubernetes adapter, preventing UID↔ID mismatches that could lead to an authorization bypass. The change also injects the RestConfigProvider into the permissions wiring and propagates UID-preserving behavior through the API adapters and tests. In short: before this patch, RBAC checks could be performed against a possibly incorrect/internal ID without consistently preserving the UID context for the Kubernetes adapter, creating a potential bypass vector. The patch aligns UID handling with internal IDs to strengthen access control for ServiceAccount resources.

The commit fixes a DoS/memory-safety risk in Grafana's Data Source plugin proxy by capping the forwarded client User-Agent when forward_user_agent is enabled. Prior to this change, an attacker could supply a very long or unbounded User-Agent header, which would be appended to the proxy UA and forwarded downstream, potentially causing resource exhaustion or memory issues in the data proxy path. The patch introduces a 255-byte cap for the original client User-Agent and truncates any excess before forwarding. Tests were added to verify the truncation behavior.

Commit 583dec70ff3a56f9dc99d985a3aaf714bfd229f2 Harden dev tooling Bash scripts by quoting environment and URL variables used in redirections and condition checks. Prior to this fix, several scripts used unquoted variable expansions (e.g., log_file in dev/bots/codelabs_build_test.sh, STAGING_DIR in dev/bots/docs.sh, WRAPPER_TEMP_DIR and WRAPPER_SRC_URL in dev/tools/repackage_gradle_wrapper.sh). Unquoted expansions are vulnerable to word-splitting and, in certain contexts, command injection if an attacker can influence the variable values. The changes mitigate these risks by quoting variables and using safer path concatenation, reducing the risk of arbitrary command execution and potential log leakage in CI/developer tooling.

This commit fixes a DoS/Memory Exhaustion risk in Grafana's provisioning files API by introducing a configurable max_file_size limit and enforcing it at the repository boundary. Previously, large provisioning payloads could be read/parsed without a strict upper bound, potentially exhausting memory or CPU resources while handling file reads/writes. The change adds: (1) a default max_file_size (5 MiB) configurable via provisioning.max_file_size; (2) enforcement at the boundary for both reads and writes; (3) 413 (Request Entity Too Large) responses for oversized writes/reads; (4) tests validating under/over-limit behavior and unlimited (0 or negative) semantics. This significantly mitigates DoS risks from oversized provisioning payloads.

The commit adds validation in the WebDAV COPY/MOVE path handling to ensure that the source and destination do not refer to the same resource and that the destination is not a parent/ancestor of the source path. If a conflict is detected (same URI or a prefix relationship), the handler returns 403 Forbidden. This mitigates a vulnerability where mis-specified COPY/MOVE paths could corrupt or destroy files by overwriting or manipulating resources via path containment issues.

The commit fixes a race leading to a use-after-free between ublk_reset_ch_dev() and ublk_cancel_cmd() in the userspace block (ublk) subsystem. The root cause is concurrent access to io->cmd and io->flags: without proper synchronization, ublk_reset_ch_dev() can clear io->cmd via ublk_queue_reinit() while ublk_cancel_cmd() may concurrently read a stale pointer and pass it to io_uring_cmd_done(), causing use-after-free. The fix synchronizes the two paths by: - Reading and clearing io->cmd under cancel_lock in ublk_cancel_cmd(), saving the value to a local variable and calling io_uring_cmd_done() on that local copy outside the lock. - Holding cancel_lock while performing ublk_queue_reinit() in ublk_reset_ch_dev() so that io->cmd and io->flags are cleared atomically with respect to ublk_cancel_cmd(). This removes the window where a freed or stale pointer could be used when completing the IO command and closes a potential memory safety vulnerability in the IO cancel/reset path.

The commit fixes an Availability/Denial of Service vulnerability in Grafana's Unified Storage where the KV key regex did not allow ':' in the Name segment. Grafana's resource-name validation permits ':' (e.g., user-storage's '<service>:<userUID>'), but the unified storage KV layer previously rejected such keys, causing iterator scans to fail and potentially crash the resource server during startup/init. The patch expands the validKeyRegex to include ':' and adjusts tests to ensure colon-containing keys are preserved end-to-end, eliminating the crash risk.

The commit adds explicit repository-origin validation for GitHub webhook events in the provisioning subsystem. Previously, webhook events (e.g., push or pull_request) could be processed without verifying that the event's repository matched the configured Grafana provisioning repository (owner/repo). The fix introduces a repository mismatch check and returns a BadRequest with a repository mismatch error when the event's repository does not match the expected one. It also logs warnings when mismatches occur and propagates a dedicated ErrRepositoryMismatch error. This reduces the risk of unauthorized provisioning actions triggered by spoofed or misrouted webhook payloads.

The commit introduces a precedence rule for extra_label and extra_filters[] in GetExtraTagFilters: URL query parameters take precedence over POST form values. Prior to this change, the handler read values from r.Form (which combines URL query and POST data) without explicitly prioritizing URL parameters, creating a potential authorization bypass where a request could include conflicting values for extra_label/extra_filters[] in the POST body that override security-enforcing inputs. This could allow an attacker to influence tag-based filters used by vmauth or proxies, potentially bypassing policy restrictions. The fix makes the URL query values authoritative when both sources are present, thereby enforcing policies based on URL parameters and reducing the risk of bypass via crafted form data. The change is accompanied by tests that exercise requests containing both sources and verify that URL query values are used for extra_label and extra_filters[].

The commit adds an ImageDecodingManager to throttle HTMLImageElement.decode() calls and prevent resource exhaustion DoS scenarios in browsers (notably iOS Safari) when many large images are decoded. It introduces a multi-phase HtmlImageElementCodec that waits for a slot from the manager before decoding, enforces a limit on concurrent decodes and total bytes in flight, and performs aggressive resource reclamation by clearing img.src on disposal. This targets a stability/DoS risk rather than a traditional input-based vulnerability. The change also adds unit tests for the manager and integration tests for the codec. The reported vulnerability is a resource exhaustion/DoS risk that could be exploited by an attacker opening a page or app that triggers numerous large image decodes concurrently.

Summary of the vulnerability fix: - The commit addresses a denial-of-service-like crash caused by non-ASCII characters being written into the internal x-next-cache-tags HTTP header used by ISR caching. Node's header validation rejects non-printable ASCII outside the allowed range, so writing a tag containing non-ASCII data (e.g., emoji, CJK, Hebrew) could cause ERR_INVALID_CHAR and crash responses, disabling ISR cache refresh. - A canonical ASCII-safe form is now enforced at public boundaries by introducing an encodeCacheTag helper and applying it to all boundary inputs: tag construction (getImplicitTags, validateTags), invalidation inputs (revalidatePath, revalidateTag, updateTag), and fetch-related tag handling. The encoder encodes runs of non-ASCII characters using encodeURIComponent while remaining idempotent for already-encoded sequences. This ensures storage, comparison, and the wire all see the same ASCII-safe form and prevents invalid header values from being emitted. - The change propagates encoding through derived tags, user-supplied tags, and path-derived tags so the entire lifecycle (storage, invalidation, and wire) stays in sync. - Tests and end-to-end tests were added to validate non-ASCII handling (including surrogate-pair emojis) and to ensure headers remain within valid ASCII bounds. - This is a real security fix (not merely a dependency bump or cleanup) that mitigates a potential DoS/crash via invalid HTTP header values in ISR timing and cache invalidation paths.

The commit implements a substantive fix for XSS related to Content Security Policy (CSP) nonce handling and escaping in Next.js server-rendered content. It addresses (a) unsafe extraction of CSP nonces from headers, (b) unsafe embedding of nonces in inline scripts and server-inserted metadata, and (c) escaping of nonce values when emitted into HTML attributes. The changes include: tighter nonce parsing that ignores malformed nonces and validates allowed characters via a regex; escaping of nonce values when injected into script tags or metadata; wrapping JSON payloads with an HTML-safe escape function; and adding tests for malformed nonce handling and RSC-related headers. Collectively, this fixes a class of XSS vectors where an attacker could craft CSP headers or input data to inject or break out of inline scripts.

The commit fixes use-after-free / memory safety issues in the pmdomain (power management domains) subsystem: - genpd detach fix (drivers/pmdomain/core.c): When detaching devices, the code now distinguishes virtual devices created by genpd and disables runtime PM for them, and only unregisters devices that were created by genpd. This prevents premature frees or invalid dereferences during detachment of virtual devices, addressing a potential use-after-free during lifecycle handling of PM domains. - scpsys bus protection path fix (drivers/pmdomain/mediatek/mtk-pm-domains.c): In scpsys_get_bus_protection_legacy(), the patch introduces an explicit return path using a ret variable and ensures of_node_put(node) is released before returning on error. This prevents a use-after-free or use-after-release scenario stemming from improper resource/lifetimes management when looking up regmaps for legacy bus protection. Together these changes fix a memory-safety vulnerability in PM domain detach and legacy bus-protection lookup, reducing risk of use-after-free leading to crashes or potential privilege/escalation opportunities under certain device lifecycle sequences.

The patch fixes a use-after-free vulnerability in the udlfb driver by tracking mmap lifetimes of the framebuffer via vm_ops and an mmap_count on dlfb_data. Previously, dlfb_ops_mmap mapped vmalloc-backed pages without vm_ops and could free the backing pages while user-space mappings persisted, such as after a framebuffer resize via FBIOPUT_VSCREENINFO or USB disconnect. The fix adds vm_open/vm_close callbacks, assigns vm_ops to the VMA, and increments/decrements mmap_count accordingly. dlfb_realloc_framebuffer() now checks mmap_count and returns -EBUSY if mappings are active, preventing buffer replacement while stale user mappings exist. This removes the window for a use-after-free in the mapped framebuffer pages.

Security hardening: The change enforces immutability of alert provenance for existing rules during provisioning updates. If a stored provenance exists and a provisioning request attempts to change it, the API now returns a structured provenance mismatch error (using errProvenanceMismatch) with a 409 Conflict semantics. This prevents provenance metadata tampering and strengthens integrity/authentication guarantees around alert rule provisioning.

The commit implements a hardening of the Secrets GC workflow by introducing a maximum number of GC attempts for a secure value and deleting the value after exceeding that limit. This reduces the risk that secret material remains in storage due to repeated GC failures, addressing potential information disclosure risk from long-lived secrets. It also changes the data model (DeleteInput) and storage interface to support batch deletes and per-value GC attempt counters, and logs the deletions.

This commit introduces RBAC for the alertmanager imports feature and wires authorization checks into the convert API used for importing Alertmanager configurations. It defines four scoped actions under notifications.alerting.grafana.app for per-import control: alertmanagerimports:create, alertmanagerimports:get, alertmanagerimports:update, alertmanagerimports:delete. It adds per-identifier scoping support (ScopeAlertmanagerImportsProvider and ScopeAlertmanagerImportsAll), introduces an ExtraConfigAuthz interface enforced by the notifier, and wires authorization into Save/Apply and Delete operations. It also registers a dedicated admin role fixed:alerting.alertmanager-imports:writer (created when a feature flag is enabled) with all four actions scoped to all imports, and exposes this through the RBAC permission registry. The change mitigates an authorization bypass risk where mutating alertmanager imports could be performed using legacy permissions (e.g., notifications:write) without per-import scoping, by requiring explicit create permission for creation and enabling scoped checks for update/delete. However, update/delete still accept the legacy notifications:write path as a fallback, so full per-import isolation is not guaranteed unless the scoped actions or the new role are granted. Affected versions are Grafana 12.x up to and including 12.4.0 (before this fix).

The commit fixes an authorization bypass in the App Plugins proxy by introducing explicit per-route RBAC checks and a SignedInUser-aware request scope. Previously, plugin proxy requests could be processed without proper RBAC checks, potentially allowing unauthorized users to reach plugin routes or access protected resources. The patch enforces authorization via per-route requirements (ReqAction and ReqRole) using the access control subsystem (Evaluate with routeEval) and binds access decisions to an explicit signed-in user (SignedInUser) and request context. It also strengthens JSON error handling and includes a secure JSON decryption path for plugin configuration data. Together, these changes address authorization, information exposure, and data handling risks in the plugin proxy mechanism, representing a genuine security vulnerability fix rather than a pure refactor or test addition.

The commit fixes an authorization bypass/privilege escalation scenario in provisioning. Previously, GetRulesets would block a write workflow whenever a branch had any active pull_request rule, ignoring bypass information from parent rulesets. The fix fetches each unique parent ruleset and consults CurrentUserCanBypass to determine if the current actor is allowed to bypass. It treats only always and exempt as non-blocking; pull_request bypass is only allowed during PR merges. The change also uses fail-closed behavior when a parent fetch fails to avoid silently saving configurations that would fail at push time. Overall, this reduces the risk of privilege escalation or unauthorized configuration changes during repository provisioning.

The commit implements a real SSRF mitigation in the Next.js image optimizer by blocking fetchExternalImage requests that resolve to private IPs unless explicitly allowed via a dangerous flag (images.dangerouslyAllowLocalIP). It also refines the error message presented when a private IP resolution is detected and adds unit tests to guard this behavior. This is more than a documentation or test-only change; it changes runtime behavior to prevent SSRF via image URL fetching.

The commit implements a security fix for an authorization bypass related to mutating OwnerReferences on SecureValue resources. Prior to this change, non-AccessPolicy identities could mutate OwnerReferences during an Update, potentially allowing an attacker to reassign ownership metadata and bypass RBAC/ownership-based restrictions. The patch preserves existing OwnerReferences for non-AccessPolicy identities and permits mutation of OwnerReferences only for AccessPolicy identities, mitigating unauthorized ownership tampering. This addresses a class of authorization bypass risks where ownership metadata could be manipulated to gain or escalate access.

The patch fixes a memory-safety use-after-free in futex hash handling during process cloning. Previously, the kernel allocated a private default futex hash only when both CLONE_VM and CLONE_THREAD were set for the child (i.e., a thread-like clone). The patch relaxes this requirement to allocate the default futex hash for any CLONE_VM clone except vfork, by changing need_futex_hash_allocate_default() to return true when the clone_flags indicate a VM clone without VFORK. This prevents a scenario where mm->futex_ref is not allocated soon enough during certain forking/cloning paths, which could lead to use-after-free in futex_hash_put and related memory-safety issues (as reported by KASAN). The change targets the fork path in kernel/fork.c and ensures the default futex hash is allocated for more cloning scenarios, avoiding a potential memory-safety bug in futex hash handling when sharing a parent's mm.

The commit fixes a memory-safety issue in SPI-NOR printing of device flags via debugfs. Specifically, spi_nor_params_show previously passed an incorrect length to spi_nor_print_flags by using the size in bytes of the flags name array (sizeof(snor_f_names)) instead of the number of elements (ARRAY_SIZE(snor_f_names)). This can cause an out-of-bounds read when the nor->flags bitfield contains bits beyond the number of defined flag entries, leading to potential kernel memory read or instability. The patch also adds safe handling for packed ODTR (on-die transfer) reads and aligns related SPI-NAND/ODTR logic, but the explicit vulnerability fix is the corrected flag-printing length. This is a memory-safety vulnerability in the kernel's debugfs output path.

The commit delivers three independent hardening fixes in Grafana's unified search storage: 1) objectStorageLock heartbeat: The loss-detection window is reduced by declaring loss one heartbeat interval before TTL. This narrows the window where another replica could acquire the lock at the exact moment the lease expires, mitigating a potential race condition in distributed locking. The new calculation uses maxFailures = ttl/heartbeatInterval - 1. 2) BucketRemoteIndexStore.DownloadIndex: Each per-file download is capped at expectedSize + 1 bytes using a LimitedWriter. This prevents DoS scenarios where a misadvertised manifest size or a bucket object that has grown out of band would cause unbounded data transfer to disk. If the transfer would exceed the limit, an error is returned early. 3) validateManifestPaths: Relaxed handling for legitimate filenames that start with dots (e.g., ..foo/bar.zap) while still rejecting dangerous paths like .., ../escape, etc. This prevents valid paths from being rejected while preserving safety against path traversal. Triage results in the commit: vulnerability type is Denial of Service (resource exhaustion) and Race condition (distributed lock). Confidence is HIGH that these are security-hardening changes addressing real security risks rather than mere cleanup. The fixes apply to the affected code paths in 12.x releases and are intended to reduce exposure to lock contention, oversized data transfers, and unsafe path handling.

The commit adds an explicit ErrorRequestHeaders option to the Errors middleware (ErrorPage). By default, when ErrorRequestHeaders is nil, all the original request headers are forwarded to the error page backend. This creates an information disclosure surface where sensitive headers (e.g., Authorization, Cookie, etc.) could be leaked through error pages. The fix introduces a configurable allowlist (or empty list to forward no headers) to constrain which headers are sent to the error page backend, thereby reducing the risk of leaking sensitive header data in error responses. It also updates tests to cover the three modes: forward all headers (default), forward only allowlisted headers, and forward no headers.

The commit fixes an authorization misconfiguration in the provisioning files subresource. Previously, the files endpoint used a single static fallback role (admin) for all verbs, which could over-restrict reads or under-appropriate write permissions depending on the verb. This caused per-verb access checks to be incorrect, potentially exposing sensitive file contents or denying legitimate read/write operations. The fix introduces a verb-aware access checker that dispatches checks to a read or a write AccessChecker based on the HTTP verb, and wires it into the files connector, ensuring reads fall back to Viewer and writes to Editor instead of a blanket Admin fallback.

The commit improves input validation error handling for folder/dashboard validation by wrapping validation errors in APIStatus and returning 400 Bad Request instead of 500 Internal Server Error for invalid inputs (e.g., invalid UID, UID too long). It introduces API-wrapped errors (ErrAPIInvalidUID, ErrAPIUIDTooLong) that mirror legacy dashboard sentinels and propagates structured details (Details.UID) to downstream consumers. This reduces information leakage from unhandled 500 errors and ensures consistent, testable error responses for invalid inputs.

Open Redirect / Cross-origin Redirect vulnerability in login redirect handling. Prior to this fix, a redirectTo parameter could cause a logged-in user to be redirected to an attacker-controlled origin after authentication, enabling open redirect and potential token leakage or phishing. The commit adds strict origin validation for redirects, only allowing same-origin redirects or internal /goto/ navigation, and it uses URL parsing with a try-catch safeguard. It also ensures cross-origin redirects are not performed via the frontend navigation path and handles normalization/stripping of the redirect target for internal routing. This mitigates cross-origin redirection attacks following login.

Grafana 12.4.0 and earlier versions could disclose internal identity references in the Recently Deleted dashboards UI. Prior to this fix, the UI rendered raw identity UIDs (e.g.,

The commit enhances access control for SoC slider modparams used by x86_energy_perf_policy. Previously, the tool could read or write the slider_balance and slider_offset modparams (kernel sysfs entries under /sys/module/processor_thermal_soc_slider/) without verifying that the platform-profile was set to a compatible SoC profile (specifically a profile named "SoC Power Slider"). The patch adds gating logic to ensure these modparams are only accessible when the platform-profile is readable and the profile name matches POWER_SLIDER_NAME, and that the platform-profile and the slider modparams are accessible with the requested mode (read/write). This reduces the risk of unauthorized configuration changes via sysfs when the platform/driver is not in a state that supports or expects these adjustments (preventing potential privilege escalation or information disclosure through misconfigurations).

The commit fixes multiple error-path handling issues in the mana_probe()/mana_remove() code path of the Mana NIC driver. The main vulnerabilities addressed are memory-safety related: potential NULL pointer dereferences, use-after-free/warn_on in work structs, and resource leaks when probe steps fail or during PM resume/unbind sequences. Specific fixes include: initializing work structures before error paths that could trigger removal, guarding mana_remove() against NULL gdma_context/driver_data to prevent double invocations, avoiding overwrites of port probe errors via add_adev(), and ensuring EQ cleanup is always reached in port-loop cleanup. Collectively these changes reduce crash risk and kernel warnings, and reduce the likelihood of an attacker triggering kernel instability via malformed probe/remove paths.

The patch guards against a Denial of Service where a crafted, self-referential multisync extension could cause an infinite loop inside the V3D DRM driver. Previously, v3d_get_extensions() walked a user-supplied singly-linked list of ioctl extensions without a bound on the chain length. A user could construct an extension where ext->next == &ext and both in_sync_count and out_sync_count were zero. Because v3d_get_multisync_post_deps() returns immediately when the counts are zero, the loop could leave the extension state unchanged and repeat indefinitely, pegging a CPU core and blocking the calling thread. The fix adds a guard in v3d_get_multisync_submit_deps() to reject an empty multisync extension (both in_sync_count and out_sync_count zero) by returning -EINVAL, preventing the infinite loop. This is a defense-in-depth against a crafted user-space input leading to kernel DoS.

Mitigates a Spectre variant 1 style information disclosure in the LoongArch syscall dispatch path. Previously, the syscall number (nr) is used to index into sys_call_table directly after a bounds check; speculative execution could bypass the check and access beyond the end of the syscall table, leaking kernel data. The patch applies array_index_nospec(nr, NR_syscalls) to sanitize the index during speculative execution, preventing leakage.

The flaw occurs in net/smc/smc_clc_wait_msg where, during an early handshake, a CLC decline with FIRST_CONTACT could be processed without guaranteeing that a link-group context (smc->conn.lgr) exists. The existing code path could dereference smc->conn.lgr when it is NULL, causing a NULL pointer dereference (memory safety crash). The patch adds a guard to ensure smc->conn.lgr is non-NULL before touching lgr state (sync_err and termination), fixing the NULL pointer dereference vulnerability.

The commit fixes a memory-safety vulnerability in AppArmor path handling where a string buffer could overrun due to a missing string terminator when appending a trailing '/'. The underlying issue arose from replacing a deprecated strcpy without ensuring proper null termination, which could lead to a KASAN slab-out-of-bounds read/write in aa_dfa_match during path resolution (e.g., while mounting with AppArmor checks). The patch adds an explicit null terminator after inserting the trailing '/', ensuring the buffer remains properly terminated and preventing writes beyond the allocated 8KB slab. This directly mitigates the reported memory-safety bug observed in a KASAN trace and prevents potential memory corruption during path handling in AppArmor mounts.

The commit message and triage notes indicate a real memory-safety vulnerability fix: a Use-After-Free (UAF) in the debugfs teardown path of the EDT touchscreen driver (edt-ft5x06). The patch entry explicitly mentions "fix use-after-free in debugfs teardown" and shows accompanying driver cleanups (guard()/__free() usage) aimed at ensuring proper teardown and preventing dereferencing freed memory. While many changes are broader input subsystem updates, the security-relevant change is the UAF fix in the edt-ft5x06 debugfs teardown path. This is not merely a version bump or cleanup; it is a targeted memory-safety fix likely to prevent use-after-free exploitation when a debugfs-backed view interacts with a device being torn down or freed. The affected code path is the EDT touchscreen (edt-ft5x06) debugfs teardown, and the fix stabilizes the teardown sequence to avoid dereferencing freed objects.

ksmbd: race condition in ksmbd_conn_wait_idle_sess_id() where rcount is shared across iterations causing an iteration-order dependent threshold. The code previously set rcount to 2 for the current connection and 1 for others, but because rcount was kept as a single variable outside the loop, subsequent iterations could compare sibling connections against an outdated threshold. This created a race where destroy_previous_session() could proceed while there are in-flight operations on sibling connections sharing the same SMB session, potentially tearing down a session prematurely. The patch recomputes rcount per connection inside the loop (rcount = (conn == curr_conn) ? 2 : 1) so each connection is validated against its own threshold regardless of iteration order, closing the race window.

The commit includes concrete memory-safety and race-condition fixes in the F2FS filesystem to remediate use-after-free scenarios and related memory corruption risks. Notable changes include: (1) reordering and guarding end_io paths (e.g., f2fs_write_end_io, f2fs_compress_write_end_io) to ensure the F2FS SBIs are not accessed after they may be freed; (2) additional guards around node/ extents handling and the warm-node list; (3) avoidance of access to inline data or uninitialized values; (4) fixes to data loss scenarios caused by incorrect nat_entry flag usage; and (5) related sysfs/diagnostic improvements. Collectively these changes address memory-safety vulnerabilities (use-after-free) in F2FS I/O completion, races with GC and remount, and potential data corruption.

The commit fixes a potential NULL pointer dereference in the OS fingerprint TTL check path (nf_osf_ttl). Previously, the function dereferenced skb->dev to obtain an in_device and iterated local interface addresses via in_dev_for_each_ifa_rcu, which could dereference a NULL or invalid device pointer under certain skb conditions, potentially crashing the kernel. The patch removes the device dereference and the interface loop and replaces the TTL evaluation with a safer switch-based approach that does not rely on skb->dev, thereby mitigating the memory-safety vulnerability in the netfilter OS fingerprint path.

The commit introduces a gating mechanism to ensure a device is not probed until device_add() has finished its initialization by using a ready_to_probe flag. If a probe would occur before the device is ready, probe is deferred (EPROBE_DEFER). This directly addresses a race between device_add()/bus_add_device() and driver probing (via driver_register()/probe), reducing timing windows where a partially initialized device could be probed. Additional changes include: returning -ENOTCONN from software_node_get_reference_args() when a referenced software node exists but is not yet registered (allowing callers to defer probing), and ensuring sysfs group visibility respects both new and existing visibility helpers. A minor kernel-doc warning was fixed and a const-variant visibility path was added to sysfs ownership checks. Overall, these changes mitigate a class of security-relevant races, improve synchronization between device initialization and probing, and reduce exposure during partial initialization.

Root cause: In ice_set_ringparam(), the code nullifies the tstamp_ring of temporary tx_rings and then proceeds to call ice_setup_tx_ring(). If ICE_TX_RING_FLAGS_TXTIME is still set when ice_setup_tx_ring() fails, the unwinding path can trigger a NULL pointer dereference during cleanup: ice_clean_tx_ring() -> ice_is_txtime_cfg() == true -> ice_free_tx_tstamp_ring() -> ice_free_tstamp_ring() -> tstamp_ring->desc (NULL deref). Fix: The patch clears the ICE_TX_RING_FLAGS_TXTIME bit on the affected tx_rings before calling ice_setup_tx_ring(), preventing the unwinding path from attempting to free an absent timestamp ring and thus avoiding the NULL dereference. Impact: This is a memory safety issue in the kernel networking stack (Intel ICE driver). If triggered, it could crash the kernel (local DoS) rather than execute arbitrary code. The fix is a targeted control-flow safeguard in error handling."

This commit includes a targeted fix for a memory-safety issue in ext4 by correcting a bounds check in check_xattrs() to prevent out-of-bounds access when processing extended attributes. The vulnerability would occur in scenarios with corrupted filesystems or edge cases in xattr handling, potentially allowing out-of-bounds reads/writes in kernel memory before the fix.

The patch fixes a TOCTOU race in amdgpu_userq_input_va_validate where the kernel could validate a user-queue virtual address without the root bo reservation being held by the caller. Previously, validation could occur after releasing or without proper locking, enabling a race that could lead to use-after-free or unauthorized access to the root buffer object. The fix enforces that the caller holds the root.bo reservation during validation via dma_resv_assert_held and adjusts reservation handling in the create path to hold and release the reservation explicitly. In short: without this fix, a malicious user could race with the VA validation to abuse the user queue mapping, potentially causing memory corruption or escalation in a GPU context.

The commit aggregates multiple memory-safety fixes in the VFS/FS subsystem that address use-after-free (UAF) and NULL-pointer dereference conditions, notably: - eventpoll: fix UAF in ep_remove() path and related cleanup to avoid dereferencing freed file/epitem state when epoll file descriptors or items are torn down concurrently - fs/aio: prevent NULL-pointer dereference in mmap/remap paths by guarding aio context during remap and by applying VMA_DONTCOPY_BIT in mmap, reducing the window where a dead context could be dereferenced - fs-writeback: address use-after-free in inode_switch_wbs_work_fn via safer handling of switch_wbs_ctxs and reference management - fuse: reject oversized dirents in page cache to avoid cache-related memory corruption risks These changes collectively tighten memory-safety boundaries (UAF and NULL dereference) and reduce exploitation risk in concurrent filesystem/polling paths. They are proper vulnerability fixes rather than mere dependency bumps, code cleanups, or tests.

The commit fixes a memory-safety vulnerability in the slab allocator's reallocation paths (k(v)ealloc/krealloc). Previously, when reallocating a slab object, especially when shrinking the size or relocating to a different NUMA node, the code could copy orig_size bytes into a newly allocated buffer sized new_size. If new_size < orig_size, this could overflow the new buffer or corrupt adjacent memory, leading to data loss or a kernel crash. The patch applies min(new_size, orig_size) (and related changes) to ensure only the valid amount of data is copied, and preserves allocation behavior when moving to another node. This mitigates a potential buffer overflow and data-corruption pathway in kvrealloc/krealloc. Impact scope: memory safety in the slab allocator’s reallocation logic across NUMA boundaries or shrinking allocations. The fix is foundational and addresses a real vulnerability in the pre-fix code path.

The patch fixes a NULL pointer dereference in the Renesas RCAR-DU DRM driver by guarding accesses to rcrtc->cmm and its dev field. Previously, code paths dereferenced rcrtc->cmm->dev without ensuring rcrtc->cmm was non-NULL, which could crash the kernel if rcrtc->cmm was NULL. The fix adds an early check (if (!rcrtc->cmm) return;) and uses the pointer directly in subsequent calls (without dereferencing a NULL rcrtc->cmm->dev). This converts a potential NULL pointer dereference into a safe no-op when CMM is not present, mitigating a memory-safety crash path.