[PATCH AUTOSEL 7.0-5.10] ALSA: aoa/tas: Fix OF node leak on probe failure

[PATCH AUTOSEL 7.0-5.10] ALSA: aoa/tas: Fix OF node leak on probe failure

[Sasha Levin]

From: wangdicheng <wangdicheng@kylinos.cn>

[ Upstream commit 1558905669e4da922fbaa7cf6507eb14779bffbd ]

Add missing of_node_put() in the error path.

Signed-off-by: wangdicheng <wangdicheng@kylinos.cn>
Link: https://patch.msgid.link/20260402023604.54682-1-wangdich9700@163.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a complete analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem**: `ALSA: aoa/tas` (ALSA Apple Onboard Audio, TAS codec)
- **Action verb**: "Fix"
- **Summary**: Fix OF (Open Firmware) node reference leak on probe
  failure path

### Step 1.2: Tags
- **Signed-off-by**: wangdicheng <wangdicheng@kylinos.cn> (author)
- **Link**:
  `https://patch.msgid.link/20260402023604.54682-1-wangdich9700@163.com`
- **Signed-off-by**: Takashi Iwai <tiwai@suse.de> (ALSA subsystem
  maintainer)
- No Fixes: tag, no Cc: stable, no Reported-by — all expected for
  AUTOSEL candidates
- Takashi Iwai as committer is a strong signal: he is the ALSA
  maintainer

### Step 1.3: Commit Body
The message is very brief: "Add missing of_node_put() in the error
path." This concisely describes a reference counting bug (missing put on
error path).

### Step 1.4: Hidden Bug Fix
This is an explicit bug fix — no disguise. The commit directly states it
fixes a missing `of_node_put()`.

Record: [Reference counting bug fix — missing of_node_put on error path
in probe function]

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **Files changed**: 1 (`sound/aoa/codecs/tas.c`)
- **Lines added**: 1
- **Lines removed**: 0
- **Function modified**: `tas_i2c_probe()` — the `fail:` error path
- **Scope**: Single-file, single-line, surgical fix

### Step 2.2: Code Flow Change
Before the fix, the `fail:` path in `tas_i2c_probe()`:

```873:876:sound/aoa/codecs/tas.c
 fail:
        mutex_destroy(&tas->mtx);
        kfree(tas);
        return -EINVAL;
```

After the fix, `of_node_put(tas->codec.node)` is added between
`mutex_destroy` and `kfree`. The reference taken at line 864
(`tas->codec.node = of_node_get(node)`) is now properly released.

### Step 2.3: Bug Mechanism
**Category**: Reference counting bug (OF node reference leak)
- At line 864, `of_node_get(node)` increments the OF node's refcount and
  stores the result in `tas->codec.node`
- If `aoa_codec_register()` fails at line 866, execution jumps to
  `fail:`
- Without the fix, the `fail:` path calls `kfree(tas)` which frees the
  struct holding the only pointer to the refcounted node — the refcount
  is never decremented
- The `tas_i2c_remove()` function at line 885 correctly calls
  `of_node_put(tas->codec.node)`, confirming the expected pattern

### Step 2.4: Fix Quality
- **Obviously correct**: Yes — mirrors the cleanup pattern already in
  `tas_i2c_remove()` (line 885)
- **Minimal**: Yes — 1 line added
- **Regression risk**: Essentially zero — only adds cleanup on an error
  path
- **Placement**: Correct — `of_node_put(tas->codec.node)` is placed
  before `kfree(tas)` so the pointer is still valid

Record: [1 file, +1 line, reference counting fix on error path,
obviously correct, zero regression risk]

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
The buggy code (`of_node_get(node)` without matching put on error path)
was introduced in commit `f3d9478b2ce468` by Johannes Berg on 2006-06-21
("[ALSA] snd-aoa: add snd-aoa"). This is the initial commit for the
entire snd-aoa subsystem, from the v2.6.18 era.

Record: [Bug has been present since 2006 (v2.6.18). Present in ALL
stable trees.]

### Step 3.2: No Fixes: Tag
No Fixes: tag present — expected for AUTOSEL candidates. However, the
implicit fix target is `f3d9478b2ce468`.

### Step 3.3: File History
The file has had only minor maintenance changes (strscpy, guard()
conversions, kzalloc_obj treewide changes). No related of_node_put fixes
for this specific path.

