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)