[PATCH AUTOSEL 6.18-6.12] platform/x86: int1092: Fix info leak in parse_package()

[Sasha Levin]

From: Abdun Nihaal <nihaal@xxxxxxxxxxxxxx>

[ Upstream commit f5eb833730c071b68a68de5d1df442aae4ae7e6e ]

Sashiko reports a possible information leak that can occur as follows:

1. In parse_package(), memory allocated for data->device_mode_info is not
   zerozed initially as it is allocated with devm_kmalloc_array().

2. In the for loop after the allocation, a malformed ACPI package
   provided by firmware can cause some fields in data->device_mode_info
   to remain uninitialized.

3. Later in update_sar_data(), the uninitialized fields gets copied to
   the fields of context->sar_data, which can be exposed to userspace
   through sysfs attribute read (intc_data_show()).

Fix the leak by switching to use devm_kcalloc() for allocation.

Reported-by: Sashiko <sashiko-bot@xxxxxxxxxx>
Closes: https://sashiko.dev/#/patchset/20260710052806.100107-1-nihaal%40cse.iitm.ac.in
Signed-off-by: Abdun Nihaal <nihaal@xxxxxxxxxxxxxx>
Link: https://patch.msgid.link/20260723-platx86-v4-2-93b4a178b595@xxxxxxxxxxxxxx
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx>
Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
---

LLM Generated explanations, may be completely bogus:

I have enough to judge the leak path, the `devm_kcalloc` fix, and
whether this 7.3-rc4 tree should take it. Writing up the nine-phase
analysis next.

## Phase 1: Commit message forensics

**Step 1.1: Subject line**
Record: `[platform/x86: int1092]` `[Fix]` `[info leak in parse_package()
— uninitialized kmalloc data can reach sysfs]`

**Step 1.2: Tags**
Record:
- `Reported-by: Sashiko <sashiko-bot@xxxxxxxxxx>` — automated kernel
  review bot, not syzbot
- `Closes: https://sashiko.dev/#/patchset/20260710052806.100107-1-
  nihaal%40cse.iitm.ac.in`
- `Signed-off-by: Abdun Nihaal <nihaal@xxxxxxxxxxxxxx>` (author)
- `Link: https://patch.msgid.link/20260723-platx86-v4-2-
  93b4a178b595@xxxxxxxxxxxxxx`
- `Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx>`
  (platform/x86 maintainer)
- `Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx>`
  (applied by maintainer)
- No `Fixes:` tag in the committed message (expected for this review
  pipeline)
- No `Cc: stable` in the committed message; original mail **was** CCed
  to `stable@xxxxxxxxxxxxxxx` (verified via `b4 dig -w` and the v4 cover
  letter on the stable list)
- No `Tested-by:` (cover letter: compile-tested only)

**Step 1.3: Body**
Record:
- **Bug:** `device_mode_info` is allocated with `devm_kmalloc_array()`
  (non-zeroed). The parse loop `continue`s on malformed ACPI package
  elements, leaving those array slots uninitialized.
- **Symptom:** Uninitialized fields can be copied in `update_sar_data()`
  into `context->sar_data` and read from userspace via `intc_data` sysfs
  (`intc_data_show()`).
- **Root cause:** Allocation is not zeroed, despite `parse_package()`
  documenting that skipped entries “will have the default value of
  zero.”
- **Fix:** `devm_kmalloc_array()` → `devm_kcalloc()`.
- **Version info in message:** none. Driver has existed since v5.15.

**Step 1.4: Hidden bug fix?**
Record: Not hidden. Explicit information-leak fix. The surrounding
comment already promised zeroed skipped slots; the allocator did not
provide that.

## Phase 2: Diff analysis

**Step 2.1: Inventory**
Record:
- File: `drivers/platform/x86/intel/int1092/intel_sar.c` (+4/−4)
- Function: `parse_package()`
- Scope: single-file, one-call-site surgical change