The related commit `222bce5eb88d1` ("ALSA: snd-aoa: add of_node_put() in
error path") fixed a similar bug in `sound/aoa/core/gpio-feature.c` —
different file, same subsystem, same bug class.

### Step 3.4: Author
The author (wangdicheng) has contributed several ALSA fixes. The patch
was accepted by Takashi Iwai, the ALSA maintainer, giving it strong
credibility.

### Step 3.5: Dependencies
None. The fix is a single `of_node_put()` call — it is completely
standalone and applies cleanly.

Record: [No dependencies. Standalone fix. Accepted by subsystem
maintainer.]

---

## PHASE 4: MAILING LIST

### Step 4.1: Original Submission
b4 dig could not find the original submission (the commit hash is from
the autosel pipeline, not mainline). The Link: in the commit message
points to
`patch.msgid.link/20260402023604.54682-1-wangdich9700@163.com`. Lore was
not accessible due to bot protection.

### Step 4.2-4.5
Could not access lore.kernel.org due to Anubis anti-scraping protection.
However, the commit was accepted by the ALSA maintainer (Takashi Iwai),
which means it passed his review.

Record: [Lore inaccessible. Patch accepted by ALSA maintainer Takashi
Iwai.]

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Functions Modified
Only `tas_i2c_probe()` — specifically its `fail:` error path.

### Step 5.2: Callers
`tas_i2c_probe` is the I2C probe callback registered in the `tas_driver`
struct (line 904). It is called by the I2C subsystem when the device is
enumerated. This is a standard device probe path.

### Step 5.3-5.4: Call Chain
The error path is reached when `aoa_codec_register()` fails. Looking at
the function body (`sound/aoa/core/core.c` lines 57-69), it fails when
`attach_codec_to_fabric()` returns an error. This is a plausible failure
scenario during boot or module loading.

### Step 5.5: Similar Patterns
The sibling driver `onyx.c` has the **exact same bug** at lines 980-988:
- `onyx->codec.node = of_node_get(node)` at line 980
- The `fail:` label at line 987-989 calls `kfree(onyx)` without
  `of_node_put(onyx->codec.node)`

Record: [Same pattern bug exists in onyx.c. Probe function called by I2C
subsystem during device enumeration.]

---

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Code Existence
The buggy code was introduced in 2006 (`f3d9478b2ce468`). It exists in
**every** stable tree (5.4.y, 5.10.y, 5.15.y, 6.1.y, 6.6.y, 6.12.y,
etc.).

### Step 6.2: Backport Complications
The only concern is the `kzalloc_obj` conversion on line 848 (from Feb
2026), which exists only in mainline 7.0. In older stable trees, this
will be `kzalloc(sizeof(*tas), GFP_KERNEL)`. However, the fix (adding
one line in the `fail:` path) is completely independent of the
allocation call. The `fail:` label context (mutex_destroy + kfree) has
been stable since 2006. The fix should apply cleanly or with trivial
context adjustment.

### Step 6.3: No related fixes in stable
No previous fix for this specific bug exists in stable trees.

Record: [Bug exists in all stable trees. Fix should apply cleanly with
minor context fuzz.]

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem
- **Subsystem**: ALSA (sound), Apple Onboard Audio — codec driver for
  TAS3004
- **Criticality**: PERIPHERAL — only affects Apple PowerPC-based
  machines with TAS3004 codec (PowerBooks, PowerMacs)

### Step 7.2: Activity
The file gets very infrequent changes (mostly treewide cleanups). This
is a mature, stable subsystem with minimal churn.

Record: [PERIPHERAL subsystem (Apple PowerPC audio). Mature code with
low churn.]

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Population
Users with Apple PowerPC hardware using the TAS3004 audio codec. This is
a niche population, but real users exist (retrocomputing, legacy
systems).

### Step 8.2: Trigger Conditions
The bug triggers only when `aoa_codec_register()` fails during probe.
This is an error path, so it's not common, but it represents a real leak
each time it occurs (e.g., resource contention, misconfiguration).

### Step 8.3: Failure Mode Severity
- **OF node reference leak**: The node refcount is never decremented, so
  the OF node structure is never freed.
- Severity: **LOW-MEDIUM** — resource leak on error path, not a crash or
  security issue, but a real correctness bug.

### Step 8.4: Risk-Benefit Ratio
- **Benefit**: Fixes a real reference counting bug that leaks memory on
  probe failure.
- **Risk**: Essentially zero — 1-line, obviously correct, mirrors
  existing cleanup in the remove function.
- **Ratio**: Very favorable — minimal risk, real correctness
  improvement.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backporting**:
- Fixes a real reference counting bug (missing `of_node_put()` on error
  path)
- 1-line fix, obviously correct, mirrors cleanup in `tas_i2c_remove()`
- Bug has existed since 2006, present in all stable trees
- Accepted by ALSA maintainer Takashi Iwai
- Zero regression risk
- Classic reference counting fix — standard stable material

**AGAINST backporting**:
- Only affects Apple PowerPC hardware with TAS3004 codec (niche)
- Only triggers on probe failure (error path, not common)
- Severity is LOW-MEDIUM (resource leak, not crash/security)

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **YES** — mirrors existing cleanup in
   remove()
2. Fixes a real bug? **YES** — OF node reference leak
3. Important issue? **MODERATE** — resource leak, not critical
4. Small and contained? **YES** — 1 line, 1 file
5. No new features/APIs? **YES** — pure fix
6. Can apply to stable? **YES** — standalone, no dependencies

### Step 9.3: Exception Categories
Not an exception category. Standard bug fix.

### Step 9.4: Decision
This is a small, obviously correct reference counting fix. While the
impact is limited (niche hardware, error path only), the fix has
essentially zero risk and addresses a real correctness bug. OF node
reference leak fixes are routinely accepted in stable, and this follows
a well-established pattern.

---

## Verification

- [Phase 1] Parsed subject: ALSA: aoa/tas subsystem, "Fix" verb, OF node
  leak on probe failure
- [Phase 1] Parsed tags: Signed-off-by from author and Takashi Iwai
  (ALSA maintainer), Link to lore
- [Phase 2] Diff analysis: 1 line added in `tas_i2c_probe()` fail path:
  `of_node_put(tas->codec.node)` before `kfree(tas)`
- [Phase 2] Verified `of_node_get(node)` at line 864 takes a reference
  that is not released on error path
- [Phase 2] Verified `tas_i2c_remove()` at line 885 calls
  `of_node_put(tas->codec.node)` — confirming correct pattern
- [Phase 3] git blame: buggy code introduced in f3d9478b2ce468
  (2006-06-21, "[ALSA] snd-aoa: add snd-aoa")
- [Phase 3] git log: only treewide cleanups on this file, no prior fix
  for this specific bug
- [Phase 3] Related commit 222bce5eb88d1 fixed same bug class in gpio-
  feature.c (different file, same subsystem)
- [Phase 4] b4 dig: could not match rebased commit hash; lore.kernel.org
  blocked by Anubis
- [Phase 5] Verified `onyx.c` at lines 980-988 has the same unfixed bug
  pattern (systematic issue)
- [Phase 5] Verified `aoa_codec_register()` in core.c can fail when
  `attach_codec_to_fabric()` errors
- [Phase 6] Bug exists since 2006 — present in all active stable trees
- [Phase 6] Minor context difference in stable (kzalloc_obj vs kzalloc)
  won't affect the fix line
- [Phase 8] Failure mode: OF node reference leak on probe error path,
  severity LOW-MEDIUM
- UNVERIFIED: Could not access lore.kernel.org to check full review
  discussion or stable nominations

**YES**

 sound/aoa/codecs/tas.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/aoa/codecs/tas.c b/sound/aoa/codecs/tas.c
index 13da2b159ad0d..25214d3da65d1 100644
--- a/sound/aoa/codecs/tas.c
+++ b/sound/aoa/codecs/tas.c
@@ -872,6 +872,7 @@ static int tas_i2c_probe(struct i2c_client *client)
 	return 0;
  fail:
 	mutex_destroy(&tas->mtx);
+	of_node_put(tas->codec.node);
 	kfree(tas);
 	return -EINVAL;
 }
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] powerpc/64s: Fix _HPAGE_CHG_MASK to include _PAGE_SPECIAL bit

