[PATCH AUTOSEL 6.17] ASoC: SDCA: bug fix while parsing mipi-sdca-control-cn-list

[PATCH AUTOSEL 6.17] ASoC: SDCA: bug fix while parsing mipi-sdca-control-cn-list

[Sasha Levin]

From: Niranjan H Y <niranjan.hy@ti.com>

[ Upstream commit eb2d6774cc0d9d6ab8f924825695a85c14b2e0c2 ]

"struct sdca_control" declares "values" field as integer array.
But the memory allocated to it is of char array. This causes
crash for sdca_parse_function API. This patch addresses the
issue by allocating correct data size.

Signed-off-by: Niranjan H Y <niranjan.hy@ti.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20251110152646.192-1-niranjan.hy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now let me do a comprehensive analysis of this commit.

## COMPREHENSIVE ANALYSIS

### 1. COMMIT MESSAGE ANALYSIS

**Subject:** ASoC: SDCA: bug fix while parsing mipi-sdca-control-cn-list

**Key Information:**
- **Problem:** The `values` field in `struct sdca_control` is declared
  as an integer array (`int *`), but memory allocated is for a char
  array
- **Impact:** "This causes crash for sdca_parse_function API"
- **Solution:** Allocate correct data size using `sizeof(int)`
- **Signals:** "bug fix", "crash" - STRONG YES signals
- **No tags:** No "Fixes:" tag, no "Cc: stable@vger.kernel.org" tag

### 2. DEEP CODE RESEARCH

#### A. Understanding How the Bug Was Introduced

The bug was introduced in commit **50a479527ef01f** by Charles Keepax on
**July 18, 2025**:
- Commit: "ASoC: SDCA: Add support for -cn- value properties"
- This commit added support for Control Number value properties in SDCA
  DisCo parsing
- First appeared in **v6.17-rc1**

The SDCA subsystem itself was added in **v6.13** (commit 3a513da1ae339,
Oct 16, 2024), so this bug does NOT affect older kernels.

#### B. Technical Analysis of the Bug

**The Structure:**

```759:776:include/sound/sdca_function.h
struct sdca_control {
        const char *label;
        int sel;

        int nbits;
        int *values;
        u64 cn_list;
        int interrupt_position;

        enum sdca_control_datatype type;
        struct sdca_control_range range;
        enum sdca_access_mode mode;
        u8 layers;

        bool deferrable;
        bool has_default;
        bool has_fixed;
};
```

Note line 764: `int *values;` - This is a pointer to an integer array.

**The Buggy Code:**

```897:897:sound/soc/sdca/sdca_functions.c
        control->values = devm_kzalloc(dev, hweight64(control->cn_list),
GFP_KERNEL);
```

**The Problem:**
- `hweight64(control->cn_list)` returns the number of bits set in
  `cn_list` (e.g., if 4 bits are set, it returns 4)
- The buggy code allocates only 4 bytes (treating values as char array)
- But `control->values` is an `int*` array, so we need 4 × sizeof(int) =
  **16 bytes** on most architectures

**How the Bug Manifests:**

```850:850:sound/soc/sdca/sdca_functions.c
                control->values[i] = tmp;
```

When the code writes `u32` values into the undersized buffer:
- **Heap buffer overflow** occurs
- Adjacent memory gets corrupted
- Kernel crashes (as stated in commit message)
- Potential security vulnerability (heap overflow)

**Pattern Comparison:**
Looking at similar allocations in the same file:

```985:986:sound/soc/sdca/sdca_functions.c
        num_controls = hweight64(control_list);
        controls = devm_kcalloc(dev, num_controls, sizeof(*controls),
GFP_KERNEL);
```

```1682:1683:sound/soc/sdca/sdca_functions.c
        num_pins = hweight64(pin_list);
        pins = devm_kcalloc(dev, num_pins, sizeof(*pins), GFP_KERNEL);
```

These allocations correctly use `devm_kcalloc()` with proper sizing. The
buggy line 897 is the **ONLY instance** of this incorrect pattern.

#### C. Explanation of the Fix

The fix changes:
```c
- control->values = devm_kzalloc(dev, hweight64(control->cn_list),
  GFP_KERNEL);
+ control->values = devm_kcalloc(dev, hweight64(control->cn_list),
+                                sizeof(int), GFP_KERNEL);
```

This correctly allocates `hweight64(control->cn_list) × sizeof(int)`
bytes, preventing the buffer overflow.

### 3. SECURITY ASSESSMENT

**Severity:** HIGH
- **Bug Type:** Heap buffer overflow
- **Trigger:** Parsing MIPI SDCA DisCo properties from ACPI firmware
- **Impact:** Kernel crash (confirmed in commit message), memory
  corruption
- **Exploitability:** Low to Medium (requires specially crafted ACPI
  firmware tables, typically controlled by OEM/BIOS)
- **No CVE assigned** (yet)

### 4. FEATURE VS BUG FIX CLASSIFICATION

**Classification:** PURE BUG FIX
- Fixes a crash-causing heap buffer overflow
- No new functionality added
- Changes allocation size calculation only
- Aligns with existing patterns in the same file

### 5. CODE CHANGE SCOPE ASSESSMENT

**Scope:** MINIMAL
- **1 file changed:** sound/soc/sdca/sdca_functions.c
- **2 lines changed:** +2 insertions, -1 deletion
- **Surgical fix:** Only changes the allocation call
- **No API changes**
- **No behavior changes** (except preventing the crash)

