Dashboard

The commit prevents a potential Denial of Service (memory/resource exhaustion) by capping the amount of the HTTP error response body read during prom.scrape non-200 responses. Previously, the code read the entire response body (io.ReadAll) for non-200 HTTP statuses, which could allow a malicious or misbehaving endpoint to exhaust memory (OOM) by returning a very large body. The fix introduces a limited reader (GetLimitedReader) with a maximum size (maxScrapeSize+1) and reads only up to that bound, mitigating unbounded reads and subsequent memory exhaustion. Impact: This changes the behavior of error-paths in lib/promscrape/client.go, ensuring that error bodies are not read in full when the endpoint is misbehaving or malicious. This is a genuine security improvement, not just a dependency bump or a cosmetic change.

This commit hardens AccessControl by introducing per-resource permission kind restrictions (AllowsKind) for ResourcePermission mappers and by explicitly constraining Service Accounts (SA) to not be granted BasicRole at the resource level. Previously, mappers could implicitly allow all permission kinds (nil allowedKinds) for resources like serviceaccounts, which could enable a per-resource BasicRole grant to an SA. The patch adds: (1) a configurable ScopeAttribute and Scope attribute constants to make scope handling explicit, (2) a shared mapper with an AllowsKind(...) method to restrict which permission kinds are allowed per resource, and (3) storage_backend.go wiring that, for serviceaccounts, uses an explicit allowedKinds list excluding BasicRole. This closes a potential authorization bypass where a user could grant a BasicRole to an SA on a specific resource, effectively escalating privileges at the resource level when BasicRole is globally derived for SA.

The commit adds fieldSelector handling for the preferences listing endpoint and enforces access checks to prevent information disclosure via list operations. Specifically: - Only a single fieldSelector on metadata.name is supported with the = operator. - Access control is applied based on the owner parsed from the name: namespace owner is always allowed; user owner is allowed only if the requester matches; team owner is allowed only if the requester is a member of that team. - Continue tokens and label selectors are rejected to prevent abuse. - If access is not permitted, the API returns an empty list instead of leaking data. This fixes a potential authorization/info-disclosure flaw where an authenticated user could enumerate or fetch preferences for other users/teams via the list endpoint using field selectors. The vulnerability type is Information Disclosure / Access Control (Authorization).

The commit bundles fixes for memory-safety vulnerabilities in the ksmbd SMB server (smbdirect path and related code). The primary issues addressed are memory-corruption risks such as use-after-free and double-free in the SMB Direct path (e.g., handling and ownership of request objects in smbdirect_send paths, and the flow where a request is moved to a batch and should not be freed), as well as a use-after-free in the close path for durable/async operations. Additional changes address a potential crypto-message use-after-free, a memory leak in session setup, validation improvements (EA name length), and safer handling of related FSCC structures to reduce the risk of out-of-bounds or invalid memory access. Overall, these changes are aimed at mitigating memory-safety defects that could lead to crashes or code execution, rather than pure functionality changes.

The commit set contains device-mapper and DM core fixes that include memory-safety improvements around dynamic allocations and ioctl handling (notably in dm-bufio.c and related dm-cache/metadata paths). The key change is replacing a potentially unsafe fixed-size allocation for a dynamically-sized structure with a safe flexible-allocation approach (kzalloc_flex) and related ioctl/error-path hardening. This points to a genuine memory-safety bug (buffer overflow risk) in ioctl/Data-structure handling within the device-mapper subsystem, rather than a pure dependency bump or cosmetic cleanup.

The patch fixes a memory-safety vulnerability by replacing an out-of-bounds read when computing the length to copy into task_struct->comm. Previously __set_task_comm used strlen(buf) to determine the length, which can read past a non-NUL-terminated user-provided buffer. The fix uses strnlen(buf, sizeof(tsk->comm) - 1) to cap the read to the destination buffer, preventing potential over-read and related memory-safety issues or information disclosure. This is a genuine safety improvement in the exec path that updates task names.

The commit fixes a race condition in regmap-debugfs dummy name allocation. Previously, regmap-debugfs used a static dummy_index for naming dummy entries, which could race when multiple regmaps create dummy debugfs entries concurrently, potentially leading to name collisions, incorrect mapping, or use-after-free scenarios during cleanup. The fix introduces per-instance ID allocation (via IDA) and per-map tracking (debugfs_dummy_id) with proper cleanup, eliminating the shared global naming race and ensuring each dummy debugfs entry has a unique, correctly freed name.