[Sasha Levin]

From: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>

[ Upstream commit 68b1fa0ed5c84769e4e60d58f6a5af37e7273b51 ]

commit af38538801c6a ("mm/memory: factor out common code from vm_normal_page_*()"),
added a VM_WARN_ON_ONCE for huge zero pfn.

This can lead to the following call stack.

 ------------[ cut here ]------------
 WARNING: mm/memory.c:735 at vm_normal_page_pmd+0xf0/0x140, CPU#19: hmm-tests/3366
 NIP [c00000000078d0c0] vm_normal_page_pmd+0xf0/0x140
 LR [c00000000078d060] vm_normal_page_pmd+0x90/0x140
 Call Trace:
 [c00000016f56f850] [c00000000078d060] vm_normal_page_pmd+0x90/0x140 (unreliable)
 [c00000016f56f8a0] [c0000000008a9e30] change_huge_pmd+0x7c0/0x870
 [c00000016f56f930] [c0000000007b2bc4] change_protection+0x17a4/0x1e10
 [c00000016f56fba0] [c0000000007b3440] mprotect_fixup+0x210/0x4c0
 [c00000016f56fc30] [c0000000007b3c3c] do_mprotect_pkey+0x54c/0x780
 [c00000016f56fdb0] [c0000000007b3ed8] sys_mprotect+0x68/0x90
 [c00000016f56fdf0] [c00000000003ae40] system_call_exception+0x190/0x500
 [c00000016f56fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec

This happens when we call mprotect -> change_huge_pmd()
mprotect()
  change_pmd_range()
    pmd_modify(oldpmd, newprot) 	# this clears _PAGE_SPECIAL for zero huge pmd
	    pmdv = pmd_val(pmd);
	    pmdv &= _HPAGE_CHG_MASK;	# -> gets cleared here
	    return pmd_set_protbits(__pmd(pmdv), newprot);
    can_change_pmd_writable(vma, vmf->address, pmd)
      vm_normal_page_pmd(vma, addr, pmd)
        __vm_normal_page()
          VM_WARN_ON(is_zero_pfn(pfn) || is_huge_zero_pfn(pfn));  # this get hits as _PAGE_SPECIAL for zero huge pmd was cleared.

It can be easily reproduced with the following testcase:
	p = mmap(NULL, 2 * hpage_pmd_size, PROT_READ, MAP_PRIVATE |
		 MAP_ANONYMOUS, -1, 0);
	madvise((void *)p, 2 * hpage_pmd_size, MADV_HUGEPAGE);
	aligned = (char*)(((unsigned long)p + hpage_pmd_size - 1) &
				~(hpage_pmd_size - 1));
	(void)(*(volatile char*)aligned);  // read fault, installs huge zero PMD
	mprotect((void *)aligned, hpage_pmd_size, PROT_READ | PROT_WRITE);

This patch adds _PAGE_SPECIAL to _HPAGE_CHG_MASK similar to
_PAGE_CHG_MASK, as we don't want to clear this bit when calling
pmd_modify() while changing protection bits.

Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/7416f5cdbcfeaad947860fcac488b483f1287172.1773078178.git.ritesh.list@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have a complete picture. Let me compile the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `powerpc/64s`
- Action verb: "Fix" - explicitly a bug fix
- Summary: Fix `_HPAGE_CHG_MASK` to include `_PAGE_SPECIAL` bit,
  preventing it from being stripped during `pmd_modify()`

**Step 1.2: Tags**
- No `Fixes:` tag (expected for this pipeline)
- No `Cc: stable@vger.kernel.org` (expected)
- `Signed-off-by: Ritesh Harjani (IBM)` - the author
- `Tested-by: Venkat Rao Bagalkote` - independently tested
- `Signed-off-by: Madhavan Srinivasan` - powerpc subsystem maintainer
- `Link:` to patch.msgid.link with the original submission

**Step 1.3: Commit Body**
The commit describes a concrete bug: when `mprotect()` is called on a
mapping with a huge zero PMD, `pmd_modify()` strips `_PAGE_SPECIAL`
because `_HPAGE_CHG_MASK` doesn't include it. This causes
`vm_normal_page_pmd()` to hit a `VM_WARN_ON` for zero huge pfn. A
complete call trace is provided, along with a simple reproducible
testcase.

**Step 1.4: Hidden Bug Fix?**
Not hidden at all - this is an explicitly stated fix with "Fix" in the
subject.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Single file changed: `arch/powerpc/include/asm/book3s/64/pgtable.h`
- Net change: 2 lines changed (adding `_PAGE_SPECIAL |` to the mask,
  reformatting)
- Effectively a 1-token addition to a preprocessor bitmask

**Step 2.2: Code Flow Change**
Before: `_HPAGE_CHG_MASK` does not include `_PAGE_SPECIAL`, so
`pmd_modify()` clears this bit.
After: `_HPAGE_CHG_MASK` includes `_PAGE_SPECIAL`, preserving it through
`pmd_modify()`.

**Step 2.3: Bug Mechanism**
Logic/correctness fix. The `_PAGE_CHG_MASK` (for regular PTEs) already
includes `_PAGE_SPECIAL` at line 123-125 of the same file. The
`_HPAGE_CHG_MASK` (for huge PMDs) was missing it, creating an
inconsistency where `pmd_modify()` strips `_PAGE_SPECIAL` while
`pte_modify()` preserves it.

**Step 2.4: Fix Quality**
- Obviously correct: makes the huge page mask match the regular page
  mask
- Minimal and surgical: single bit addition to a bitmask
- Zero regression risk: preserving a bit that should always be preserved
- Historical precedent: commit fbc78b07ba53 (2009) fixed the same issue
  for `_PAGE_CHG_MASK`

## PHASE 3: GIT HISTORY

**Step 3.1: Blame**
The `_HPAGE_CHG_MASK` definition was introduced by commit
`2e8735198af039` (Aneesh Kumar K.V, 2016-04-29) when powerpc moved
common PTE bits to `book3s/64/pgtable.h`. The `_PAGE_SPECIAL` was
missing from `_HPAGE_CHG_MASK` from the very beginning while it was
present in `_PAGE_CHG_MASK`. The bug has existed since 2016, meaning all
active stable trees have this bug.

**Step 3.2: Fixes Tag**
No explicit `Fixes:` tag, but the buggy commit is `2e8735198af039` which
exists in all active stable trees (v4.8+).

**Step 3.3: Related Changes**
- Commit `548cb932051fb` ("x86/mm: Fix PAT bit missing from page
  protection modify mask") - analogous fix on x86 for a similar issue
  with `_PAGE_PAT` missing from the modify mask. This shows this is a
  known class of bugs.
- Commit `fbc78b07ba53` ("powerpc/mm: Fix _PAGE_CHG_MASK to protect
  _PAGE_SPECIAL") from 2009 - exact same type of fix but for the regular
  PTE mask.

**Step 3.4: Author**
Ritesh Harjani is a regular powerpc contributor at IBM with many commits
in this subsystem.

**Step 3.5: Dependencies**
This commit is fully standalone. No prerequisites needed.

## PHASE 4: MAILING LIST

- b4 dig could not find the exact commit hash (it's not yet in the
  mainline tree referenced by b4).
- The `Link:` tag points to `patch.msgid.link/7416f5cdbcfeaad947860fcac4
  88b483f1287172.1773078178.git.ritesh.list@gmail.com`
- Lore was inaccessible due to anti-bot protection.
- The commit was accepted by the powerpc maintainer Madhavan Srinivasan,
  indicating proper review.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1-5.4: Key Functions**
- `pmd_modify()` in `arch/powerpc/mm/book3s64/pgtable.c:277` uses
  `_HPAGE_CHG_MASK` to filter bits.
- `pud_modify()` at line 286 also uses `_HPAGE_CHG_MASK`.
- These are called from `change_huge_pmd()` in `mm/huge_memory.c:2625`
  during `mprotect()`.
- `change_huge_pmd()` then calls `can_change_pmd_writable()` which calls
  `vm_normal_page_pmd()`.
- `vm_normal_page_pmd()` calls `__vm_normal_page()` which has a
  `VM_WARN_ON_ONCE` for zero pfns.

The call chain is: `sys_mprotect()` -> `do_mprotect_pkey()` ->
`mprotect_fixup()` -> `change_protection()` -> `change_pmd_range()` ->
`change_huge_pmd()` -> `pmd_modify()` (loses `_PAGE_SPECIAL`) ->
`can_change_pmd_writable()` -> `vm_normal_page_pmd()` -> `VM_WARN_ON`.

This is reachable from any unprivileged userspace `mprotect()` call on a
THP-backed mapping.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1:** The buggy `_HPAGE_CHG_MASK` definition has been present
since v4.8 (2016). All active stable trees contain this bug.

**Step 6.2:** The fix will apply cleanly - the `_HPAGE_CHG_MASK`
definition is stable and hasn't changed significantly (last modification
by `d438d273417055` removed `_PAGE_DEVMAP`).

**Step 6.3:** No related fix has been applied to stable for this issue.

## PHASE 7: SUBSYSTEM CONTEXT

- Subsystem: `powerpc/64s` - architecture-specific memory management
- Criticality: IMPORTANT - affects all powerpc book3s 64-bit systems
  using THP
- The code touches page table bit handling, a critical part of the
  memory subsystem

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1:** Affects users of powerpc book3s 64-bit systems with THP
enabled.

**Step 8.2:** Triggered by `mprotect()` on a huge zero page mapping. The
reproducer is simple: mmap + madvise(MADV_HUGEPAGE) + read fault +
mprotect. Any unprivileged user can trigger it.

**Step 8.3:** Failure mode: Kernel warning (VM_WARN_ON), incorrect page
treatment (zero page treated as normal page after mprotect). MEDIUM-HIGH
severity - causes kernel splats and potentially incorrect memory
management decisions.

**Step 8.4:**
- BENEFIT: HIGH - fixes a bug triggerable from userspace via common
  operations, prevents kernel warnings and incorrect page handling
- RISK: VERY LOW - single bit addition to a bitmask, obviously correct
  by analogy with `_PAGE_CHG_MASK`
- Ratio: Strongly favorable

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
- Fixes a real bug with concrete reproducer and call trace
- Single-bit addition to a bitmask - trivially small and obviously
  correct
- Makes `_HPAGE_CHG_MASK` consistent with `_PAGE_CHG_MASK` (which
  already has `_PAGE_SPECIAL`)
- Historical precedent: same fix for regular PTEs (2009) and for x86
  (2023)
- Tested independently, accepted by subsystem maintainer
- Bug exists in all stable trees since 2016
- Zero regression risk

**Evidence AGAINST backporting:**
- The `VM_WARN_ON` that makes this most visible (from `af38538801c6a`)
  is only in recent kernels (6.18+)
- powerpc does not define `pmd_special()` (returns false generically),
  so the full mechanism is subtle

**Stable Rules Checklist:**
1. Obviously correct? **YES** - trivial consistency fix
2. Fixes a real bug? **YES** - `_PAGE_SPECIAL` incorrectly stripped
   during `pmd_modify()`
3. Important issue? **YES** - kernel warning + incorrect page handling
4. Small and contained? **YES** - 1 line in 1 file
5. No new features? **YES**
6. Applies cleanly? **YES**

## Verification

- [Phase 1] Parsed tags: Signed-off-by powerpc maintainer, Tested-by
  from IBM tester
- [Phase 2] Diff analysis: adding `_PAGE_SPECIAL` to `_HPAGE_CHG_MASK`
  bitmask, 1 effective line
- [Phase 3] git blame: buggy `_HPAGE_CHG_MASK` introduced in commit
  2e8735198af039 (2016, v4.8+)
- [Phase 3] git show 548cb932051fb: confirmed analogous x86 fix for
  `_PAGE_PAT` missing from modify mask
- [Phase 3] git show fbc78b07ba53: confirmed 2009 fix adding
  `_PAGE_SPECIAL` to `_PAGE_CHG_MASK` (the PTE equivalent)
- [Phase 3] git show 2e8735198af039: confirmed original code movement
  commit, _HPAGE_CHG_MASK missing _PAGE_SPECIAL from the start
- [Phase 4] b4 dig -c af38538801c6a: found the vm_normal_page
  refactoring series (v1-v3 by David Hildenbrand)
- [Phase 5] Traced call chain: mprotect -> change_huge_pmd -> pmd_modify
  (strips bit) -> can_change_pmd_writable -> vm_normal_page_pmd ->
  VM_WARN_ON
- [Phase 5] Verified _HPAGE_CHG_MASK used in pmd_modify()
  (pgtable.c:282) and pud_modify() (pgtable.c:291)
- [Phase 5] Verified _PAGE_CHG_MASK already includes _PAGE_SPECIAL
  (pgtable.h:123-125)
- [Phase 6] Buggy code present since v4.8 (2016) - all active stable
  trees affected
- [Phase 6] File has had minimal changes to _HPAGE_CHG_MASK area - clean
  apply expected
- [Phase 7] Confirmed powerpc selects ARCH_HAS_PTE_SPECIAL but not
  ARCH_SUPPORTS_HUGE_PFNMAP
- [Phase 8] Reproducer is trivial userspace mmap+mprotect sequence
- UNVERIFIED: Could not access lore.kernel.org discussion due to anti-
  bot protection

**YES**

 arch/powerpc/include/asm/book3s/64/pgtable.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h
index 1a91762b455d9..e0b78fa36d160 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -107,8 +107,8 @@
  * in here, on radix we expect them to be zero.
  */
 #define _HPAGE_CHG_MASK (PTE_RPN_MASK | _PAGE_HPTEFLAGS | _PAGE_DIRTY | \
-			 _PAGE_ACCESSED | H_PAGE_THP_HUGE | _PAGE_PTE | \
-			 _PAGE_SOFT_DIRTY)
+			 _PAGE_ACCESSED | H_PAGE_THP_HUGE | _PAGE_SPECIAL | \
+			 _PAGE_PTE | _PAGE_SOFT_DIRTY)
 /*
  * user access blocked by key
  */
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] PCI/DPC: Hold pci_dev reference during error recovery