### 6. BUG TYPE AND SEVERITY

**Type:** Heap buffer overflow / Memory allocation bug

**Severity:** **CRITICAL**
- Causes kernel crashes in production
- Affects all systems with SDCA-capable SoundWire audio devices
- Memory corruption can lead to unpredictable behavior
- Data integrity risk

### 7. USER IMPACT EVALUATION

**Affected Users:**
- Systems with SDCA (SoundWire Device Class for Audio) hardware
- Modern Intel platforms with SoundWire audio codecs
- Primarily laptops and mobile devices with recent audio hardware

**Impact Scope:**
- SDCA is relatively new (added in 6.13)
- Growing adoption in modern audio hardware
- Bug affects ALL SDCA users who parse control properties
- Function `sdca_parse_function()` is core to SDCA initialization

### 8. REGRESSION RISK ANALYSIS

**Risk Level:** VERY LOW
- Extremely small, focused change
- Only fixes allocation size - no logic changes
- Makes buggy code match other correct patterns in same file
- Already reviewed by Charles Keepax (SDCA maintainer/author)
- Uses standard `devm_kcalloc()` API
- No dependencies on other code

### 9. MAINLINE STABILITY

**Status:**
- Committed to mainline: **November 10, 2025** (eb2d6774cc0d9)
- Committed by: Mark Brown (sound subsystem maintainer)
- Reviewed by: Charles Keepax (original SDCA author)
- **Already backported** to stable branches by Sasha Levin (stable
  maintainer)

### 10. AFFECTED KERNEL VERSIONS

**Versions with the bug:**
- **v6.17** and later (bug introduced in v6.17-rc1)
- **6.17.y stable** (confirmed to have the bug)

**Versions WITHOUT the bug:**
- **v6.16 and earlier** (bug not present - verified)
- v6.13-6.16 have SDCA but not the buggy code path

**Backport Status:**
- Already being staged for 6.17.y stable (commits eb36bb6148dac and
  d461d1dba9b84)

### 11. DEPENDENCY CHECK

**Dependencies:** NONE
- Self-contained fix
- No prerequisite commits needed
- No API changes that would block backporting
- Uses existing `devm_kcalloc()` API present in all stable kernels

### 12. STABLE KERNEL RULES COMPLIANCE

✅ **Obviously correct:** Yes - simple allocation size fix matching
existing patterns
✅ **Fixes real bug:** Yes - causes kernel crashes
✅ **Important issue:** Yes - crash bug in core audio subsystem code
✅ **Small and contained:** Yes - 2 lines changed, 1 file
✅ **No new features:** Yes - pure bug fix
✅ **No new APIs:** Yes - uses existing APIs

## BACKPORTING DECISION

### Should this be backported to stable?

**YES** - This is an excellent candidate for stable backporting.

### Reasoning:

**STRONG YES Signals:**
1. **Fixes kernel crashes** - Users experience crashes when SDCA audio
   devices parse control properties
2. **Memory safety bug** - Heap buffer overflow is a critical security
   concern
3. **Surgical fix** - Only 2 lines changed, extremely low regression
   risk
4. **Obviously correct** - Matches the pattern used elsewhere in the
   same file
5. **Reviewed and tested** - Already in mainline, reviewed by subsystem
   experts
6. **Already being backported** - Stable maintainer has already picked
   it up
7. **Small scope** - Only affects SDCA subsystem, won't impact other
   code
8. **No dependencies** - Can be cleanly applied to any kernel with SDCA
   support

**Risk vs Benefit:**
- **Benefit:** Prevents kernel crashes on systems with SDCA audio
  hardware
- **Risk:** Near zero - the fix is trivial and matches existing correct
  code
- **Trade-off:** Strongly favors backporting

**Affected Stable Trees:**
- **6.17.y** - MUST have this fix (currently has the bug)
- Future 6.18+ stable trees will also need it

**Note:** This fix is only relevant for stable trees that have the buggy
commit 50a479527ef01f ("ASoC: SDCA: Add support for -cn- value
properties"). Based on research:
- 6.16.y and earlier: NOT AFFECTED (don't have the buggy code)
- 6.17.y: AFFECTED - needs this fix

### Conclusion:

This commit meets all criteria for stable kernel backporting. It fixes a
critical crash bug with minimal risk, in a well-understood subsystem,
with a tiny, surgical change that's obviously correct. The stable
maintainer has already recognized this and is staging the backport.

**YES**

 sound/soc/sdca/sdca_functions.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/soc/sdca/sdca_functions.c b/sound/soc/sdca/sdca_functions.c
index 13f68f7b6dd6a..0ccb6775f4de3 100644
--- a/sound/soc/sdca/sdca_functions.c
+++ b/sound/soc/sdca/sdca_functions.c
@@ -894,7 +894,8 @@ static int find_sdca_entity_control(struct device *dev, struct sdca_entity *enti
 		return ret;
 	}
 
-	control->values = devm_kzalloc(dev, hweight64(control->cn_list), GFP_KERNEL);
+	control->values = devm_kcalloc(dev, hweight64(control->cn_list),
+				       sizeof(int), GFP_KERNEL);
 	if (!control->values)
 		return -ENOMEM;
 
-- 
2.51.0