The commit bundle contains explicit security-related fixes: (1) bounds checking addition in d_mark_tmpfile_name to prevent a potential buffer overflow when constructing a temporary file name for dcache entries. It enforces that the new name length does not exceed DNAME_INLINE_LEN - 1 before performing the copy, reducing the risk of memory corruption in path handling for tmpfiles. (2) A compatibility/feature-related adjustment to support O_TMPFILE and related tmpfile naming, including new constants and small adjustments in cifs/smb client code to correctly handle temporary file creation and naming. The triaged note mentions fixing an out-of-bounds read in symlink response parsing and an EA bounds check; these changes correlate to input validation and memory-safety improvements in the SMB client and vfs path handling. Taken together, these are concrete security-oriented fixes rather than mere dependency bumps or cosmetic changes.

The commit contains a genuine security vulnerability fix in the HFS+ handling code of the Linux kernel. It addresses a memory-safety issue where syzbot observed an uninitialized value being read from on-disk HFS+ catalog records. The root cause is that the code path reading catalog records did not validate that the on-disk record size (the length field for a catalog entry) matches the expected size for the record type. The patch introduces hfsplus_brec_read_cat(), which validates the record size against the type and returns -EIO on mismatch, preventing potential reads of uninitialized kernel memory. Additionally, the commit includes related hardening such as detecting corrupted allocator state during hfs_btree_open() (mount read-only on corruption) and fixing error-path lock handling to avoid deadlocks. These changes reduce exposure to memory-safety issues and panics when processing corrupted HFS+ images. In short, this is a targeted memory-safety vulnerability fix in HFS+ catalog record parsing, not merely a dependency bump or a cosmetic code cleanup.

The ksmbd durable handle reconnect flow did not verify the reconnecting client's identity against the original opener. This allowed an authenticated user to hijack an orphaned durable handle by guessing or brute-forcing the persistent ID (DHnC). The patch adds a durable_owner to ksmbd_file to store the original opener's UID, GID, and account name, captures owner information when a file handle becomes orphaned, and introduces ksmbd_vfs_compare_durable_owner() to validate the reconnection identity during SMB2_CREATE (DHnC). This closes the gap where any authenticated user could reconnect to a durable handle opened by another user.

This commit fixes a real race condition in KVM's gmap/shadow paging code, addressing partial gmap invalidations particularly in the s390 KVM path and tightening the user-kernel API surface by replacing VLAs with FLEX_ARRAY. The core changes introduce an invalidated flag on gmap objects and adjust the shadow/invalidation logic to avoid races where a gmap could be observed in an inconsistent state during concurrent invalidation and shadow-paging operations. It also updates multiple UAPI structures to use the FLEX_ARRAY helper instead of VLAs, reducing risks from unbounded kernel/user-space structures. The combination of s390 race fixes and the UAPI cleanup constitutes a genuine vulnerability fix aimed at preventing race-induced memory safety/isolation issues in virtualization. Rationale: - The diff shows multiple guarded checks that previously relied on sg->parent to determine validity; these have been replaced with sg->invalidated in several hot paths, indicating a race-prone condition when a gmap is invalidated concurrently with shadow operations. - The gmap structure now carries an invalidated flag and the code marks gmaps as invalidated during certain transitions, which prevents unsafe pointer usage or premature re-use of shadow state. - UAPI structures are migrated from inline flexible arrays (VLAs) to __DECLARE_FLEX_ARRAY, eliminating VLAs in kernel-user interfaces and reducing attack surface from malformed or oversized user-space inputs. Affected behavior before fix: concurrent invalidation/updates of gmaps could race with shadow paging, potentially leading to use-after-free-like scenarios or memory isolation breaches in edge cases. Impact: The fix reduces the likelihood of memory-safety vulnerabilities in KVM where gmap invalidations race with shadow paging, improving guest memory isolation and stability.

This commit implements an information-disclosure hardening in the unified search API by filtering out the K6 technical folder for non-service accounts. Previously, regular users could observe internal K6 RBAC artifacts (the K6 folder) in search results, potentially leaking internal structure and permissions. The change adds a NotIn filter on the SEARCH_FIELD_NAME for the K6FolderUID when the requester is not a service account, and updates tests accordingly. This appears to be a genuine security vulnerability fix aimed at reducing unintended information disclosure via search results.