[Sasha Levin]

From: Sizhe Liu <liusizhe5@huawei.com>

[ Upstream commit a1ed752bc7cb77b740cee671567d9508ae74becd ]

The AER and EDR error handling paths hold a reference on the pci_dev during
recovery.  Hold a reference during the DPC recovery path as well.

Signed-off-by: Sizhe Liu <liusizhe5@huawei.com>
[bhelgaas: split to separate patch]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
https://patch.msgid.link/20260214081130.1878424-1-liusizhe5@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed. Let me write the complete
analysis.

---

## Complete Analysis: PCI/DPC: Hold pci_dev reference during error
recovery

### PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `PCI/DPC` (PCI Express Downstream Port Containment)
- Action verb: "Hold" - implies adding a missing safety measure
- Summary: Hold a pci_dev reference during error recovery to prevent
  potential use-after-free
- Record: [PCI/DPC] [Hold] [Add missing reference counting for pci_dev
  during DPC recovery path]

**Step 1.2: Tags**
- `Signed-off-by: Sizhe Liu <liusizhe5@huawei.com>` - Original author
- `[bhelgaas: split to separate patch]` - Bjorn Helgaas (PCI subsystem
  maintainer) split this from a larger patch
- `Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>` - Committed by
  the PCI subsystem maintainer