**Step 2.2: Code flow**
Record:
- **Before:** `devm_kmalloc_array()` returns uninitialized heap. Loop
  writes only successfully parsed modes; failed/malformed entries leave
  `device_mode_info[itr]` untouched.
- **After:** `devm_kcalloc()` zeros the whole array first, so skipped
  slots stay `{0}` as the function comment describes.
- **Path:** probe/init (`sar_get_data()` → `parse_package()`), then
  later sysfs read / ACPI notify (`update_sar_data()`).

**Step 2.3: Bug mechanism**
Record: **Uninitialized data / kernel info leak.**
Mechanism verified in this tree:
1. `parse_package()` allocates `device_mode_info`.
2. Loop uses `continue` on type/count/`get_int_value()` failures (lines
   105–114).
3. `update_sar_data()` compares `context->sar_data.device_mode` to
   `device_mode_info[itr].device_mode` and copies `bandtable_index`,
   `antennatable_index`, `sartable_index`.
4. `intc_data_show()` emits those four ints to userspace.

If a skipped slot’s uninitialized `device_mode` happens to match the
current mode, heap leftovers are copied into `sar_data` and printed.

**Step 2.4: Fix quality**
Record: Obviously correct. `devm_kcalloc()` is the zeroing counterpart
of `devm_kmalloc_array()`. No API change, no lock change, no extra error
path. Regression risk is negligible (slightly more work at probe to zero
a small array, max 50 modes).

## Phase 3: Git history

**Step 3.1: Blame**
Record:
- Buggy skip-and-leave-uninitialized loop: `dcfbd31ef4bcf`
  (“platform/x86: BIOS SAR driver for Intel M.2 Modem”), 2021-08-20,
  first in **v5.15-rc1**.
- Original allocator was `kmalloc_array()` (also non-zeroing). Same leak
  class from day one.
- Matching-by-`device_mode` copy: `7df227847ab56` (2021-10-11).

**Step 3.2: Fixes: tag**
Record: No `Fixes:` on this commit. The matching parent
(`30c906cff490c`) has `Fixes: dcfbd31ef4bc`. That introducer **is** an
ancestor of this tree (`git merge-base --is-ancestor dcfbd31ef4bcf HEAD`
succeeded).

**Step 3.3: File history**
Record: Recent related commits on this file:
- `30c906cff490c` — convert to `devm_*` allocations (patch 1/2, parent
  of this commit)
- `f5eb833730c07` — this info-leak fix (patch 2/2)
This is **patch 2/2** of a two-patch series. It is standalone *on top of
patch 1*.

**Step 3.4: Author**
Record: Abdun Nihaal submitted both int1092 fixes in this series. Ilpo
Järvinen (platform/x86 maintainer) reviewed and applied both. Not the
original driver author (Shravan Sudhakar / Intel).

**Step 3.5: Prerequisites**
Record: **Depends on `30c906cff490c`**, which changed
`kmalloc_objs`/`kmalloc_array` into `devm_kmalloc_array()`. This hunk
only applies as written if that conversion is present. In **this** tree,
that parent **is** present (`git merge-base --is-ancestor 30c906cff490c
HEAD` succeeded). No other missing helpers: `devm_kcalloc()` is core
device-managed alloc.

## Phase 4: Mailing list / external research

**Step 4.1: Original discussion**
Record:
- `b4 dig -c f5eb833730c07` → https://patch.msgid.link/20260723-platx86-
  v4-2-93b4a178b595@xxxxxxxxxxxxxx
- Series: v1 (combined) → v2 → v3 (split 2/2) → **v4** (applied). v4
  only updated the commit message per Ilpo to document the leak path.
- Cover letter: “[PATCH v4 0/2] platform/x86: int1092: Fix two bugs in
  SAR driver”
- Explicitly CCed `stable@xxxxxxxxxxxxxxx`; also appeared on the stable
  list (spinics `lists/stable/msg986235.html` / `msg971516.html`).
- No NAK found in available archives.
- Cover letter: “Both patches are compile tested only.”