The commit implements an authorization fix for listing preferences. Prior to this change, non-user identities (e.g., AccessPolicy) could list all preferences by nulling the user, effectively bypassing access control and enabling information disclosure across users/teams within a namespace. The patch restricts listing to actual users and requires an explicit All flag to list all preferences. This prevents an authorization bypass that could reveal per-user/per-team preferences.

The commit adds a temporary authorization rule that explicitly denies watch operations on ResourcePermissions while allowing other operations. This blocks the watch exposure for ResourcePermissions, addressing an access-control weakness where watch streams could reveal permission-related data. It is a targeted code change (not a dependency bump) intended to fix an authorization bypass risk, by injecting a Deny path for the watch verb on ResourcePermissions at the API layer. The change relies on a storage-layer authorization for non-watch operations, with watch explicitly denied via a custom AuthorizerFunc.

The commit adds validation to reject wildcard '*' as the resource name in ResourcePermission objects used by Grafana's RBAC. This was enabling a potential authorization bypass/privilege escalation by creating or using a permission that targets all resources within a group (a wildcard). The changes enforce that resource permissions must target a specific resource and adjust related parsing/validation paths accordingly. Tests were added to ensure '*' is rejected, and an explicit error path was introduced for wildcard resource IDs. This indicates a real vulnerability fix rather than a mere dependency bump or cleanup.

Root cause: provisioning identity was derived from the resource object's namespace (f.Obj.GetNamespace()) in Run() and DryRun(), which could be empty or incorrect for resources created via provisioning. As a result, resources from one repository could be created or modified under an unintended namespace, leading to cross-namespace ownership conflicts and potential privilege escalation. The patch changes identity derivation to use the repository's namespace (f.Repo.Namespace) in Run(), DryRun(), and related code paths (e.g., dualwriter.go), ensuring resources are created within the repository's proper namespace and preserving isolation across repositories. Integration tests for cross-namespace isolation were added to validate correct behavior. This is a genuine security fix addressing authorization/ownership boundaries between repositories.

The commit fixes a memory-safety bug in the PN533 NFC UART driver receive path. Previously, pn532_receive_buf could consume input bytes and hand a complete frame to pn533_recv_frame() before ensuring a fresh receive skb was allocated. If a fresh skb allocation failed, the callback would return the number of bytes accepted as zero, leave recv_skb as NULL, and subsequent receive handling could dereference a NULL skb (via skb_put_u8()), leading to a kernel crash or instability. The fix allocates the receive skb lazily just before consuming the next byte and, on allocation failure, returns the number of bytes already accepted. This preserves receive accounting and avoids potential NULL dereferences. The change is a correctness bug fix with memory-safety implications in the kernel space.

The commit strengthens and clarifies RISCV indirect branch tracking (CFI) and shadow stack handling in the kernel. It unlocks per-task CFI/shadow stack state immediately after exec(), updates prctl()/ptrace interfaces to be more explicit, and renames/adjusts internal state fields for branch landing pads and shadow stacks. The changes address stale/incorrect locking behavior that could otherwise result in a misconfigured or stuck CFI/shadow stack state, which could be exploited to bypass control-flow integrity and potentially enable RCE via indirect branches. In short, this is a security hardening/fix rather than a mere cleanup or dependency bump.

The commit fixes a buffer overflow in the TH1520 AON RPC handling path (drivers/firmware/thead,th1520-aon.c). Previously, the code built the RPC message by using the RPC_SET_BE16 macro to write 16-bit values into the message at specific offsets, which could write beyond the intended bounds and corrupt memory. The patch replaces these writes with direct 16-bit fields (resource and mode) updated using cpu_to_be16, aligning the payload with the actual RPC structure and preventing out-of-bounds writes. This addresses a potential memory corruption vulnerability in the TH1520 AON firmware RPC path. The change also updates the endian handling macros in the header to standardize usage.

Memory-safety vulnerability in the IOMMU code: when unmapping, the iotlb_gather may appear empty and the code could elide the iotlb_sync() call, leading to stale TLB state and potential memory corruption, crashes, or hangs. The patch ensures iotlb_sync is invoked even if the gather is effectively empty by forcing a non-empty gather before sync.