- `Link: https://patch.msgid.link/20260214081130.1878424-1-
  liusizhe5@huawei.com` - Original submission

No Fixes: tag, no Reported-by, no Cc: stable (expected for a candidate).

Record: Signed by author and PCI maintainer. Split from a larger patch
by Bjorn Helgaas. No Fixes: tag.

**Step 1.3: Commit Body**
The message states: "The AER and EDR error handling paths hold a
reference on the pci_dev during recovery. Hold a reference during the
DPC recovery path as well." This is a clear statement of a reference
counting inconsistency between the three error recovery paths.

Record: Bug = missing pci_dev reference during DPC error recovery.
Symptom = potential use-after-free if device is freed during recovery.
Root cause = reference counting inconsistency between DPC, AER, and EDR
paths.

**Step 1.4: Hidden Bug Fix Detection**
Yes - this is a reference counting bug fix. The word "Hold" implies
adding a missing reference, aligning DPC with AER and EDR behavior. This
fixes a potential use-after-free.

### PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 1 file modified: `drivers/pci/pcie/dpc.c`
- +2 lines added, 0 removed
- Function modified: `dpc_handler()`
- Classification: single-file surgical fix (2 lines)

**Step 2.2: Code Flow Change**
Before: `dpc_handler()` uses `pdev` throughout `dpc_process_error()` and
`pcie_do_recovery()` without holding a reference.
After: `pci_dev_get(pdev)` before processing, `pci_dev_put(pdev)` after
recovery completes. Ensures the `pci_dev` object lives through the
entire recovery.

