[PATCH AUTOSEL 6.19-5.10] ALSA: asihpi: avoid write overflow check warning

[Sasha Levin <sashal@kernel.org>]

From: Arnd Bergmann <arnd@arndb.de>

[ 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 <arnd@arndb.de>
Link: https://patch.msgid.link/20260318124016.3488566-1-arnd@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

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 <arnd@arndb.de> (author)
- Link:
  https://patch.msgid.link/20260318124016.3488566-1-arnd@kernel.org
- Signed-off-by: Takashi Iwai <tiwai@suse.de> (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