**Step 4.2: Recipients (`b4 dig -w`)**
Record: Abdun Nihaal; Shravan Sudhakar; Hans de Goede; Ilpo Järvinen;
`platform-driver-x86@xxxxxxxxxxxxxxx`; `linux-kernel@xxxxxxxxxxxxxxx`;
**`stable@xxxxxxxxxxxxxxx`**; Sashiko. Maintainer Ilpo reviewed and
applied.

**Step 4.3: Bug report**
Record: Sashiko static/agent review, not a user crash report. Closes URL
did not return the specific finding body (only the Sashiko project
page). Leak path is independently verifiable from the source.
**UNVERIFIED:** exact Sashiko finding text.

**Step 4.4: Series**
Record: 2/2. Patch 1 (`30c906cff490c`) is the `devm_` conversion (has
`Cc: stable` and `Fixes:`). Patch 2 is this kcalloc leak fix. Both are
in this tree, in order.

**Step 4.5: Stable list**
Record: Series was mailed to stable@ (cover + both patches). No evidence
of a NAK or “not for stable” reason. Patch 1 later received
CVE-2026-89437 (memory leak). That CVE is **patch 1**, not this info-
leak commit; not used as the reason for this decision.

## Phase 5: Code semantic analysis

**Step 5.1: Functions**
Record: `parse_package()` modified. Related: `update_sar_data()`,
`intc_data_show()`, `sar_get_data()`, `sar_probe()`,
`sar_get_device_mode()`, `intc_reg_store()`.

**Step 5.2: Callers**
Record:
- `parse_package()` ← `sar_get_data()` ← `sar_probe()` (boot/probe,
  `MAX_REGULATORY` = 3 times)
- `update_sar_data()` ← `sar_get_device_mode()` (probe + ACPI notify
  `0x80`) and `intc_reg_store()` (sysfs write)
- `intc_data_show()` ← sysfs read of `intc_data`

**Step 5.3: Callees**
Record: `get_int_value()`, `devm_kcalloc()`. No locks, no I/O besides
ACPI objects already passed in.

**Step 5.4: Reachability**
Record: Yes, from userspace on systems with ACPI ID `INTC1092`:
- `DEVICE_ATTR_RO(intc_data)` is mode **0444** (`__DEVICE_ATTR_RO` →
  0444 in `include/linux/device.h`).
- Documented in `Documentation/ABI/testing/sysfs-driver-intc_sar` as
  `/sys/bus/platform/devices/INTC1092:00/intc_data`.
Unprivileged processes can read it. Triggering the *uninitialized* slots
still needs malformed ACPI firmware; once those slots exist, a matching
`device_mode` exposes leftover heap words.

**Step 5.5: Similar patterns**
Record: Same file’s loop comment already required zeros. No sibling copy
of this bug in the int1092 directory. The immediately preceding series
patch did not zero the array (`devm_kmalloc_array`), so this follow-up
is required to actually close the leak.

## Phase 6: Local tree (this checkout only)

**Step 6.1: Does the buggy code exist here?**
Record:
- Tree: **`v7.3-rc4-27-gf0100363d8c37`**, `make kernelversion` =
  **7.3.0-rc4**, `VERSION=7 PATCHLEVEL=3 SUBLEVEL=0 EXTRAVERSION=-rc4`.
- Driver **is** present. `parse_package()` / `update_sar_data()` /
  `intc_data_show()` all exist.
- Introducer `dcfbd31ef4bcf` is an ancestor (v5.15-era).
- Current file already uses `devm_kcalloc()` because `f5eb833730c07` is
  an ancestor of HEAD. That is **not** treated as “already selected”; it
  only confirms the code and the fix belong to this lineage.
- Parent `30c906cff490c` is also an ancestor, so the hunk’s
  `devm_kmalloc_array` context exists in this history.

**Step 6.2: Backport difficulty**
Record: **Clean apply** onto the parent already in this tree (4-line
allocator swap in one function). No conflicting refactor of this
function after the parent besides this commit itself.

