From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E73B13D16FD; Mon, 30 Mar 2026 12:38:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774874335; cv=none; b=EJsQ3WlTbd/GkHw3WeQGLpCDKLsnwMQM4sBS1xPY5NsyIpmbVya5aSHD2zmx8aIyqQgIZDG31Euaq6o32HQ8gAq4pHxvsarGWDjh3B6SzPTYTLjB9/YYaxxIr385JOd6NBCGKHDw4o2SL+ueFTKXJ5szqfqfOngAeP0l2odFtwE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774874335; c=relaxed/simple; bh=oFLU5WAgDeApMYmpEY5B4JfKxFBn2/Lp+X+vKhq6MhM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=B8ovGEku5kpqj9Bs6lBSj5B4aICbM0d2DKWRQWLZAmZuw4tAE6wRECkubYGzWfsdRyKWs7T7xTL4F8JiB7YodyqyjqlpnD8pBkiXKpKScR2doC4eJALpnkWV+MX6TKqjITAHNruAs2WJyeBgDz1ya+pp7s6RUzeu5hjSDHAfsek= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DHOl/jRo; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DHOl/jRo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 80A73C2BCB3; Mon, 30 Mar 2026 12:38:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774874333; bh=oFLU5WAgDeApMYmpEY5B4JfKxFBn2/Lp+X+vKhq6MhM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DHOl/jRo9ovT5aR3mvlIal7S3w6wbRJKbTunTOnOdNue3pKse+ATw8Z5FWjeU2OGK FBUGj776V4BJ3cCU0AA4XkroyZxIpLkF++wiBWqMZEjj29Vk3oa52hZZKwTVEH1ObT Sj4WB+IDDl5Asnnp5zSLrILxK1WRDDM/y+TtNWMCGnlKd5VY3dKMPEMFgOQ4Aott0X YRi1K6jq44mSHRkRoXW26966AXSarGk+sXQ5NHomh/0enkOEL4z3TdG4A49PHATbBq Hzfg+aMWs9sm4EoY9DOQeHgWC0W8cRp5EyfVfXK6a0PotYMy6x/RYWZcFTWwjxC21K uVpUhSz5fgtYA== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Arnd Bergmann , Takashi Iwai , Sasha Levin , perex@perex.cz, tiwai@suse.com, linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH AUTOSEL 6.19-5.10] ALSA: asihpi: avoid write overflow check warning Date: Mon, 30 Mar 2026 08:38:20 -0400 Message-ID: <20260330123842.756154-7-sashal@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260330123842.756154-1-sashal@kernel.org> References: <20260330123842.756154-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.19.10 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Arnd Bergmann [ Upstream commit 591721223be9e28f83489a59289579493b8e3d83 ] clang-22 rightfully warns that the memcpy() in adapter_prepare() copies between different structures, crossing the boundary of nested structures inside it: In file included from sound/pci/asihpi/hpimsgx.c:13: In file included from include/linux/string.h:386: include/linux/fortify-string.h:569:4: error: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror,-Wattribute-warning] 569 | __write_overflow_field(p_size_field, size); The two structures seem to refer to the same layout, despite the separate definitions, so the code is in fact correct. Avoid the warning by copying the two inner structures separately. I see the same pattern happens in other functions in the same file, so there is a chance that this may come back in the future, but this instance is the only one that I saw in practice, hitting it multiple times per day in randconfig build. Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20260318124016.3488566-1-arnd@kernel.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: Now I have all the data I need. Let me compile the full analysis. =============================================================== PHASE 1: COMMIT MESSAGE FORENSICS =============================================================== **Step 1.1: Subject Line** Record: [ALSA: asihpi] [avoid] [write overflow check warning from clang-22 fortify-string in adapter_prepare()] **Step 1.2: Tags** - Signed-off-by: Arnd Bergmann (author) - Link: https://patch.msgid.link/20260318124016.3488566-1-arnd@kernel.org - Signed-off-by: Takashi Iwai (ALSA maintainer) - No Fixes: tag (expected for manual review candidates) - No Reported-by: tag - No Cc: stable tag - No Tested-by: or Reviewed-by: Record: Author is a highly trusted kernel contributor (Arnd Bergmann). Maintainer (Takashi Iwai) signed off. No external bug reports. **Step 1.3: Commit Body** The commit describes a clang-22 `__write_overflow_field` warning from `include/linux/fortify-string.h:569`. The `memcpy()` in `adapter_prepare()` copies between `struct hpi_response` and `struct hpi_adapter_response`, which are different structure types with equivalent layouts. The author explicitly states: "the code is in fact correct." The warning is hit "multiple times per day in randconfig build." The fix splits one `memcpy` into two field-level copies. Record: [Bug: build-time fortify warning, not a runtime defect] [Symptom: -Werror,-Wattribute-warning build failure with clang-22] [Root cause: FORTIFY_SOURCE cross-field memcpy detection on different struct types with equivalent layout] **Step 1.4: Hidden Bug Fix?** Record: Not a hidden bug fix. The author explicitly confirms the code is functionally correct. This is purely a compiler warning suppression. =============================================================== PHASE 2: DIFF ANALYSIS =============================================================== **Step 2.1: Inventory** Record: [sound/pci/asihpi/hpimsgx.c: -2/+4 lines, net +2] [Function: adapter_prepare()] [Scope: single-file, single-function, surgical] **Step 2.2: Code Flow Change** Before: One `memcpy(&rESP_HPI_ADAPTER_OPEN[adapter], &hr, sizeof(rESP_HPI_ADAPTER_OPEN[0]))` — copies the full struct from `hr` into the adapter open cache. After: Two memcpys: 1. `memcpy(&rESP_HPI_ADAPTER_OPEN[adapter].h, &hr, sizeof(...h))` — copies the response header 2. `memcpy(&rESP_HPI_ADAPTER_OPEN[adapter].a, &hr.u.ax.info, sizeof(...a))` — copies the adapter info payload This is on the normal initialization path after `HPI_ADAPTER_OPEN`. Record: [Before: single aggregate memcpy across struct boundaries → After: two targeted field-level memcpys copying identical data] **Step 2.3: Bug Mechanism** Verified struct layouts: - `struct hpi_response_header`: 12 bytes (u16 size + u8 type + u8 version + u16 object + u16 function + u16 error + u16 specific_error) - `struct hpi_response`: inline header fields matching `hpi_response_header` + `union { ... union hpi_adapterx_res ax; ... } u` at offset 12 - `struct hpi_adapter_response` (packed): `struct hpi_response_header h` (12 bytes) + `struct hpi_adapter_res a` - `union hpi_adapterx_res`: first member is `struct hpi_adapter_res info` The new code copies `sizeof(hpi_response_header)` bytes from `&hr` into `.h`, then `sizeof(hpi_adapter_res)` bytes from `&hr.u.ax.info` into `.a`. This is equivalent to the original single copy because the inline header fields in `hpi_response` are layout-compatible with `hpi_response_header`, and `hr.u.ax.info` is at offset 12 (same as `.a` in the packed struct). Record: [Category: build fix — compiler warning, not runtime bug] [Mechanism: split memcpy to satisfy FORTIFY_SOURCE field boundary checks while copying identical data] **Step 2.4: Fix Quality** Record: [Obviously correct — verified from struct layouts] [Minimal, surgical] [Zero regression risk — functionally identical copy] [No API changes] =============================================================== PHASE 3: GIT HISTORY INVESTIGATION =============================================================== **Step 3.1: Blame** Verified: `git blame -L 584,586` shows the memcpy was introduced in commit `719f82d3987aa` by Eliot Blennerhassett on 2010-04-21 ("ALSA: Add support of AudioScience ASI boards"). This code has been in the kernel since v2.6.35 — present in all active stable trees. Record: [Introduced: 719f82d3987aa, v2.6.35 era (2010)] [Present in all stable trees] **Step 3.2: Fixes Tag** Record: [N/A — no Fixes: tag present] **Step 3.3: File History** Verified: `git log --oneline -20 -- sound/pci/asihpi/hpimsgx.c` shows very low activity. The only functional fix since the original import was `7b986c7430a6b` ("Fix potential OOB array access"). Since v5.15, only 2 commits touched this file. Since v6.1, only 1. Record: [Very stable file, rarely changed] [No prerequisites or series] [Standalone patch] **Step 3.4: Author** Verified: Arnd Bergmann is a prolific kernel contributor who frequently submits compiler warning/build fixes across the tree. Not the asihpi subsystem maintainer, but a highly trusted contributor. Takashi Iwai (ALSA maintainer) applied the patch. Record: [Arnd Bergmann: trusted cross-tree contributor, specializes in build fixes] [Takashi Iwai: ALSA maintainer, accepted patch] **Step 3.5: Dependencies** Record: [No dependencies — self-contained single memcpy split] =============================================================== PHASE 4: MAILING LIST AND EXTERNAL RESEARCH =============================================================== **Step 4.1-4.4:** The lore.kernel.org and patch.msgid.link URLs are not accessible due to anti-bot (Anubis) protection. Record: [UNVERIFIED: lore discussion content, reviewer feedback, stable nominations, NAKs] =============================================================== PHASE 5: CODE SEMANTIC ANALYSIS =============================================================== **Step 5.1: Functions Modified** Record: [adapter_prepare()] **Step 5.2: Callers** Verified: `adapter_prepare()` is called from exactly one place — `HPIMSGX__init()` at line 719, invoked during `HPI_SUBSYS_CREATE_ADAPTER`. This is an adapter initialization path called once per adapter during probe. Record: [Single call site: HPIMSGX__init() → adapter_prepare()] [Called during adapter creation/probe, not a hot path] **Step 5.3-5.4: Callees and Reachability** The function calls `hpi_init_message_response()`, `hw_entry_point()`, and `memcpy()`. The call chain is: adapter probe → `hpi_send_recv_ex()` → `HPIMSGX__init()` → `adapter_prepare()`. This is reachable from the ioctl and kernel-side probe path for AudioScience ASI PCI sound cards. Record: [Probe/initialization path for niche PCI sound hardware] **Step 5.5: Similar Patterns** Verified: Similar `memcpy(&cache, &hr, sizeof(cache))` patterns exist for stream and mixer responses in the same file (lines 608, 621). The author notes these may trigger similar warnings in the future but currently only the adapter_prepare instance is hit. Record: [Similar patterns exist in same file for streams/mixer; only this one triggers with clang-22 currently] =============================================================== PHASE 6: STABLE TREE ANALYSIS =============================================================== **Step 6.1: Code in Stable Trees?** Verified: The original code was introduced in v2.6.35 (commit `719f82d3987aa`). Since v6.1, only 1 unrelated commit touched this file. Since v5.15, only 2. The exact buggy memcpy line exists identically in all active stable trees. Record: [Present in all stable trees: v5.15+, v6.1+, v6.6+] **Step 6.2: Backport Complications** Record: [Clean apply expected — file barely changed, tiny hunk with stable surrounding context] **Step 6.3: Related Fixes** Record: [No related fixes in stable for this warning] =============================================================== PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT =============================================================== **Step 7.1: Subsystem** Record: [sound/pci/asihpi — AudioScience ASI professional audio PCI boards] [Criticality: PERIPHERAL — niche hardware] **Step 7.2: Activity** Record: [Very low activity; mature, rarely touched driver] =============================================================== PHASE 8: IMPACT AND RISK ASSESSMENT =============================================================== **Step 8.1: Who Is Affected** Record: [Runtime: only users of AudioScience ASI PCI cards. Build: anyone building CONFIG_SND_ASIHPI (or allmodconfig/randconfig) with clang-22 and FORTIFY_SOURCE + -Werror] **Step 8.2: Trigger Conditions** Record: [Build-time only: clang-22 + CONFIG_FORTIFY_SOURCE + -Werror + CONFIG_SND_ASIHPI] [Not a runtime trigger] **Step 8.3: Failure Mode Severity** Record: [Failure mode: build failure/error] [Runtime severity: NONE — code is functionally correct] [Build severity: MEDIUM — blocks compilation under specific toolchain] **Step 8.4: Risk-Benefit Ratio** - Benefit: Keeps an existing stable driver buildable with newer compiler fortify diagnostics. The author reports hitting this "multiple times per day" in randconfig builds. - Risk: Extremely low — two memcpys copying the same data as one memcpy; functionally identical, verified from struct layouts. Record: [Benefit: LOW-MEDIUM (build fix for newer toolchains)] [Risk: VERY LOW (trivially correct, behavior-preserving)] [Ratio: favorable] =============================================================== PHASE 9: FINAL SYNTHESIS =============================================================== **Step 9.1: Evidence** FOR backporting: - Build fixes are explicitly listed as an allowed stable exception: "Fixes for compilation errors or warnings... These are critical for users who need to build the kernel" - Fix is tiny (+4/-2 lines), single-function, obviously correct - Verified struct layout compatibility confirms the change is behavior- preserving - Author (Arnd Bergmann) is highly trusted; maintainer (Takashi Iwai) signed off - Code exists in all stable trees and patch would apply cleanly - Stable trees are expected to remain buildable with current toolchains; clang versions age into wider use AGAINST backporting: - No runtime bug — the code is functionally correct without this patch - Niche driver (AudioScience ASI PCI cards) - Only triggers with clang-22, a very recent compiler - No user reports, no syzbot involvement - Impact scope is narrow (specific config + specific toolchain) UNRESOLVED: - Lore discussion content could not be verified (anti-bot protection) - Whether reviewers explicitly nominated this for stable **Step 9.2: Stable Rules Checklist** 1. Obviously correct and tested? **YES** — trivially correct from layout analysis; tested in randconfig 2. Fixes a real bug that affects users? **YES (build bug)** — prevents build failure with affected toolchain 3. Important issue? **MEDIUM** — build failure, not crash/corruption, but build fixes are an explicit exception 4. Small and contained? **YES** — 4 lines changed in 1 function 5. No new features or APIs? **YES** 6. Can apply to stable trees? **YES** — identical code in all stable trees **Step 9.3: Exception Categories** This falls under the **Build Fixes** exception: "Fixes for compilation errors or warnings, Kconfig dependency fixes, include file fixes — These are critical for users who need to build the kernel." **Step 9.4: Decision** This is a legitimate build fix under the stable exception rules. The patch is behavior-preserving (verified from struct layout analysis), trivially correct, and zero-risk. While the impact is narrow (clang-22 + niche driver), the stable tree policy explicitly allows build fixes because maintaining buildability with current and evolving toolchains is a core goal. Compiler versions age into wider use, and preventing build regressions on stable trees has standalone value. The near-zero regression risk further supports inclusion. **Verification:** - [Phase 1] Parsed all tags: Link, 2x Signed-off-by; no Fixes, Reported- by, Cc: stable - [Phase 2] Diff: single memcpy replaced by two field-level memcpys in adapter_prepare(); net +2 lines - [Phase 2] Struct layout verified: hpi_response_header (12 bytes inline), hpi_response has matching inline fields + union at offset 12, hpi_adapter_response is packed header.h + adapter_res.a — layouts confirmed compatible - [Phase 3] git blame: code introduced in 719f82d3987aa (2010, v2.6.35 era), present in all stable trees - [Phase 3] git log: file barely changed; only 1 commit since v6.1, 2 since v5.15; no series/dependencies - [Phase 3] Author verified: Arnd Bergmann, prolific build-fix contributor; Takashi Iwai (ALSA maintainer) applied - [Phase 4] UNVERIFIED: lore.kernel.org discussion blocked by anti-bot protection - [Phase 5] Callers traced: adapter_prepare() called only from HPIMSGX__init() (line 719), probe/init path - [Phase 5] Similar memcpy patterns exist at lines 608, 621 for streams; only adapter instance triggers currently - [Phase 6] Code exists identically in v5.15, v6.1, v6.6; clean apply expected - [Phase 7] Subsystem: sound/pci/asihpi — PERIPHERAL, low activity, mature driver - [Phase 8] Impact: build-time only, clang-22 + FORTIFY_SOURCE + -Werror; severity MEDIUM as build fix - [Phase 8] Risk: VERY LOW — functionally identical change, verified from struct layouts **YES** sound/pci/asihpi/hpimsgx.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/sound/pci/asihpi/hpimsgx.c b/sound/pci/asihpi/hpimsgx.c index b68e6bfbbfbab..ed1c7b7744361 100644 --- a/sound/pci/asihpi/hpimsgx.c +++ b/sound/pci/asihpi/hpimsgx.c @@ -581,8 +581,10 @@ static u16 adapter_prepare(u16 adapter) HPI_ADAPTER_OPEN); hm.adapter_index = adapter; hw_entry_point(&hm, &hr); - memcpy(&rESP_HPI_ADAPTER_OPEN[adapter], &hr, - sizeof(rESP_HPI_ADAPTER_OPEN[0])); + memcpy(&rESP_HPI_ADAPTER_OPEN[adapter].h, &hr, + sizeof(rESP_HPI_ADAPTER_OPEN[adapter].h)); + memcpy(&rESP_HPI_ADAPTER_OPEN[adapter].a, &hr.u.ax.info, + sizeof(rESP_HPI_ADAPTER_OPEN[adapter].a)); if (hr.error) return hr.error; -- 2.53.0