[PATCH AUTOSEL 6.18] ARM: tegra: tf600t: Invert accelerometer calibration matrix

[PATCH AUTOSEL 6.18] ARM: tegra: tf600t: Invert accelerometer calibration matrix

[Sasha Levin]

From: Svyatoslav Ryhel <clamor95@gmail.com>

[ Upstream commit 774bc2764647cfd6b65727cfa978d809f11df392 ]

IMU calibration matrix used in the device tree is inverted when testing on
the device which results in wrong screen orientation. Invert it to match
the matrix dumped from the device.

Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: ARM: tegra: tf600t: Invert accelerometer
calibration matrix

**Local tree:** Linux **6.18.44** (`git describe HEAD` → `v6.18.44`,
Makefile `VERSION=6 PATCHLEVEL=18 SUBLEVEL=44`)

**Commit under review:** `774bc2764647c` (mainline; **not** present in
this 6.18.y checkout)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
**Record:** `[ARM: tegra: tf600t]` `[Invert]` `[accelerometer
calibration matrix in device tree]`

Subsystem: ARM Tegra device tree for ASUS TF600T. Action: correct an
inverted IMU `mount-matrix`.

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
**Record:**
| Tag | Value |
|-----|-------|
| Tested-by | Andreas Westman Dorcsak \<hedmoo@yahoo.com\> |
| Signed-off-by | Svyatoslav Ryhel \<clamor95@gmail.com\> (author) |
| Signed-off-by | Thierry Reding \<treding@nvidia.com\> (Tegra
maintainer) |
| Fixes: | absent (expected) |
| Reported-by: | absent |
| Cc: stable@vger.kernel.org | absent (expected, not a negative signal)
|
| Link: | absent |

Notable: hardware-tested on the actual device; maintainer sign-off from
Thierry Reding.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
**Record:**
- **Bug:** IMU `mount-matrix` in `tegra30-asus-tf600t.dts` is inverted
  relative to values read from the physical device.
- **Symptom:** Wrong screen orientation (auto-rotation does not match
  physical tablet orientation).
- **Root cause:** Incorrect device-tree sensor orientation matrix for
  the MPU6050 IMU node.
- **Version info:** None stated; fix targets board support introduced in
  `8ae70af2477b7`.

### Step 1.4: DETECT HIDDEN BUG FIXES
**Record:** Not disguised as cleanup. This is an explicit device-tree
hardware-description correction. It is a functional bug fix (wrong
sensor axis mapping), not a refactor or style change.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: INVENTORY THE CHANGES
**Record:**
- **File:** `arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts` (+3 / −3
  lines)
- **Node:** `imu@69` (compatible `"invensense,mpu6050"`)
- **Functions:** N/A (device tree only)
- **Scope:** Single-file, surgical, device-specific DT fix

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
**Record:**
| Hunk | Before | After |
|------|--------|-------|
| IMU `mount-matrix` | `[[0,-1,0],[-1,0,0],[0,0,-1]]` |
`[[0,1,0],[1,0,0],[0,0,1]]` |

The magnetometer child node (`ak8975`) `mount-matrix` is **unchanged**
(still the old values). Only the MPU6050 accelerometer/gyro orientation
is corrected. The IIO driver reads this matrix at probe via
`iio_read_mount_matrix()` and exposes corrected axis data to
userspace/kernel consumers that drive display rotation.

### Step 2.3: IDENTIFY THE BUG MECHANISM
**Record:**
- **Category:** Hardware description / DT correctness fix (incorrect
  `mount-matrix`)
- **Mechanism:** Inverted axis transformation causes accelerometer
  readings to be mapped to the wrong physical axes; consumers
  interpreting gravity vector for screen rotation get incorrect
  orientation.

### Step 2.4: ASSESS THE FIX QUALITY
**Record:**
- Fix is minimal and obviously correct for the stated hardware
  measurement.
- Zero impact on any other board (property change is inside TF600T DTS
  only).
- Regression risk: **very low** — affects only TF600T IMU node.
- Matrix values are a sign flip on all three diagonal elements,
  consistent with a 180°/axis-inversion correction.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
**Record:**
- Buggy `mount-matrix` introduced in `8ae70af2477b7` by Svyatoslav Ryhel
  (2025-06-17, committed 2025-07-09).
- Subject: "ARM: tegra: Add device-tree for ASUS VivoTab RT TF600T"
- Present in this 6.18.y tree at lines 1043–1045 (verified via `git
  blame` and file read).

### Step 3.2: FOLLOW THE FIXES: TAG
**Record:** No `Fixes:` tag present. N/A.

### Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
**Record:**
- **6.18.y history** for this file: only `8ae70af2477b7` (initial TF600T
  DTS).
- **master history** additionally has panel/backlight/connector commits
  not in 6.18.y:
  - `2ecff0cda80b9` Configure panel
  - `d9c890d753034` Drop backlight regulator
  - `774bc2764647c` Invert accelerometer calibration matrix (this
    commit)
- This specific fix is **standalone** (patch 9/9 of a series on lore,
  but functionally independent — only touches IMU matrix).

### Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
**Record:** Svyatoslav Ryhel is an active Tegra DTS contributor (TF600T,
SL101, Transformer, etc.). Thierry Reding (maintainer) committed both
the original DTS and this fix.

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
**Record:** No code dependencies. The MPU6050 driver and TF600T DTS
already exist in 6.18.y. Fix applies cleanly (`git apply --check`
passed). **Standalone: yes.**

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
**Record:**
- `b4 dig -c 774bc2764647c` found: [PATCH v1 9/9] ARM: tegra: tf600t:
  Invert accelerometer calibration matrix
- URL:
  https://patch.msgid.link/20260511074859.24930-10-clamor95@gmail.com
- Also matched earlier v1 series from 2026-04-06 (same patch 9/9).
- WebFetch of lore URL blocked by Anubis bot protection — could not read
  thread replies.
- **UNVERIFIED:** Whether reviewers explicitly nominated `Cc: stable` in
  thread replies.

### Step 4.2: CHECK WHO REVIEWED THE PATCH
**Record:** (`b4 dig -w`) CC'd: Rob Herring, Krzysztof Kozlowski, Conor
Dooley (DT maintainers), Thierry Reding, Jonathan Hunter, devicetree@,
linux-tegra@, linux-kernel@. Appropriate subsystem coverage.

### Step 4.3: SEARCH FOR THE BUG REPORT
**Record:** No external bug report links. Testing evidence is `Tested-
by:` on actual TF600T hardware.

### Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
**Record:** Part of a 9-patch TF600T series on lore; other patches
address panel/backlight/connector. This matrix fix does not depend on
them.

### Step 4.5: CHECK STABLE MAILING LIST HISTORY
**Record:** **UNVERIFIED** — did not search lore stable list (no
indication of prior stable discussion found via b4).

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF
**Record:** Device-tree property only. Runtime handling is in IIO
drivers (`iio_read_mount_matrix()` used by ST magnetometer, BMC150,
etc.; MPU6050 uses same binding per
`Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml`).

### Step 5.2: TRACE CALLERS
**Record:** `mount-matrix` is read at IMU driver probe. Accelerometer
data feeds userspace (e.g., `iio-sensor-proxy`, compositors) and kernel
display-rotation logic. Affects normal runtime sensor path on TF600T
when `CONFIG_INV_MPU6050_IIO` (or equivalent) is enabled.

### Step 5.3: TRACE CALLEES
**Record:** IIO core reads DT `mount-matrix` property and applies
transformation to raw sensor readings before exposing channels.

### Step 5.4: FOLLOW THE CALL CHAIN
**Record:** Boot → DT probe of `imu@69` → MPU6050 driver reads `mount-
matrix` → accelerometer channel data transformed → userspace/kernel
reads orientation → display rotation. **Reachable during normal tablet
use** (not an obscure error path).

### Step 5.5: SEARCH FOR SIMILAR PATTERNS
**Record:** Other boards in-tree use `mount-matrix` for orientation
(e.g., PinePhone, various ST sensors). Incorrect matrices are a known
class of DT bugs; magnetometer on the same TF600T node still has the old
matrix (intentionally left unchanged per this commit).

---

## PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE (6.18.y)

### Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?
**Record:** **Yes.** Current 6.18.44 tree has the buggy matrix at lines
1043–1045. `git merge-base --is-ancestor 8ae70af2477b7 HEAD` → TF600T
DTS is in tree. `git merge-base --is-ancestor 774bc2764647c HEAD` →
**fix is NOT in tree.**

### Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
**Record:** **Clean apply expected.** `git apply --check` on formatted
patch succeeded. Line numbers differ slightly from mainline diff (1074
vs 1091) due to fewer upstream commits in stable file, but merge is
trivial.

### Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE
**Record:** No alternate fix for this issue found in 6.18.y history.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
**Record:** **Subsystem:** ARM device tree / Tegra platform / IIO sensor
orientation. **Criticality:** PERIPHERAL — affects only ASUS VivoTab RT
TF600T (Tegra30 tablet, niche but real hardware).

### Step 7.2: ASSESS SUBSYSTEM ACTIVITY
**Record:** TF600T support is new (added 6.17 cycle, present in 6.18.y).
Active development on mainline with follow-up TF600T patches not yet in
stable.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: DETERMINE WHO IS AFFECTED
**Record:** **Platform-specific** — users running Linux on ASUS TF600T
with kernel 6.18.y. No impact on any other hardware.

### Step 8.2: DETERMINE THE TRIGGER CONDITIONS
**Record:** Trigger is **every boot / every sensor read** on TF600T when
display auto-rotation is used. Common for tablet use. Not security-
relevant; unprivileged users cannot trigger kernel crashes via this bug.

### Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
**Record:**
- **Failure mode:** Incorrect screen orientation / auto-rotation.
- **Severity:** **LOW to MEDIUM** — functional/interactivity issue, not
  crash, corruption, deadlock, or security. Annoying and breaks expected
  tablet behavior, but system remains stable.

### Step 8.4: CALCULATE RISK-BENEFIT RATIO
**Record:**
- **Benefit:** Corrects broken auto-rotation for TF600T users on 6.18.y;
  completes board support already shipped in stable.
- **Risk:** Minimal — 3-line DT change scoped to one device node on one
  board.
- **Ratio:** High benefit-to-risk for TF600T users; near-zero risk for
  everyone else.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**FOR backporting:**
- Real, hardware-verified bug (wrong screen orientation)
- Buggy code is present in 6.18.y (board support was merged with
  incorrect matrix)
- Trivial, device-specific DT fix; applies cleanly
- Tegra maintainer signed off; Tested-by on hardware
- Matches stable exception: DT fix for incorrect hardware description
- Per `stable-kernel-rules.rst`: fixes "a real bug that bothers people"
  on supported hardware

**AGAINST backporting:**
- Low severity (orientation wrong, not crash/corruption/security)
- Extremely niche hardware (2012-era Windows RT tablet)
- No syzbot/fuzzer report, no widespread user reports
- Other TF600T improvements remain mainline-only (panel, backlight) —
  stable already ships partial board support

**UNRESOLVED:**
- Whether lore reviewers explicitly requested `Cc: stable` (WebFetch
  blocked)
- Whether any distribution kernel maintainer has reported this to stable

### Step 9.2: APPLY THE STABLE RULES CHECKLIST

| Criterion | Result |
|-----------|--------|
| 1. Obviously correct and tested? | **PASS** — Tested-by on device;
maintainer ack; values match hardware dump |
| 2. Fixes a real bug affecting users? | **PASS** — wrong screen
orientation on TF600T |
| 3. Important issue? | **PASS (borderline)** — interactivity/functional
bug on supported hardware, not crash-level; qualifies as hardware-
description correction per stable DT guidance |
| 4. Small and contained? | **PASS** — 3 lines, 1 file |
| 5. No new features or APIs? | **PASS** — DT property value correction
only |
| 6. Can apply to local tree? | **PASS** — verified clean apply |

### Step 9.3: CHECK FOR EXCEPTION CATEGORIES
**Record:** **Device tree update for existing hardware** — corrects
incorrect `mount-matrix` for a board whose DTS is already in 6.18.y.

### Step 9.4: DECISION RATIONALE

This 6.18.y tree already ships TF600T device-tree support
(`8ae70af2477b7`) with an incorrect accelerometer orientation matrix.
Users of this specific tablet on 6.18.x get broken auto-rotation. The
fix is as low-risk as stable backports get: three lines in a board-
specific DTS, hardware-tested, maintainer-approved, and applies cleanly.
While severity is low compared to crashes or security issues, stable
rules explicitly accept DT hardware-description fixes and "real bugs
that bother people" on supported platforms. Shipping board support
without this correction leaves a known, verified functional defect in
the stable tree.

---

## Verification

- **[Phase 1]** Parsed commit message and tags from `git show
  774bc2764647c`
- **[Phase 2]** Diff analysis: 3 lines changed in `imu@69` `mount-
  matrix`; magnetometer matrix unchanged
- **[Phase 3]** `git blame`: buggy lines from `8ae70af2477b7`
  (2025-07-09)
- **[Phase 3]** `git log stable/linux-6.18.y -- tegra30-asus-
  tf600t.dts`: only intro commit in stable
- **[Phase 3]** `git log master -- tegra30-asus-tf600t.dts`: fix + 3
  other TF600T commits not in stable
- **[Phase 3]** `git merge-base --is-ancestor`: DTS in 6.18.y, fix NOT
  in 6.18.y
- **[Phase 4]** `b4 dig -c 774bc2764647c`: found lore URL
- **[Phase 4]** `b4 dig -w`: DT and Tegra maintainers CC'd
- **[Phase 4]** `b4 dig -a`: v1 series, patch 9/9
- **[Phase 4]** WebFetch lore URL: blocked (Anubis) — stable nomination
  in thread UNVERIFIED
- **[Phase 5]** Read current DTS at lines 1043–1064; confirmed buggy IMU
  matrix present
- **[Phase 5]** Grep: `mount-matrix` binding documented in
  `invensense,mpu6050.yaml`
- **[Phase 6]** `git describe HEAD`: v6.18.44
- **[Phase 6]** `git apply --check` on formatted patch: clean apply
- **[Phase 6]** Read file: confirmed buggy code exists at lines
  1043–1045
- **[Phase 7]** Read `Documentation/process/stable-kernel-rules.rst`:
  DT/hardware-description fixes qualify
- **[Phase 8]** Assessed severity: functional orientation bug, LOW-
  MEDIUM, platform-specific

**YES**

 arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts b/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts
index 5d9e23a438204..856b1bb8b6f37 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts
+++ b/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts
@@ -1040,9 +1040,9 @@ imu@69 {
 			vdd-supply   = <&vdd_3v3_sys>;
 			vddio-supply = <&vdd_1v8_vio>;
 
-			mount-matrix =	 "0", "-1",  "0",
-					"-1",  "0",  "0",
-					 "0",  "0", "-1";
+			mount-matrix =	 "0",  "1",  "0",
+					 "1",  "0",  "0",
+					 "0",  "0",  "1";
 
 			/* External I2C interface */
 			i2c-gate {
-- 
2.53.0

[PATCH AUTOSEL 6.18] drivers/of: validate live-tree string properties before string use

[Sasha Levin]

From: Pengpeng Hou <pengpeng@iscas.ac.cn>

[ Upstream commit 1e54c31b9cbbb42162e2e4317c18c8a8b350a79d ]

`populate_properties()` stores live-tree property values as raw byte
sequences plus a separate `length`. They are not globally guaranteed to
be NUL-terminated.

`of_prop_next_string()` iterates string-list properties by walking raw
bytes, `__of_node_is_type()` checks `device_type`,
`__of_device_is_status()` checks `status`, and
`of_alias_from_compatible()` reads the first `compatible` entry. These
paths must validate that the relevant string fits within the property
bounds before they hand it to C string helpers.

Validate these live-tree string properties within their declared bounds.
In particular, make `of_prop_next_string()` reject malformed entries
before returning them, keep the `device_type` check inside the existing
no-lock helper path, and add unit coverage for malformed first and
trailing string-list entries.

Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260507081812.91838-1-pengpeng@iscas.ac.cn
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: `drivers/of: validate live-tree string
properties before string use`

## Local Tree Context

This checkout is **linux-6.18.y** at **v6.18.43** (`HEAD detached from
stable/linux-6.18.y`). The buggy code is present; this fix is not yet
applied.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
**Record:** `[drivers/of]` `[validate]` — Validate live-tree string
properties before passing them to C string helpers (`strlen`, `strcmp`,
etc.).

### Step 1.2: Tags
**Record:**
- **Signed-off-by:** Pengpeng Hou `<pengpeng@iscas.ac.cn>` (author)
- **Link:**
  https://patch.msgid.link/20260507081812.91838-1-pengpeng@iscas.ac.cn
- **Signed-off-by:** Rob Herring (Arm) `<robh@kernel.org>` (OF
  maintainer merge)
- No `Fixes:`, `Reported-by:`, `Cc: stable@vger.kernel.org`, `Tested-
  by:`, or `Reviewed-by:` tags

Notable: maintainer merge sign-off from Rob Herring; no syzbot or user
bug report.

### Step 1.3: Body Analysis
**Record:**
- **Bug:** `populate_properties()` and live-tree property storage keep
  raw byte sequences with a `length` field; they are not guaranteed NUL-
  terminated.
- **Affected paths:** `of_prop_next_string()`, `__of_node_is_type()`,
  `__of_device_is_status()`, `of_alias_from_compatible()` use
  `strlen`/`strcmp` without verifying the string fits within `length`.
- **Symptom:** Out-of-bounds reads when scanning for a NUL terminator on
  malformed properties.
- **Fix:** Validate with `strnlen()` within declared bounds; switch
  `of_alias_from_compatible()` to `of_property_read_string_index()`
  (already validated).
- **Root cause:** Inconsistent validation — some OF helpers already use
  `strnlen`, these paths do not.

### Step 1.4: Hidden Bug Fix?
**Record:** Yes. Despite “validate” wording rather than “fix”, this is a
real memory-safety bug fix (out-of-bounds read), not cosmetic cleanup.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
**Record:**
| File | Change |
|------|--------|
| `drivers/of/base.c` | ~30 lines modified |
| `drivers/of/property.c` | ~25 lines modified |
| `drivers/of/unittest.c` | ~35 lines added (tests) |

**Functions modified:** `__of_node_is_type()`,
`__of_device_is_status()`, `of_alias_from_compatible()`,
`of_prop_next_string()`

**Scope:** Single-subsystem, surgical fix + unit tests.

### Step 2.2: Code Flow Changes

**Hunk 1 — `__of_node_is_type()`:**
- Before: `strcmp(match, type)` with no bounds check on `device_type`.
- After: `strnlen(match, len) >= len` rejects unterminated values before
  `strcmp`.

**Hunk 2 — `__of_device_is_status()`:**
- Before: `strlen(status)` / `strcmp` / `strncmp` without verifying
  `status` is NUL-terminated within `statlen`.
- After: Rejects if `strnlen(status, statlen) >= statlen`.

**Hunk 3 — `of_alias_from_compatible()`:**
- Before: `strlen(compatible) > cplen` — `strlen` itself can read past
  `cplen` if no NUL exists within bounds.
- After: Uses `of_property_read_string_index()` which already validates
  via `strnlen`.

**Hunk 4 — `of_prop_next_string()`:**
- Before: On first entry (`cur == NULL`), returns `prop->value`
  unconditionally; on advance uses `strlen(cur)` without bounds.
- After: Validates cursor within `[value, value+length)`; uses `strnlen`
  for both current and next strings; rejects unterminated entries.

### Step 2.3: Bug Mechanism
**Record:** **Category:** Memory safety — out-of-bounds read (buffer
over-read).

**Mechanism:** Property values are stored as `(value, length)` byte
sequences. `strlen()`/`strcmp()` scan until NUL. If no NUL exists within
`length`, they read past the property boundary. The tree already has
test data for this:

```65:66:drivers/of/unittest-data/tests-phandle.dtsi
                                unterminated-string = [40 41 42 43];
                                unterminated-string-list = "first",
"second", [40 41 42 43];
```

`of_property_read_string_index()` already rejects these (`-EILSEQ`), but
`of_prop_next_string()` does not.

### Step 2.4: Fix Quality
**Record:**
- **Obviously correct:** Matches the existing pattern in
  `of_property_read_string()` and `of_property_read_string_helper()`.
- **Minimal:** No API changes, no refactoring.
- **Regression risk:** Low — well-formed DT strings behave the same;
  only malformed properties change from OOB-read to safe rejection.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
**Record:** Shallow clone (`git rev-parse --is-shallow-repository` →
`true`); blame points all lines to merge base `6bda50f4333fa`. Cannot
determine original introduction commit from this checkout. Buggy code is
present in 6.18.43.

### Step 3.2: Fixes Tag
**Record:** N/A — no `Fixes:` tag in commit message.

### Step 3.3: Related File History
**Record:** Shallow history limits `git log` on these files. In-tree,
`of_property_read_string()` (line 505) and
`of_property_read_string_helper()` (line 581) already use `strnlen`.
`overlay.c` line 228 also validates before `strlen`. This fix closes the
remaining gaps in the same subsystem.

### Step 3.4: Author History
**Record:** No prior commits from Pengpeng Hou in this shallow tree. Rob
Herring (OF maintainer) merged it.

### Step 3.5: Dependencies
**Record:** Standalone. Uses existing `of_property_read_string_index()`
(inline in `include/linux/of.h`, calls
`of_property_read_string_helper`). No series dependencies.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1–4.5
**Record:**
- `b4 dig -c HEAD` matched wrong commit (local HEAD, not this patch).
- `b4 dig` with message-ID failed (requires `-c COMMITISH`).
- lore.kernel.org and patch.msgid.link blocked by bot protection
  (Anubis).
- **UNVERIFIED:** Full mailing-list review thread, stable nominations,
  reviewer NAKs.

From commit message and Rob Herring merge sign-off: patch went through
normal OF maintainer tree.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key Functions
**Record:** `of_prop_next_string`, `__of_node_is_type`,
`__of_device_is_status`, `of_alias_from_compatible`

### Step 5.2: Callers
**Record:**
- `of_prop_next_string`: `__of_device_is_compatible()` (core device
  matching), `drivers/memory/of_memory.c`,
  `drivers/net/wireless/mediatek/mt76/eeprom.c`, `drivers/leds/leds-
  powernv.c`, `arch/powerpc/platforms/pseries/of_helpers.c`, macro in
  `include/linux/of.h`
- `__of_device_is_status` → `of_device_is_available()` (called on
  essentially every OF device probe), `of_device_is_fail`,
  `of_device_is_reserved`
- `__of_node_is_type` → `of_find_node_by_type()`,
  `of_get_next_cpu_node()`, `__of_device_is_compatible()`
- `of_alias_from_compatible` → SPI, I2C, DRM DSI, HSI, ACPI bus alias
  handling

### Step 5.3: Callees
**Record:** `__of_get_property`, `strnlen`, `strcmp`, `strncmp`,
`of_property_read_string_index` → `of_property_read_string_helper`

### Step 5.4: Reachability
**Record:** Reachable on every boot on DT-based platforms (ARM, RISC-V,
PowerPC, etc.) during device-tree parsing, matching, and probe. Trigger
requires malformed property data (bad DT blob, overlay, or dynamic
property), not normal well-formed vendor DT.

### Step 5.5: Similar Patterns
**Record:** Same `strnlen(prop->value, prop->length) >= prop->length`
check already exists in:
- `of_property_read_string()` at `drivers/of/property.c:505`
- `of_property_read_string_helper()` at `drivers/of/property.c:581`
- `overlay.c:228`

This fix brings the remaining helpers in line.

---

## PHASE 6: CROSS-REFERENCE WITH LOCAL TREE

### Step 6.1: Buggy Code Present?
**Record:** **Yes.** All four vulnerable code paths exist in 6.18.43:

```615:629:drivers/of/property.c
const char *of_prop_next_string(const struct property *prop, const char
*cur)
{
        const void *curv = cur;
        // ...
        curv += strlen(cur) + 1;  // no bounds check on cur or first
string
```

```83:87:drivers/of/base.c
static bool __of_node_is_type(const struct device_node *np, const char
*type)
{
        const char *match = __of_get_property(np, "device_type", NULL);
        return np && match && type && !strcmp(match, type);  // no
bounds check
```

### Step 6.2: Backport Difficulty
**Record:** Clean apply expected — line context matches the provided
diff. No conflicting changes in recent 6.18.y history on these
functions.

### Step 6.3: Related Fixes Already Present?
**Record:** Partial. `of_property_read_string*` paths already validate.
`of_prop_next_string` and the three `base.c` helpers do not. No
duplicate fix found.

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem
**Record:** `drivers/of` — Open Firmware / Device Tree core.
**Criticality: CORE** for all DT-based platforms.

### Step 7.2: Activity
**Record:** Actively maintained; recent commits include fwnode flag
thread-safety and alias refcount leak fixes in this tree.

---

## PHASE 8: IMPACT AND RISK

### Step 8.1: Who Is Affected
**Record:** All DT/OF platforms (ARM, RISC-V, PowerPC, some MIPS, etc.).
Not x86 ACPI-only systems.

### Step 8.2: Trigger Conditions
**Record:**
- Malformed DT property without NUL within declared `length`
- Examples: raw byte properties (`[40 41 42 43]`), truncated overlay
  properties, dynamic properties via `__of_prop_dup()` (copies exact
  length, no added NUL)
- Unprivileged trigger: only if attacker can supply/modify DT (some
  embedded boot chains, overlay loading)
- Well-formed vendor DT: not affected

### Step 8.3: Failure Mode
**Record:** Out-of-bounds read past property boundary → KASAN report,
potential oops, information leak from adjacent memory. **Severity:
HIGH** (memory safety); not data corruption but real kernel robustness
issue.

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** HIGH for DT platforms — closes OOB-read holes in core
  matching/probe paths
- **Risk:** VERY LOW — ~55 lines of production code, mirrors existing
  validated patterns
- **Ratio:** Strongly favors backport

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backport:**
- Real out-of-bounds read bug in core OF code
- Affects device matching, status checks, alias resolution — common boot
  paths
- Small, surgical, maintainer-merged fix
- Consistent with validation already present in same files
- Unit tests included
- Bug demonstrable with existing `unterminated-string` test data

**AGAINST backport:**
- Requires malformed DT to trigger (not typical production DT)
- No user/syzbot report in commit message
- Mailing-list discussion unverified

**Unresolved:**
- Full lore review thread (blocked)
- Exact mainline commit hash (not in shallow 6.18.y history)

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — mirrors existing `strnlen`
   pattern; adds unit tests
2. Fixes a real bug? **PASS** — OOB read on malformed properties
3. Important issue? **PASS** — memory safety / potential crash on DT
   platforms
4. Small and contained? **PASS** — ~55 lines production code + tests
5. No new features/APIs? **PASS** — behavior change only for malformed
   input
6. Can apply to local tree? **PASS** — buggy code present, clean apply
   expected

### Step 9.3: Exception Category
**Record:** N/A (not device ID, quirk, DT binding, build fix, or docs
fix — standard bug fix).

### Step 9.4: Decision Rationale

For **linux-6.18.y**, this commit fixes a genuine memory-safety gap in
core device-tree string handling. Several OF helpers already validate
with `strnlen`, but `of_prop_next_string()` and three `base.c` helpers
do not — creating inconsistent, unsafe behavior on malformed properties.
The fix is small, follows established in-tree patterns, is merged by the
OF maintainer, and affects paths used during every device probe on DT
platforms. The trigger (malformed DT) is uncommon in production but is
exactly the class of input the kernel must handle safely.

---

## Verification

- **[Phase 1]** Parsed subject, tags, body from provided commit message
- **[Phase 1]** Confirmed no `Fixes:`, `Reported-by:`, or `Cc: stable`
  tags
- **[Phase 2]** Diff analysis: 3 production files, 4 functions modified
- **[Phase 2]** Read current `of_prop_next_string()` at
  `drivers/of/property.c:615-629` — uses unbounded `strlen`
- **[Phase 2]** Read current `__of_node_is_type()` at
  `drivers/of/base.c:83-87` — no bounds check
- **[Phase 2]** Read current `__of_device_is_status()` at
  `drivers/of/base.c:437-460` — no bounds check
- **[Phase 2]** Read current `of_alias_from_compatible()` at
  `drivers/of/base.c:1170-1181` — `strlen` before bounds validation
- **[Phase 2]** Read `of_property_read_string()` at
  `drivers/of/property.c:505` — already uses `strnlen` (fix pattern
  exists)
- **[Phase 2]** Read `of_property_read_string_helper()` at
  `drivers/of/property.c:581` — already uses `strnlen`
- **[Phase 2]** Read `overlay.c:228` — already uses `strnlen`
- **[Phase 3]** `git rev-parse --is-shallow-repository` → `true`
  (limited history)
- **[Phase 3]** `git blame` on changed lines — all point to
  `6bda50f4333fa` (shallow base)
- **[Phase 3]** Verified `of_property_read_string_index` exists at
  `include/linux/of.h:1262-1268`
- **[Phase 4]** `b4 dig -c HEAD` — returned unrelated URL (wrong match)
- **[Phase 4]** `b4 dig` with message-ID — failed (wrong usage)
- **[Phase 4]** UNVERIFIED: lore.kernel.org and patch.msgid.link blocked
  by bot protection
- **[Phase 5]** `grep of_prop_next_string` — 6 call sites in production
  code
- **[Phase 5]** `grep of_alias_from_compatible` — 6 production call
  sites
- **[Phase 5]** `grep of_device_is_available` — widespread driver usage
  confirmed
- **[Phase 6]** `git describe HEAD` → `v6.18.43-1-gc7f0dac02d232`;
  branch `stable/linux-6.18.y`
- **[Phase 6]** Confirmed buggy code present in all four functions
- **[Phase 6]** Read `tests-phandle.dtsi:65-66` — unterminated test
  properties exist
- **[Phase 6]** Read `__of_prop_dup()` at `drivers/of/dynamic.c:424` —
  `kmemdup` without NUL padding
- **[Phase 8]** Failure mode: OOB read via `strlen`/`strcmp` on non-NUL-
  terminated property within declared length

**YES**

 drivers/of/base.c     | 43 ++++++++++++++++++++++++++-----------------
 drivers/of/property.c | 27 +++++++++++++++++++++------
 drivers/of/unittest.c | 32 ++++++++++++++++++++++++++++++++
 3 files changed, 79 insertions(+), 23 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 6620bf07b79b8..f6b99bd7a9ceb 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -82,9 +82,17 @@ EXPORT_SYMBOL(of_node_name_prefix);
 
 static bool __of_node_is_type(const struct device_node *np, const char *type)
 {
-	const char *match = __of_get_property(np, "device_type", NULL);
+	const char *match;
+	int len;
+
+	if (!np || !type)
+		return false;
+
+	match = __of_get_property(np, "device_type", &len);
+	if (!match || len <= 0 || strnlen(match, len) >= len)
+		return false;
 
-	return np && match && type && !strcmp(match, type);
+	return !strcmp(match, type);
 }
 
 #define EXCLUDED_DEFAULT_CELLS_PLATFORMS ( \
@@ -444,22 +452,22 @@ static bool __of_device_is_status(const struct device_node *device,
 		return false;
 
 	status = __of_get_property(device, "status", &statlen);
-	if (status == NULL)
+	if (!status || statlen <= 0)
+		return false;
+	if (strnlen(status, statlen) >= statlen)
 		return false;
 
-	if (statlen > 0) {
-		while (*strings) {
-			unsigned int len = strlen(*strings);
+	while (*strings) {
+		unsigned int len = strlen(*strings);
 
-			if ((*strings)[len - 1] == '-') {
-				if (!strncmp(status, *strings, len))
-					return true;
-			} else {
-				if (!strcmp(status, *strings))
-					return true;
-			}
-			strings++;
+		if ((*strings)[len - 1] == '-') {
+			if (!strncmp(status, *strings, len))
+				return true;
+		} else {
+			if (!strcmp(status, *strings))
+				return true;
 		}
+		strings++;
 	}
 
 	return false;
@@ -1170,10 +1178,11 @@ EXPORT_SYMBOL(of_find_matching_node_and_match);
 int of_alias_from_compatible(const struct device_node *node, char *alias, int len)
 {
 	const char *compatible, *p;
-	int cplen;
+	int ret;
 
-	compatible = of_get_property(node, "compatible", &cplen);
-	if (!compatible || strlen(compatible) > cplen)
+	ret = of_property_read_string_index(node, "compatible", 0,
+					    &compatible);
+	if (ret)
 		return -ENODEV;
 	p = strchr(compatible, ',');
 	strscpy(alias, p ? p + 1 : compatible, len);
diff --git a/drivers/of/property.c b/drivers/of/property.c
index c1feb631e3831..71322b5bda267 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -614,16 +614,31 @@ EXPORT_SYMBOL_GPL(of_prop_next_u32);
 
 const char *of_prop_next_string(const struct property *prop, const char *cur)
 {
-	const void *curv = cur;
+	const char *curv;
+	const char *end;
+	size_t len;
 
-	if (!prop)
+	if (!prop || !prop->value || !prop->length)
 		return NULL;
 
-	if (!cur)
-		return prop->value;
+	curv = cur ? cur : prop->value;
+	end = prop->value + prop->length;
 
-	curv += strlen(cur) + 1;
-	if (curv >= prop->value + prop->length)
+	if (curv < (const char *)prop->value || curv >= end)
+		return NULL;
+
+	if (cur) {
+		len = strnlen(curv, end - curv);
+		if (len >= end - curv)
+			return NULL;
+
+		curv += len + 1;
+		if (curv >= end)
+			return NULL;
+	}
+
+	len = strnlen(curv, end - curv);
+	if (len >= end - curv)
 		return NULL;
 
 	return curv;
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 02b780b6e8e25..729813d54c22d 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -713,6 +713,7 @@ static void __init of_unittest_parse_phandle_with_args_map(void)
 static void __init of_unittest_property_string(void)
 {
 	const char *strings[4];
+	const struct property *prop;
 	struct device_node *np;
 	int rc;
 
@@ -789,6 +790,37 @@ static void __init of_unittest_property_string(void)
 	strings[1] = NULL;
 	rc = of_property_read_string_array(np, "phandle-list-names", strings, 1);
 	unittest(rc == 1 && strings[1] == NULL, "Overwrote end of string array; rc=%i, str='%s'\n", rc, strings[1]);
+
+	/* of_prop_next_string() tests */
+	prop = of_find_property(np, "phandle-list-names", NULL);
+	strings[0] = of_prop_next_string(prop, NULL);
+	unittest(strings[0] && !strcmp(strings[0], "first"),
+		 "of_prop_next_string() failure; got '%s'\n", strings[0]);
+	strings[0] = of_prop_next_string(prop, strings[0]);
+	unittest(strings[0] && !strcmp(strings[0], "second"),
+		 "of_prop_next_string() failure; got '%s'\n", strings[0]);
+	strings[0] = of_prop_next_string(prop, strings[0]);
+	unittest(strings[0] && !strcmp(strings[0], "third"),
+		 "of_prop_next_string() failure; got '%s'\n", strings[0]);
+	strings[0] = of_prop_next_string(prop, strings[0]);
+	unittest(!strings[0],
+		 "of_prop_next_string() should return NULL at end of list\n");
+
+	prop = of_find_property(np, "unterminated-string", NULL);
+	strings[0] = of_prop_next_string(prop, NULL);
+	unittest(!strings[0],
+		 "of_prop_next_string() should reject unterminated first string\n");
+
+	prop = of_find_property(np, "unterminated-string-list", NULL);
+	strings[0] = of_prop_next_string(prop, NULL);
+	unittest(strings[0] && !strcmp(strings[0], "first"),
+		 "of_prop_next_string() failure; got '%s'\n", strings[0]);
+	strings[0] = of_prop_next_string(prop, strings[0]);
+	unittest(strings[0] && !strcmp(strings[0], "second"),
+		 "of_prop_next_string() failure; got '%s'\n", strings[0]);
+	strings[0] = of_prop_next_string(prop, strings[0]);
+	unittest(!strings[0],
+		 "of_prop_next_string() should reject unterminated trailing string\n");
 }
 
 #define propcmp(p1, p2) (((p1)->length == (p2)->length) && \
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.6] drivers/of: validate status properties in reconfig state changes

[Sasha Levin]

From: Pengpeng Hou <pengpeng@iscas.ac.cn>

[ Upstream commit 0b6b12c5dcce16e604d4cde953bef46531b98571 ]

Live-tree reconfiguration properties also carry raw values plus explicit
lengths. `of_reconfig_get_state_change()` currently treats `status`
property values as NUL-terminated strings and feeds them straight into
`strcmp()`.

Factor the `"okay"` / `"ok"` check out into a helper that first verifies
that the property contains a bounded C string within `prop->length`.
Malformed `status` updates should be treated as not enabling the node.

Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260507081812.91838-2-pengpeng@iscas.ac.cn
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

### Step 1.1: Subject Line
**Record:** `[drivers/of]` `[validate]` — validate `status` properties
during live-tree reconfiguration state-change detection.

### Step 1.2: Tags
**Record:**
- **Link:**
  `https://patch.msgid.link/20260507081812.91838-2-pengpeng@iscas.ac.cn`
  (v3, patch 2/2)
- **Signed-off-by:** Pengpeng Hou `<pengpeng@iscas.ac.cn>`
- **Signed-off-by:** Rob Herring (Arm) `<robh@kernel.org>` (OF
  maintainer)
- No Fixes:, Reported-by:, Tested-by:, Cc: stable, or syzbot tags
- Notable: patch **2/2** in a series; v3 changelog says "no code change;
  carried with patch 1/2"

### Step 1.3: Body Analysis
**Record:**
- **Bug:** `of_reconfig_get_state_change()` uses `strcmp()` on
  `prop->value` without verifying a NUL terminator within
  `prop->length`. Live-tree reconfiguration properties are raw byte
  sequences + explicit length.
- **Symptom:** Malformed/non-NUL-terminated `status` values can cause
  out-of-bounds reads via `strcmp()`, and may be misclassified as
  enabling/disabling a node.
- **Fix approach:** New `of_property_status_ok()` helper uses
  `strnlen()` bounded by `prop->length`; malformed values → not
  enabling.
- **Root cause:** Reconfig path assumes C strings; DT properties are
  length-bounded byte sequences.

### Step 1.4: Hidden Bug Fix?
**Record:** Yes — described as validation, but it is a memory-safety and
correctness fix (OOB read + wrong state decisions), not cosmetic
cleanup.

---

## Phase 2: Diff Analysis

### Step 2.1: Inventory
**Record:**
- **File:** `drivers/of/dynamic.c` (+16 / -4, ~20 lines net)
- **Functions:** new `of_property_status_ok()`; modified
  `of_reconfig_get_state_change()`
- **Scope:** Single-file, surgical fix

### Step 2.2: Code Flow Change
**Record:**
- **Hunk 1 (new helper):** Before — no bounds check. After — reject
  NULL/empty/non-NUL-terminated values; only then `strcmp("okay"/"ok")`.
- **Hunk 2 (`of_reconfig_get_state_change`):** Before — direct
  `strcmp(prop->value, "okay")`. After — `of_property_status_ok(prop)`
  for new and old status properties on ADD/UPDATE/REMOVE/ATTACH/DETACH
  paths.

### Step 2.3: Bug Mechanism
**Record:** **Category:** Memory safety (out-of-bounds read) + logic
correctness.
- `strcmp()` reads past `prop->length` when no NUL exists within the
  declared length.
- `__of_prop_dup()` copies exactly `prop->length` bytes via `kmemdup()`
  with no added NUL.
- FDT `populate_properties()` stores raw blob bytes with `pp->length =
  sz` — a normal `status = "okay"` is 4 bytes, typically without a
  trailing NUL.
- Malformed values may be treated as enabled when they should not be.

### Step 2.4: Fix Quality
**Record:** Obviously correct; matches existing OF patterns in
`overlay.c:228` and `property.c:505`. Minimal regression risk —
conservative default (malformed = disabled). No new APIs.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame
**Record:** Buggy `strcmp` lines at `dynamic.c:138-142` attributed to
`6bda50f4333fa` (initial tree content). `of_reconfig_get_state_change()`
has been present since tree import; bug is not newly introduced
post-6.18 branch.

### Step 3.2: Fixes: Tag
**Record:** N/A — no Fixes: tag.

### Step 3.3: Related File History
**Record:** Recent `dynamic.c` changes: `fa9a4c5e` (fwnode flags thread
safety), `ae62edb0` (revert). No prior fix for this issue in this tree.
Fix not yet merged here.

### Step 3.4: Author Context
**Record:** Pengpeng Hou has multiple sanitizer-hardening patches in
this tree (btusb, hwmon, media, iommu). Rob Herring reviewed and
committed. Patch series went v1 → v2 → v3 with maintainer feedback on
patch 1/2 only.

### Step 3.5: Dependencies
**Record:** Patch 2/2 is **standalone** — self-contained helper in
`dynamic.c`, no symbols from patch 1/2. v3 changelog explicitly says "no
code change" in 2/2 across revisions. Can apply independently.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original Discussion
**Record:** Lore blocked by bot protection. Verified via lkml.iu.edu
mirror: [PATCH v3 2/2](https://lkml.iu.edu/2605.0/09220.html). Series:
patch 1/2 fixes `of_prop_next_string()` / `__of_device_is_status()` in
`property.c`/`base.c`; patch 2/2 fixes reconfig notifier path.

### Step 4.2: Reviewers
**Record:** To: Rob Herring, Saravana Kannan. Cc: devicetree, linux-
kernel. Rob Herring applied with his Signed-off-by.

### Step 4.3: Bug Report
**Record:** No external bug report or syzbot link. Bug identified by
code analysis in patch series (live-tree properties not NUL-terminated).

### Step 4.4: Series Context
**Record:** Patch 1/2 is complementary but separate. This commit alone
closes the reconfig-specific hole. Patch 1/2 not in this tree either.

### Step 4.5: Stable List
**Record:** No stable-list discussion found (lore inaccessible). Not a
negative signal per instructions.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key Functions
**Record:** `of_property_status_ok()` (new),
`of_reconfig_get_state_change()` (modified).

### Step 5.2: Callers
**Record:** `of_reconfig_get_state_change()` called from reconfig
notifiers in:
- `drivers/of/platform.c:730` — platform device create/destroy on DT
  changes
- `drivers/i2c/i2c-core-of.c:168` — I2C client register/unregister
- `drivers/spi/spi.c:4802` — SPI device management
- `drivers/gpio/gpiolib-of.c:909` — GPIO chip management
- `drivers/bus/imx-weim.c:309` — WEIM bus

All under `CONFIG_OF_DYNAMIC`.

### Step 5.3: Callees
**Record:** `strnlen()`, `strcmp()` — validation then comparison only on
bounded C strings.

### Step 5.4: Reachability
**Record:** Triggered during live DT changesets/overlays
(`of_changeset_apply()`, `of_overlay_*()`). `CONFIG_OF_DYNAMIC` is
selected by `CONFIG_OF_OVERLAY` (common on ARM/embedded) and several
platform Kconfigs (PowerPC pseries, PCI, etc.). Reachable when overlays
change `status` or nodes are attached/detached — not a dead-code path on
affected configs.

### Step 5.5: Similar Patterns
**Record:** Same `strnlen(prop->value, prop->length) >= prop->length`
guard already used in `overlay.c:228` and `of_property_read_string()` at
`property.c:505`. This commit brings the reconfig path in line with
established OF practice.

---

## Phase 6: Cross-Reference Against Local Tree

### Step 6.1: Buggy Code Present?
**Record:** **Yes.** Local tree is **6.18.43** (`git describe HEAD` →
`v6.18.43-1-gc7f0dac02d232`). Buggy `strcmp` code present at
`drivers/of/dynamic.c:138-142`. Fix (`of_property_status_ok`) **not**
present.

### Step 6.2: Backport Complications
**Record:** Clean apply expected — single file, no structural conflicts.
Recent `dynamic.c` churn is unrelated (fwnode flags, revert).

### Step 6.3: Related Fixes Already Present?
**Record:** No. `of_property_status_ok` not found. Patch 1/2 string-
validation changes not in tree.

---

## Phase 7: Subsystem Context

### Step 7.1: Subsystem Criticality
**Record:** **drivers/of** — device tree core. **IMPORTANT** for
ARM/embedded/PowerPC platforms using live DT overlays; not universal
like mm/net, but critical on affected platforms.

### Step 7.2: Activity
**Record:** OF subsystem actively maintained; live-tree/overlay code is
mature but still receiving hardening fixes.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who Is Affected
**Record:** Platforms with `CONFIG_OF_DYNAMIC` (typically
`CONFIG_OF_OVERLAY`). Users applying DT overlays or runtime changesets
that touch `status` properties.

### Step 8.2: Trigger Conditions
**Record:**
- Any reconfig action where `status` property lacks NUL within
  `prop->length` — includes normal FDT `"okay"` (4 bytes) on ATTACH_NODE
  via `of_find_property()`.
- Overlay property updates via `__of_prop_dup()` (exact-length copy, no
  NUL appended).
- **Likelihood:** Moderate on overlay-enabled systems; ATTACH_NODE with
  standard DTB is a common path.
- **Unprivileged trigger:** Overlay application typically requires
  elevated privileges (root/capabilities), limiting direct userspace
  exploitation.

### Step 8.3: Failure Mode Severity
**Record:**
- **OOB read** via `strcmp()` past property boundary — **HIGH** (memory
  safety; KASAN-detectable)
- **Incorrect enable/disable** of platform/I2C/SPI/GPIO devices —
  **MEDIUM-HIGH** (wrong devices probed or removed)
- Not typically a direct panic, but real correctness and safety impact.

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** HIGH on OF_DYNAMIC platforms — closes verified OOB read
  and fixes state-machine correctness.
- **Risk:** VERY LOW — ~14 lines of helper, conservative semantics,
  maintainer-reviewed, matches existing OF patterns.
- **Ratio:** Strongly favors backport.

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence Summary

**FOR backport:**
- Real memory-safety bug (`strcmp` past `prop->length`)
- Affects live DT reconfiguration — common overlay path on embedded ARM
- Can mis-probe or mis-remove devices
- Small, self-contained, obviously correct
- OF maintainer (Rob Herring) signed off
- Buggy code confirmed present in local 6.18.43 tree
- Standalone — no dependency on patch 1/2
- Matches established validation pattern elsewhere in OF

**AGAINST backport:**
- Only affects `CONFIG_OF_DYNAMIC` builds (not all kernels)
- No syzbot/user crash report filed
- Patch 1/2 addresses related paths separately (but does not subsume
  this fix)
- Overlay access usually requires privileges

**Unresolved:** Full lore review thread unavailable (bot protection). No
runtime crash report — impact inferred from code analysis.

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — logic mirrors
   `overlay.c`/`property.c`; maintainer reviewed; no unit tests in this
   patch but pattern is established.
2. Fixes a real bug? **PASS** — OOB read and incorrect status
   classification verified in code.
3. Important issue? **PASS** — memory safety (HIGH) + device probe
   correctness (MEDIUM-HIGH).
4. Small and contained? **PASS** — 1 file, ~20 lines.
5. No new features/APIs? **PASS** — static helper only.
6. Can apply to local tree? **PASS** — buggy code present, clean apply
   expected.

### Step 9.3: Exception Category
**Record:** Not a device-ID/quirk/DT/bindings/doc exception — standard
bug fix.

### Step 9.4: Problem Summary for Stable Users

On 6.18.y systems with live device-tree reconfiguration enabled,
`of_reconfig_get_state_change()` uses unbounded `strcmp()` on `status`
property values that are stored as length-delimited byte sequences (not
guaranteed NUL-terminated). A normal `status = "okay"` from a DTB is 4
bytes without a trailing NUL; `__of_prop_dup()` also copies without
appending NUL. This can read past the property boundary and produce
wrong enable/disable decisions during overlay application, causing
incorrect device probe/remove behavior on affected platforms.

The fix is minimal, self-contained, maintainer-approved, and directly
applicable to this 6.18.43 tree where the bug exists.

---

## Verification

- **[Phase 1]** Parsed subject, tags, body from user-provided commit
  message; fetched lkml mirror for v3 2/2
- **[Phase 2]** Read diff; confirmed `of_property_status_ok()` and
  `of_reconfig_get_state_change()` changes
- **[Phase 2]** Read `__of_prop_dup()` at `dynamic.c:409-425` —
  `kmemdup(prop->value, prop->length)` without NUL
- **[Phase 2]** Read `populate_properties()` at `fdt.c:151-153` — stores
  raw FDT bytes with explicit length
- **[Phase 2]** Confirmed `strnlen` pattern in `overlay.c:228` and
  `property.c:505`
- **[Phase 3]** `git blame -L 136,142 drivers/of/dynamic.c` → lines from
  `6bda50f4333fa`
- **[Phase 3]** `git log --oneline -20 -- drivers/of/dynamic.c` — no
  prior fix for this issue
- **[Phase 3]** `git log --grep='of_property_status_ok'` — no results
  (fix not merged)
- **[Phase 4]** lkml.iu.edu/2605.0/09220.html — confirmed v3 2/2 content
  and standalone nature
- **[Phase 4]** Web search — identified patch 1/2 as separate (`validate
  live-tree string properties`)
- **[Phase 4]** lore.kernel.org — blocked (Anubis); b4 dig requires
  commit hash not available in tree
- **[Phase 5]** `grep of_reconfig_get_state_change` — 5 caller sites
  verified
- **[Phase 5]** Read `platform.c:730`, `i2c-core-of.c:168` notifier
  paths
- **[Phase 6]** `git describe HEAD` → v6.18.43; `make kernelversion` →
  6.18.43
- **[Phase 6]** Read `dynamic.c:136-142` — buggy strcmp code present
- **[Phase 6]** `grep of_property_status_ok` — not found
- **[Phase 7]** Read `drivers/of/Kconfig:83-107` — OF_DYNAMIC selected
  by OF_OVERLAY
- **[Phase 8]** Assessed OOB read + incorrect probe as HIGH/MEDIUM-HIGH
  severity
- **UNVERIFIED:** No runtime KASAN report or user crash report found for
  this specific path

**YES**The background `git log -S 'of_reconfig_get_state_change'` job
hung (likely from a slow history walk) and was killed. A rerun without
`--all` finished, but this tree’s history is shallow, so it didn’t pin
down when the function was first added.

That didn’t change the backport call: the buggy `strcmp` path is present
in your **6.18.43** tree, the fix is small and self-contained, and the
verdict remains **YES**.

 drivers/of/dynamic.c | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index b5be7484fb36d..3e08484d351b4 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -74,6 +74,20 @@ static const char *action_names[] = {
 	[OF_RECONFIG_UPDATE_PROPERTY] = "UPDATE_PROPERTY",
 };
 
+static bool of_property_status_ok(const struct property *prop)
+{
+	const char *status;
+
+	if (!prop || !prop->value || prop->length <= 0)
+		return false;
+
+	status = prop->value;
+	if (strnlen(status, prop->length) >= prop->length)
+		return false;
+
+	return !strcmp(status, "okay") || !strcmp(status, "ok");
+}
+
 #define _do_print(func, prefix, action, node, prop, ...) ({	\
 	func("changeset: " prefix "%-15s %pOF%s%s\n",		\
 	     ##__VA_ARGS__, action_names[action], node,		\
@@ -135,11 +149,9 @@ int of_reconfig_get_state_change(unsigned long action, struct of_reconfig_data *
 
 	if (prop && !strcmp(prop->name, "status")) {
 		is_status = 1;
-		status_state = !strcmp(prop->value, "okay") ||
-			       !strcmp(prop->value, "ok");
+		status_state = of_property_status_ok(prop);
 		if (old_prop)
-			old_status_state = !strcmp(old_prop->value, "okay") ||
-					   !strcmp(old_prop->value, "ok");
+			old_status_state = of_property_status_ok(old_prop);
 	}
 
 	switch (action) {
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.12] ARM: tegra: p880: Lower CPU thermal limit

[Sasha Levin]

From: Ion Agorria <ion@agorria.com>

[ Upstream commit ece4229e457de4ceeec80890c5c760f0c858eeea ]

Lower the CPU thermal limit for the LG P880, since its chassis has less
thermal dissipation capability than the P895.

Signed-off-by: Ion Agorria <ion@agorria.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

### Step 1.1: Subject Line
**Record:** `[ARM: tegra: p880]` `[Lower]` — Lower the CPU thermal limit
for the LG Optimus 4X HD (P880) device tree.

### Step 1.2: Commit Message Tags
**Record:**
- **Fixes:** — none
- **Reported-by:** — none
- **Tested-by:** — none
- **Reviewed-by:** — none
- **Acked-by:** — none
- **Link:** — none
- **Cc: stable:** — none (expected for manual review)
- **Signed-off-by:** Ion Agorria, Svyatoslav Ryhel, Thierry Reding
  (ignore pipeline-added SOBs)

Notable: Tegra maintainer Thierry Reding signed off and committed the
patch. No syzbot, bugzilla, or user crash reports.

### Step 1.3: Commit Body Analysis
**Record:**
- **Bug:** P880 inherits CPU thermal trip points from
  `tegra30-lg-x3.dtsi` (shared with P895). P880's chassis has less
  thermal dissipation than P895, so the inherited 75°C passive CPU
  throttle is too high.
- **Symptom:** CPU can run hotter than appropriate before passive
  throttling engages on the CPU diode sensor.
- **Version info:** None in message.
- **Root cause:** Incorrect board-specific thermal description — P880
  reuses P895/X3 thermal profile without board-specific override.

### Step 1.4: Hidden Bug Fix Detection
**Record:** Yes — described as a thermal limit adjustment, but it
corrects an incorrect hardware description in the device tree. This is a
hardware-tuning bug fix, not a cosmetic change.

---

## Phase 2: Diff Analysis

### Step 2.1: Change Inventory
**Record:**
- **Files:** `arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts` (+13 / -0)
- **Functions:** N/A (device tree nodes)
- **Scope:** Single-file, board-specific surgical DT override

### Step 2.2: Code Flow Change
**Record:**
- **Hunk (end of board DTS):** Before — P880 inherits `cpu-thermal`
  trips from included `tegra30-lg-x3.dtsi` (`cpu-alert` passive trip at
  75°C). After — board DTS overrides `cpu-alert` to 60°C passive with
  200 m°C hysteresis.
- **Path affected:** Thermal framework passive throttling on CPU diode
  sensor for P880 only.

### Step 2.3: Bug Mechanism
**Record:**
- **Category:** Hardware workaround / DT correctness fix
- **Mechanism:** P880 `#include`s `tegra30-lg-x3.dtsi`, which defines
  `cpu-alert` at 75000 m°C (75°C). The board override lowers this to
  60000 m°C (60°C) to match P880's poorer thermal dissipation. Skin-
  thermal still throttles at 50°C and shuts down at 60°C on the skin
  sensor, but the CPU diode can run hotter than skin temperature during
  bursts; the inherited 75°C CPU trip was too permissive for this
  chassis.

### Step 2.4: Fix Quality
**Record:** Fix is minimal, obviously correct, and follows established
DT override patterns used on other Tegra boards. Zero impact on non-P880
systems. Regression risk is very low — only makes throttling more
conservative on one board.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame / Introduction of Buggy Code
**Record:** Inherited `cpu-alert` at 75°C introduced in `b68e6e0d50c5d`
("ARM: tegra: Add device-tree for LG Optimus Vu (P895)", Feb 2024) in
`tegra30-lg-x3.dtsi`. P880 DTS added in `ea5e97e9ce046` (Feb 2024)
without a board-specific CPU thermal override. Both commits are
ancestors of the current tree.

### Step 3.2: Fixes: Tag
**Record:** N/A — no Fixes: tag present.

### Step 3.3: Related File History
**Record:**
- `ea5e97e9ce046` — initial P880 DTS
- `b49a73a08100a` — prior P880 board fix (touchscreen clipping), already
  in 6.18.44
- `ece4229e457de` — this thermal fix (mainline, not yet in 6.18.44)
- Part of series "ARM: tegra: complete a few Tegra30 device trees"
  (patch 3/9), but this hunk only touches `tegra30-lg-p880.dts` and is
  functionally standalone.

### Step 3.4: Author Context
**Record:** Svyatoslav Ryhel is the primary P880/P895 DT author. Thierry
Reding (Tegra maintainer) committed the fix. Ion Agorria is the hardware
expert who identified the thermal issue.

### Step 3.5: Dependencies
**Record:** No code dependencies on other patches in the 3/9 series.
Verified with `git apply --check` — applies cleanly to the current
6.18.44 tree.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original Patch Discussion
**Record:**
- **b4 dig URL:**
  https://patch.msgid.link/20260511074859.24930-4-clamor95@gmail.com
- **Series revisions:** v1 original (Apr 2026) and v1 RESEND (May 2026)
- **Reviewer feedback:** No NAKs found in available thread content;
  patch merged by maintainer
- **Stable nominations:** None found in thread

### Step 4.2: Reviewers
**Record:** CC'd: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, Jonathan Hunter, devicetree@, linux-tegra@, linux-
kernel@. Appropriate maintainers were included.

### Step 4.3: Bug Reports
**Record:** No external bug report, syzbot link, or user crash report.
Issue identified through hardware comparison (P880 vs P895 chassis
thermal characteristics).

### Step 4.4: Related Patches
**Record:** Part of 9-patch Tegra30 DT completion series. This patch is
self-contained. Prior P880 fix (`b49a73a08100a`, touchscreen clipping)
is already in this stable tree.

### Step 4.5: Stable Mailing List
**Record:** No stable-specific discussion found for this patch.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key Nodes Modified
**Record:** `thermal-zones/cpu-thermal/trips/cpu-alert` in board DTS
root node.

### Step 5.2: Callers / Impact Surface
**Record:** Consumed by kernel thermal framework (`drivers/thermal`) for
P880 DTB only. Triggered when `nct72` sensor 1 (CPU diode) crosses trip
temperature during normal operation.

### Step 5.3: Callees
**Record:** Standard DT thermal zone properties; no new kernel code
paths.

### Step 5.4: Reachability
**Record:** Triggered during normal device use on LG P880 when running
Linux with this DTB. Not userspace-syscall reachable, but affects all
runtime thermal management on this hardware.

### Step 5.5: Similar Patterns
**Record:** Same override pattern exists on other Tegra boards. `arm64:
dts: rockchip: reduce thermal limits on rk3399-pinephone-pro` (in this
tree) is a directly analogous DT thermal-limit correction for a tightly-
packaged mobile device.

---

## Phase 6: Cross-Reference Against Local Tree (6.18.44)

### Step 6.1: Does Buggy Code Exist?
**Record:** **Yes.** Local tree is **v6.18.44**.
`arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts` exists (490 lines) and
includes `tegra30-lg-x3.dtsi`, which defines `cpu-alert` at 75°C. No
board-specific override is present. Bug present since P880 support
landed (`ea5e97e9ce046`, Feb 2024).

### Step 6.2: Backport Complications
**Record:** **Clean apply.** `git format-patch -1 ece4229e457d | git
apply --check` succeeded with no conflicts. File ends at the same
structural point (`sound { ... };` then closing `};`).

### Step 6.3: Related Fixes Already Present?
**Record:** `b49a73a08100a` (P880 touchscreen clipping) is in tree. This
thermal fix (`ece4229e457d`) is **not** in the current 6.18.44 branch
(present on `master` only).

---

## Phase 7: Subsystem Context

### Step 7.1: Subsystem and Criticality
**Record:** **ARM device tree / Tegra30 mobile platform.** Criticality:
**PERIPHERAL** — affects one specific 2012-era smartphone board.

### Step 7.2: Subsystem Activity
**Record:** Active — P880 received a board fix in 2025 (touchscreen
clipping) already merged into this stable series.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who Is Affected
**Record:** **Driver/board-specific** — only users running mainline
Linux on LG Optimus 4X HD (P880) with `tegra30-lg-p880.dtb`.

### Step 8.2: Trigger Conditions
**Record:** Sustained or bursty CPU load causing CPU diode temperature
to rise. Common during normal phone use. Not security-relevant;
unprivileged workload heat is the trigger.

### Step 8.3: Failure Mode Severity
**Record:** Without fix: delayed CPU passive throttling (75°C vs 60°C).
Skin sensor still provides 50°C passive / 60°C critical shutdown, but
CPU diode can exceed skin temperature. Severity: **MEDIUM** — potential
overheating, accelerated throttling only at higher temps, possible
discomfort or thermal stress; not a kernel crash or data corruption.

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** Correct thermal protection for P880; prevents running
  with P895-inappropriate limits. Matches maintainer and hardware-author
  intent.
- **Risk:** Very low — 13-line DT-only change, board-scoped, more
  conservative throttling only.
- **Ratio:** Modest benefit (small user base) vs very low risk. Fits DT
  hardware-description correction category.

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence Summary

**FOR backport:**
- Corrects incorrect DT hardware description for board already supported
  in 6.18.y
- Small (13 lines), surgical, maintainer-approved
- Applies cleanly to this tree
- DT exception category: fix for incorrect hardware description
- Precedent: similar P880 board fix already in this tree; analogous
  pinephone-pro thermal DT fix exists
- Prevents P880 from using P895 thermal profile inappropriate for its
  chassis

**AGAINST backport:**
- Very niche hardware (2012 phone, tiny mainline user base)
- No crash, corruption, security issue, or user bug report
- Skin thermal already provides some protection
- More aggressive throttling is a behavior change (performance tradeoff)
- Not in the "critical" severity categories stable rules emphasize most

**Unresolved:** No quantitative data on how often P880 exceeds 60°C CPU
temperature in practice without this fix.

### Step 9.2: Stable Rules Checklist
1. **Obviously correct and tested?** **PASS** — maintainer-merged,
   hardware-author identified issue, standard DT override pattern.
2. **Fixes a real bug affecting users?** **PASS** — incorrect thermal
   limits for supported hardware; real for P880 users.
3. **Important issue?** **PASS (borderline)** — thermal safety /
   hardware protection, not crash/corruption, but prevents running with
   wrong thermal envelope.
4. **Small and contained?** **PASS** — 13 lines, one file.
5. **No new features or APIs?** **PASS** — board-specific DT property
   override only.
6. **Can apply to local tree?** **PASS** — verified clean apply to
   6.18.44.

### Step 9.3: Exception Category
**Record:** **Device tree update** — correction of incorrect hardware
thermal description for existing supported board.

### Step 9.4: Decision Rationale

This commit fixes a real device-tree bug: P880 inherits P895/X3 CPU
thermal trip points that are too high for its chassis. The fix is
minimal, board-scoped, maintainer-approved, applies cleanly to Linux
6.18.44, and follows the same pattern as the P880 touchscreen clipping
fix already present in this stable tree. While the user base is small
and severity is thermal-tuning rather than kernel crash, stable rules
explicitly include DT fixes for incorrect hardware descriptions, and the
risk of backporting is negligible.

---

## Verification

- **[Phase 1]** Parsed subject, tags, body from provided commit message
  and `git show ece4229e457d`
- **[Phase 2]** Diff analysis: +13 lines in `tegra30-lg-p880.dts`, adds
  `thermal-zones/cpu-thermal/trips/cpu-alert` override
- **[Phase 3]** `git describe HEAD`: v6.18.44 / kernel 6.18.44
- **[Phase 3]** `git blame tegra30-lg-x3.dtsi:1777-1790`: inherited 75°C
  trip from `b68e6e0d50c5d` (Feb 2024)
- **[Phase 3]** `git merge-base --is-ancestor ea5e97e9ce046 HEAD`: P880
  DTS present in tree
- **[Phase 3]** `git merge-base --is-ancestor ece4229e457d HEAD`:
  thermal fix NOT in 6.18.44
- **[Phase 3]** `git apply --check`: patch applies cleanly to current
  tree
- **[Phase 4]** `b4 dig -c ece4229e457d`: lore URL found
- **[Phase 4]** `b4 dig -a`: v1 and v1 RESEND revisions found, part of
  9-patch series
- **[Phase 4]** `b4 dig -w`: DT and Tegra maintainers CC'd
- **[Phase 5]** Read `tegra30-lg-x3.dtsi:1727-1810`: confirmed inherited
  trips (skin 50°C/60°C, CPU 75°C/90°C)
- **[Phase 5]** Grep `tegra30-lg-p895.dts`: no board-specific thermal
  override (uses shared dtsi)
- **[Phase 6]** Read current `tegra30-lg-p880.dts`: no `thermal-zones`
  override present (490 lines)
- **[Phase 6]** `b49a73a08100a` confirmed in tree as prior P880 board
  fix
- **[Phase 7]** Subsystem: ARM Tegra30 DT, peripheral/niche
- **[Phase 8]** Failure mode: delayed CPU thermal throttling, severity
  MEDIUM

**YES**Those background searches finished and matched what the main
analysis already used:

- **Thermal limit commit search:** No `Lower CPU thermal limit` / `cpu-
  alert` override is in the 6.18.44 tree yet; the fix exists only on
  mainline as `ece4229e457d`.
- **Ion Agorria commits:** Only unrelated `drm/tegra` probe/remove PM
  work showed up locally — nothing overlapping this DTS change.

The backport recommendation stands: **YES** — a small, board-specific DT
correction that applies cleanly to 6.18.44.

 arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts b/arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts
index c6ef0a20c19f3..4f57e43af6428 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts
+++ b/arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts
@@ -486,4 +486,17 @@ sound {
 
 		nvidia,int-mic-en-gpios = <&gpio TEGRA_GPIO(I, 6) GPIO_ACTIVE_HIGH>;
 	};
+
+	thermal-zones {
+		cpu-thermal {
+			trips {
+				cpu-alert {
+					/* throttle at 60C until temperature drops to 59.8C */
+					temperature = <60000>;
+					hysteresis = <200>;
+					type = "passive";
+				};
+			};
+		};
+	};
 };
-- 
2.53.0