**Step 6.3: Related fixes already here**
Record: Patch 1 (devm conversion) is here. That conversion **does not**
zero the array, so it does not substitute for this fix. No other info-
leak fix on this path.

## Phase 7: Subsystem context

**Step 7.1**
Record: `drivers/platform/x86/intel/int1092/` — Intel BIOS Dynamic SAR
for M.2 modem. Criticality: **PERIPHERAL / platform-specific**, but the
sysfs node is world-readable, so the leak is a real userspace-visible
security issue on those machines.

**Step 7.2**
Record: Low-churn mature driver (added 2021, occasional fixes).
Maintainer: Shravan Sudhakar; applied by Ilpo Järvinen (pdx86). Config:
`CONFIG_INTEL_SAR_INT1092`, depends on ACPI.

## Phase 8: Impact and risk

**Step 8.1: Who is affected**
Record: Users of Intel platforms with ACPI device `INTC1092` and this
driver loaded (WWAN SAR). Not universal; **driver/platform-specific**.

**Step 8.2: Trigger**
Record: Probe parses BIOS ACPI DSM packages. Malformed/partial packages
skip slots. Later, ACPI notify or `intc_reg` store calls
`update_sar_data()`; any user can read `intc_data`. Firmware-dependent,
but the skip path is intentional (not a theoretical dead branch).
Unprivileged read of the attribute: **yes**.

**Step 8.3: Failure mode**
Record: Kernel heap contents (a few integers) can be copied into a
world-readable sysfs attribute. Severity: **HIGH** (info leak /
security), not a panic. Matches the classic uninitialized-kmalloc-to-
userspace pattern.

**Step 8.4: Risk–benefit**
Record:
- **Benefit:** High for affected hardware — closes a kernel-memory
  disclosure through a documented 0444 sysfs ABI; implements the
  behavior the function comment already promised.
- **Risk:** Very low — one allocator flag, no locking, no ABI change, no
  new features.
- **Ratio:** Strongly favors taking the fix.

## Phase 9: Synthesis

**Step 9.1: Evidence**

FOR:
- Real uninitialized-heap info leak to userspace via sysfs
- World-readable `intc_data` (0444)
- Function comment already required zeros;
  `kmalloc`/`devm_kmalloc_array` never provided them
- Bug present since the driver was added (v5.15); code exists in this
  7.3 tree
- 4-line, obviously correct `devm_kcalloc()` switch
- Reviewed and applied by the platform/x86 maintainer
- Author CCed stable@; v4 series posted to the stable list
- Prerequisite patch 1 is already in this tree

AGAINST:
- Niche Intel WWAN SAR driver, not a core path
- Needs malformed ACPI to leave holes (though that path is explicit)
- Compile-tested only, no `Tested-by`
- Committed message omitted `Fixes:` / `Cc: stable` (not a negative per
  pipeline rules)

UNRESOLVED:
- Full Sashiko finding text (page did not return the patchset body)
- Full verbatim Ilpo review mail (known: he asked to document the leak
  path; then Reviewed-by + applied)
- lore.kernel.org WebFetch returned 403; discussion reconstructed via
  `b4 dig`, openwall, LKML archive, and spinics

**Step 9.2: Stable rules**
1. Obviously correct and tested? **PASS** (obvious kcalloc swap;
   maintainer review; compile-tested)
2. Real bug affecting users? **PASS** (heap data can reach sysfs)
3. Important (crash/security/corruption/deadlock)? **PASS** —
   security/info leak
4. Small and contained? **PASS** — 8 lines in one function
5. No new features/APIs? **PASS**
6. Can apply to this tree? **PASS** — file, function, and
   `devm_kmalloc_array` parent all exist here

**Step 9.3: Exception category**
Record: Not a device-ID/quirk/DT/build/docs exception. It is a normal
**security/uninitialized-data** bugfix.