**Step 2.3: Bug Mechanism**
Category: **Reference counting fix**
- `pci_dev_get()` is ADDED (this fixes a potential use-after-free /
  missing reference hold)
- AER path: uses `pci_dev_get()` in `add_error_device()` at `aer.c:992`
  and `pci_dev_put()` in `handle_error_source()` at `aer.c:1202`
- AER APEI path: uses `pci_get_domain_bus_and_slot()` (returns with ref)
  at `aer.c:1226` and `pci_dev_put()` at `aer.c:1253`
- EDR path: uses `pci_dev_get()` in `acpi_dpc_port_get()` at
  `edr.c:89,94` and `pci_dev_put()` at `edr.c:218`
- DPC path: **no reference held** before this fix

**Step 2.4: Fix Quality**
- Obviously correct: balanced get/put pair wrapping the usage
- Minimal/surgical: exactly 2 lines
- No regression risk: adding reference counting cannot cause deadlock or
  data corruption
- No red flags

### PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
The `dpc_handler()` function was authored by Kuppuswamy Sathyanarayanan
in commit `aea47413e7ceec` (2020-03-23), present since v5.15. The core
structure with `dpc_process_error()` + `pcie_do_recovery()` has been
stable since then. The surprise removal check was added later by
`2ae8fbbe1cd42` (2024, first in v6.12).

