[PATCH AUTOSEL 6.18-5.10] ACPICA: Avoid walking the Namespace if start_node is NULL

[Sasha Levin <sashal@kernel.org>]

From: Cryolitia PukNgae <cryolitia.pukngae@linux.dev>

[ Upstream commit 9d6c58dae8f6590c746ac5d0012ffe14a77539f0 ]

Although commit 0c9992315e73 ("ACPICA: Avoid walking the ACPI Namespace
if it is not there") fixed the situation when both start_node and
acpi_gbl_root_node are NULL, the Linux kernel mainline now still crashed
on Honor Magicbook 14 Pro [1].

That happens due to the access to the member of parent_node in
acpi_ns_get_next_node().  The NULL pointer dereference will always
happen, no matter whether or not the start_node is equal to
ACPI_ROOT_OBJECT, so move the check of start_node being NULL
out of the if block.

Unfortunately, all the attempts to contact Honor have failed, they
refused to provide any technical support for Linux.

The bad DSDT table's dump could be found on GitHub [2].

DMI: HONOR FMB-P/FMB-P-PCB, BIOS 1.13 05/08/2025

Link: https://github.com/acpica/acpica/commit/1c1b57b9eba4554cb132ee658dd942c0210ed20d
Link: https://gist.github.com/Cryolitia/a860ffc97437dcd2cd988371d5b73ed7 [1]
Link: https://github.com/denis-bb/honor-fmb-p-dsdt [2]
Signed-off-by: Cryolitia PukNgae <cryolitia.pukngae@linux.dev>
Reviewed-by: WangYuli <wangyl5933@chinaunicom.cn>
[ rjw: Subject adjustment, changelog edits ]
Link: https://patch.msgid.link/20251125-acpica-v1-1-99e63b1b25f8@linux.dev
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Comprehensive Analysis

### 1. COMMIT MESSAGE ANALYSIS

**Subject**: "ACPICA: Avoid walking the Namespace if start_node is NULL"

The commit message clearly indicates:
- This is a fix to a prior fix (commit 0c9992315e73)
- It addresses a real crash on Honor Magicbook 14 Pro hardware
- The bug is a NULL pointer dereference in `acpi_ns_get_next_node()`
- Link to ACPICA upstream commit
  (1c1b57b9eba4554cb132ee658dd942c0210ed20d) - this is coordinated with
  the ACPICA project
- Signed off by Rafael J. Wysocki (ACPI maintainer) with "Reviewed-by"
  tag

**Missing tags**: No explicit `Cc: stable@vger.kernel.org` or `Fixes:`
tag, but this is clearly a fix to a stable-tree-relevant commit.

### 2. CODE CHANGE ANALYSIS

**The bug mechanism**:

Looking at `acpi_ns_get_next_node()` (lines 34-46 of nswalk.c):

```c
if (!child_node) {
    /* It's really the parent's _scope_ that we want */
    return (parent_node->child);  // <-- CRASH if parent_node is NULL
}
```

The original fix (0c9992315e73) added this check **inside** the
ACPI_ROOT_OBJECT branch:
```c
if (start_node == ACPI_ROOT_OBJECT) {
    start_node = acpi_gbl_root_node;
    if (!start_node) {  // Only catches: ACPI_ROOT_OBJECT +
gbl_root_node==NULL
        return_ACPI_STATUS(AE_NO_NAMESPACE);
    }
}
```

**The problem**: If `start_node` is passed as NULL directly (not via
ACPI_ROOT_OBJECT), the check is never executed:
- `start_node` remains NULL
- `parent_node = start_node;` makes `parent_node` = NULL
- `acpi_ns_get_next_node(parent_node, NULL)` dereferences
  `parent_node->child` → **KERNEL PANIC**

**The fix** (this commit): Move the NULL check outside the if block:
```c
if (start_node == ACPI_ROOT_OBJECT) {
    start_node = acpi_gbl_root_node;
}

/* Avoid walking the namespace if the StartNode is NULL */
if (!start_node) {  // Now catches ALL NULL cases
    return_ACPI_STATUS(AE_NO_NAMESPACE);
}
```

### 3. CLASSIFICATION

- **Type**: Bug fix (NULL pointer dereference crash)
- **Not an exception category**: This is a pure crash fix, not a device
  ID, quirk, or DT update
- **Severity**: Kernel panic/crash - HIGH severity for affected hardware

### 4. SCOPE AND RISK ASSESSMENT

**Lines changed**: 8 (minimal)
**Files touched**: 1 (`drivers/acpi/acpica/nswalk.c`)
**Complexity**: Trivial - literally moving 3 lines of code outside an if
block

**Risk**: VERY LOW
- The change only affects the code path when `start_node` is NULL
- For non-NULL `start_node`, behavior is identical
- The fix is obviously correct - you must catch all NULL cases
- The fix was also merged upstream to ACPICA project

### 5. USER IMPACT

**Who is affected**:
- Users with Honor Magicbook 14 Pro (FMB-P series)
- Potentially other devices with similar DSDT issues

**Impact severity**:
- Complete system crash (kernel panic) during boot
- System is completely unusable without this fix

**Evidence**: Real crash report linked in commit with DMI string: "HONOR
FMB-P/FMB-P-PCB, BIOS 1.13 05/08/2025"

### 6. STABILITY INDICATORS

**Positive signals**:
- Reviewed-by tag present
- Signed off by Rafael J. Wysocki (ACPI maintainer - highly trusted)
- Merged to ACPICA upstream (external validation)
- Very simple, obvious logic fix

**Concerns**:
- Very recent commit (Nov 25, 2025)
- No explicit Cc: stable tag

### 7. DEPENDENCY CHECK

**Dependencies**:
- Requires commit 0c9992315e73 to be present (it added the original NULL
  check that this fix improves)
- Commit 0c9992315e73 is already in stable trees (v5.18+, backported to
  many LTS trees)

The code change is self-contained - no other changes required.

### 8. HISTORICAL CONTEXT

The original commit 0c9992315e73 was introduced in March 2022 and was
backported to all stable trees. This new fix addresses a gap in that
original fix. The fact that the original fix was deemed stable-worthy
means this completion of that fix should also be stable material.

---

## Final Assessment

**Should this be backported?** YES

**Rationale**:
1. **Fixes a real crash**: NULL pointer dereference causing kernel panic
   on real hardware
2. **Minimal, surgical change**: Only 8 lines changed, moving code
   outside an if block
3. **Obviously correct**: The logic is trivial - catch ALL NULL cases,
   not just one path
4. **Completes a prior stable fix**: The original fix (0c9992315e73) is
   already in stable trees; this completes it
5. **Low risk**: Only affects NULL case; no behavioral change for
   working systems
6. **Externally validated**: Merged to ACPICA upstream project
7. **Trusted maintainer**: Signed off by Rafael J. Wysocki

**Backport considerations**:
- Should apply cleanly to all kernels that have commit 0c9992315e73
- May have minor copyright year conflicts (trivial to resolve)
- No functional dependencies beyond the original fix

The lack of explicit `Cc: stable` tag is likely an oversight. The commit
is clearly stable material as it fixes a crash that makes hardware
completely unusable.

**YES**

 drivers/acpi/acpica/nswalk.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/acpica/nswalk.c b/drivers/acpi/acpica/nswalk.c
index a2ac06a26e921..5670ff5a43cd4 100644
--- a/drivers/acpi/acpica/nswalk.c
+++ b/drivers/acpi/acpica/nswalk.c
@@ -169,9 +169,12 @@ acpi_ns_walk_namespace(acpi_object_type type,
 
 	if (start_node == ACPI_ROOT_OBJECT) {
 		start_node = acpi_gbl_root_node;
-		if (!start_node) {
-			return_ACPI_STATUS(AE_NO_NAMESPACE);
-		}
+	}
+
+	/* Avoid walking the namespace if the StartNode is NULL */
+
+	if (!start_node) {
+		return_ACPI_STATUS(AE_NO_NAMESPACE);
 	}
 
 	/* Null child means "get first node" */
-- 
2.51.0