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/1c1b57b9eba4554cb132ee658dd942c0210e... 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" */