**Step 9.4: Decision**
This tree is 7.3-rc4. The INT1092 SAR driver and the non-zeroed
allocation-plus-`continue` parse loop are part of this lineage.
Switching to `devm_kcalloc()` is the minimal, correct way to stop
leftover slab contents from being matched in `update_sar_data()` and
printed by `intc_data_show()`. Prerequisite `30c906cff490c` is already
here, so the patch is self-contained for this tree. That is a stable-
quality security fix.

### What the commit solves, and why it matters here
`parse_package()` can skip malformed ACPI package entries and leave
`device_mode_info[]` uninitialized. Those words can later be copied into
`context->sar_data` and read through
`/sys/bus/platform/devices/INTC1092:00/intc_data` (mode 0444). On 7.3
this driver is present; without zeroing, that is a kernel info leak.
`devm_kcalloc()` closes it with no behavioral change for well-formed
firmware.

### Stable rules / risk
The change is four lines, maintainer-reviewed, and does not add APIs.
Benefit is closing a userspace-visible leak; regression risk is
essentially zero.

### Concerns
Needs patch 1’s `devm_kmalloc_array` conversion — **already in this
tree**. No other blockers.

Verification:
- [Phase 1] Parsed tags: Reported-by Sashiko; Reviewed-by/SOB Ilpo
  Järvinen; no Fixes in the commit; original mail CCed stable@
- [Phase 2] Diff: `devm_kmalloc_array` → `devm_kcalloc` in
  `parse_package()` only
- [Phase 2] Confirmed skip/`continue` loop and `update_sar_data()` copy
  in `intel_sar.c`
- [Phase 3] Introducer `dcfbd31ef4bcf` (v5.15-rc1) is ancestor of HEAD
- [Phase 3] Parent `30c906cff490c` is ancestor of HEAD (`merge-base
  --is-ancestor` exit 0)
- [Phase 3] `git describe HEAD` = `v7.3-rc4-27-gf0100363d8c37`; `make
  kernelversion` = 7.3.0-rc4
- [Phase 4] `b4 dig -c f5eb833730c07`: v4 2/2 at
  patch.msgid.link/20260723-platx86-v4-2-93b4a178b595@xxxxxxxxxxxxxx
- [Phase 4] `b4 dig -a`: v1…v4; applied version is v4 (commit-message-
  only change)
- [Phase 4] `b4 dig -w`: pdx86 maintainers + stable@xxxxxxxxxxxxxxx
- [Phase 4] Cover letter: two bugfixes, compile-tested only; Ilpo
  requested leak-path wording
- [Phase 4] lore.kernel.org WebFetch: 403; used openwall/LKML/spinics
  instead
- [Phase 5] Call chain: `sar_probe` → `sar_get_data` → `parse_package`;
  sysfs `intc_data_show` is 0444
- [Phase 6] Buggy parse/sysfs path exists in this tree; kcalloc is the
  correct fix for it
- [Phase 8] Failure mode: kernel heap integers to userspace sysfs,
  severity HIGH (info leak)
- UNVERIFIED: verbatim Sashiko finding body; full Ilpo review email text

**YES**

 drivers/platform/x86/intel/int1092/intel_sar.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/platform/x86/intel/int1092/intel_sar.c b/drivers/platform/x86/intel/int1092/intel_sar.c
index 7263114f0b3d0..f506155f35d4d 100644
--- a/drivers/platform/x86/intel/int1092/intel_sar.c
+++ b/drivers/platform/x86/intel/int1092/intel_sar.c
@@ -91,10 +91,10 @@ static acpi_status parse_package(struct wwan_sar_context *context, union acpi_ob
 	    item->package.count <= data->total_dev_mode)
 		return AE_ERROR;
 
-	data->device_mode_info = devm_kmalloc_array(&context->sar_device->dev,
-						    data->total_dev_mode,
-						    sizeof(*data->device_mode_info),
-						    GFP_KERNEL);
+	data->device_mode_info = devm_kcalloc(&context->sar_device->dev,
+					      data->total_dev_mode,
+					      sizeof(*data->device_mode_info),
+					      GFP_KERNEL);
 	if (!data->device_mode_info)
 		return AE_ERROR;
 
-- 
2.53.0