**Step 3.2: Fixes Tag Context**
The original v3 patch had `Fixes: a57f2bfb4a58` ("PCI/AER: Ratelimit
correctable and non-fatal error logging") which was first in v6.16-rc1.
However, the reference counting bug existed earlier - the DPC path has
been missing the reference since `aea47413e7ceec` (2020, v5.15+). Bjorn
split the reference counting part into its own patch.

**Step 3.3: File History**
Recent commits to `dpc.c` are mostly cleanup/improvement (FIELD_GET,
defines, TLP log). No other reference counting fixes.

**Step 3.4: Author Context**
Sizhe Liu (Huawei) identified the issue. Bjorn Helgaas (PCI subsystem
maintainer) reviewed, suggested the reference counting addition, and
committed the fix.

**Step 3.5: Dependencies**
This commit is fully standalone. It adds `pci_dev_get()`/`pci_dev_put()`
around existing code. No new functions, no API changes, no dependencies.

### PHASE 4: MAILING LIST RESEARCH

The complete discussion was found. Key findings:
1. Sizhe Liu submitted v1/v2/v3 of "PCI/AER: Fix missing AER logs in DPC
   and EDR paths"
2. On v2 review, **Bjorn Helgaas himself identified** the missing
   reference: "I don't see a similar pci_dev_get() anywhere in the DPC
   path ... holding that reference on the device is important."
3. Sizhe Liu agreed and added it in v3
4. Bjorn then split the v3 patch into two separate patches: the AER log
   fix and this reference counting fix
5. Shiju Jose reviewed v3 with minor formatting comments
6. The patch was applied by Bjorn Helgaas

### PHASE 5: CODE SEMANTIC ANALYSIS

**Callers of affected code:**
- `dpc_handler()` is a threaded IRQ handler registered in `dpc_probe()`
  via `devm_request_threaded_irq()`
- Triggered by `dpc_irq()` (hardirq handler) returning `IRQ_WAKE_THREAD`
- `pcie_do_recovery()` is a long-running function that walks the PCI
  bus, calls driver error handlers, resets links, and waits for
  secondary bus readiness

**Call chain:** Hardware DPC trigger -> `dpc_irq()` -> `dpc_handler()`
-> `dpc_process_error()` + `pcie_do_recovery()` -> `dpc_reset_link()` ->
`pcie_wait_for_link()` + `pci_bridge_wait_for_secondary_bus()`

The recovery process can take seconds (waiting for links, bus resets).
During this time, the `pci_dev` must remain valid.

### PHASE 6: STABLE TREE ANALYSIS

The buggy code (`dpc_handler()` without reference) exists in all stable
trees from v5.15 onwards. The function was introduced in
`aea47413e7ceec` (v5.15). For trees older than v6.12, the surprise
removal block won't be present, but the patch context for the
`pci_dev_get`/`pci_dev_put` addition is around the `dpc_process_error()`
+ `pcie_do_recovery()` calls which are present in all trees. Minor
conflicts may be needed for trees without the surprise removal check.

### PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

- Subsystem: PCI Express (drivers/pci/pcie/) - IMPORTANT subsystem
  affecting all PCIe users
- DPC is a standard PCIe feature for error containment
- Maintainer: Bjorn Helgaas - he personally identified and committed
  this fix
- Criticality: IMPORTANT - affects all systems with PCIe DPC support

### PHASE 8: IMPACT AND RISK ASSESSMENT

**Who is affected:** All systems with PCIe DPC support (most modern x86
systems, some ARM)

**Trigger conditions:** A DPC containment event (PCIe fatal error)
concurrent with device removal. While the specific race may be hard to
trigger, DPC events are not uncommon (hardware errors, NVMe removal
under load).

**Failure mode:** Potential use-after-free - accessing freed `pci_dev`
during recovery. Severity: **HIGH** (crash, potential security issue)

**Benefit:** Fixes a reference counting correctness bug, aligns DPC with
AER/EDR behavior, prevents potential UAF during error recovery.

**Risk:** **Very low** - 2 lines, balanced get/put, obviously correct,
no behavioral change.

### PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
1. Fixes a reference counting bug (missing `pci_dev_get` in DPC handler)
2. Potential use-after-free during error recovery
3. Only 2 lines added - minimal risk
4. PCI subsystem maintainer (Bjorn Helgaas) personally identified the
   issue and committed the fix
5. Consistent with how AER and EDR paths already work
6. `pcie_do_recovery()` is a long-running function making the window
   non-trivial
7. Buggy code present since v5.15
8. Standalone fix with no dependencies

**Evidence AGAINST backporting:**
1. No concrete crash report or syzbot finding (theoretical)
2. Race requires specific timing (DPC + hot-removal)

**Stable Rules Checklist:**
1. Obviously correct? **YES** - balanced get/put, trivially verifiable
2. Fixes a real bug? **YES** - reference counting inconsistency,
   potential UAF
3. Important issue? **YES** - potential crash/UAF during error recovery
4. Small and contained? **YES** - 2 lines in 1 file
5. No new features/APIs? **YES** - pure bug fix
6. Can apply to stable? **YES** - standalone, clean apply expected for
   v7.0

### Verification

- [Phase 1] Parsed tags: Signed-off-by Sizhe Liu + Bjorn Helgaas, Link
  to lore
- [Phase 2] Diff analysis: +2 lines in `dpc_handler()`, adds
  `pci_dev_get()`/`pci_dev_put()` around error recovery
- [Phase 3] git blame: `dpc_handler()` introduced in commit
  `aea47413e7ceec` (2020), present since v5.15
- [Phase 3] git show a57f2bfb4a58: confirmed the ratelimit commit is in
  v6.16-rc1, first in v7.0 tree
- [Phase 4] Found full thread via yhbt.net mirror of lore: v1/v2/v3
  progression, Bjorn requested ref counting in v2 review
- [Phase 4] Bjorn Helgaas (PCI maintainer) explicitly said "holding that
  reference on the device is important"
- [Phase 4] Bjorn split original 3-file patch into separate patches,
  this is the DPC ref-counting portion
- [Phase 5] `pcie_do_recovery()` walks bus, resets links, waits for
  secondary bus - long-running operation
- [Phase 5] Verified AER (aer.c:992/1202), AER APEI (aer.c:1226/1253),
  EDR (edr.c:89/218) all hold references
- [Phase 5] Verified DPC path has NO reference holding in current 7.0
  tree
- [Phase 6] Buggy code exists since v5.15 (aea47413e7ceec present in
  v5.15, v6.1, v6.6, v6.12, v7.0)
- [Phase 6] Surprise removal block (2ae8fbbe1cd42) is in v6.12+ only, so
  older trees may need context adjustment
- [Phase 7] PCI/DPC is an important subsystem; fix committed by
  subsystem maintainer
- [Phase 8] Failure mode: potential UAF during DPC recovery, severity
  HIGH
- UNVERIFIED: Whether the `devm_request_threaded_irq` + `free_irq`
  synchronization fully prevents the race (it synchronizes handler
  completion but doesn't prevent refcount drops during handler
  execution)

The fix is a 2-line, obviously correct reference counting addition that
aligns the DPC error recovery path with the AER and EDR paths. The PCI
subsystem maintainer identified and committed it. The potential
consequence of the missing reference is a use-after-free, and the fix
carries essentially zero regression risk.

**YES**

 drivers/pci/pcie/dpc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
index fc18349614d7c..f028bc795f197 100644
--- a/drivers/pci/pcie/dpc.c
+++ b/drivers/pci/pcie/dpc.c
@@ -372,11 +372,13 @@ static irqreturn_t dpc_handler(int irq, void *context)
 		return IRQ_HANDLED;
 	}
 
+	pci_dev_get(pdev);
 	dpc_process_error(pdev);
 
 	/* We configure DPC so it only triggers on ERR_FATAL */
 	pcie_do_recovery(pdev, pci_channel_io_frozen, dpc_reset_link);
 
+	pci_dev_put(pdev);
 	return IRQ_HANDLED;
 }
 
-- 
2.53.0