[PATCH AUTOSEL 6.17-5.4] cpufreq/longhaul: handle NULL policy in longhaul_exit

[Sasha Levin <sashal@kernel.org>]

From: Dennis Beier <nanovim@gmail.com>

[ Upstream commit 592532a77b736b5153e0c2e4c74aa50af0a352ab ]

longhaul_exit() was calling cpufreq_cpu_get(0) without checking
for a NULL policy pointer. On some systems, this could lead to a
NULL dereference and a kernel warning or panic.

This patch adds a check using unlikely() and returns early if the
policy is NULL.

Bugzilla: #219962

Signed-off-by: Dennis Beier <nanovim@gmail.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

## Comprehensive Analysis

### Executive Summary
This commit fixes a **critical NULL pointer dereference bug** in the
longhaul cpufreq driver that has existed since 2014. The fix is a
minimal defensive check that prevents kernel crashes when unloading the
module. This is an **excellent candidate for stable backporting**.

### Bug Analysis

#### Root Cause
The bug was introduced in **commit 7aa0557fae5ce (2014)** when Srivatsa
S. Bhat added code to `longhaul_exit()` that directly dereferences the
policy pointer at **line 960**:

```c
freqs.old = policy->cur;  // NULL dereference if policy is NULL!
```

This code assumes `cpufreq_cpu_get(0)` always returns a valid pointer,
but that's not guaranteed.

#### When NULL Can Be Returned
Based on my analysis of `cpufreq_cpu_get()` in
**drivers/cpufreq/cpufreq.c:226-242**:

1. **No cpufreq driver registered** (`cpufreq_driver` is NULL)
2. **No policy exists for CPU 0** (`cpufreq_cpu_get_raw()` returns NULL)
3. **Invalid CPU number** (though unlikely for CPU 0)

In the module exit path, this can occur if:
- The driver registration partially failed
- The cpufreq core removed the policy due to runtime errors
- Race conditions during module unload

#### Impact
Without this fix, calling `policy->cur` at line 960 causes:
- **NULL pointer dereference** → immediate kernel crash
- **Kernel warning or panic** as documented in the commit message
- Additionally, `cpufreq_cpu_put(policy)` at line 971 would also crash
  since it calls `kobject_put(&policy->kobj)` without NULL checking

### Code Changes Analysis

The fix adds exactly **3 lines** at drivers/cpufreq/longhaul.c:956-958:

```c
+       if (unlikely(!policy))
+               return;
+
```

**Analysis of the fix:**
1. **Minimal and surgical** - Only adds a defensive NULL check
2. **Uses `unlikely()`** - Correctly hints to compiler this is an error
   path
3. **Early return pattern** - Clean exit without side effects
4. **No functional change** when policy is valid - Zero impact on normal
   operation

### Pattern Consistency

My research found that **many other cpufreq drivers already implement
this exact pattern**:

- **drivers/cpufreq/tegra186-cpufreq.c:113**: `if (!policy)`
- **drivers/cpufreq/amd-pstate-ut.c:126**: `if (!policy)`
- **drivers/cpufreq/s5pv210-cpufreq.c:561**: `if (!policy)`
- **drivers/cpufreq/mediatek-cpufreq-hw.c:64**: `if (!policy)`
- **drivers/cpufreq/powernv-cpufreq.c:900,933**: `if (!cpu_policy)` /
  `if (!policy)`
- **drivers/cpufreq/apple-soc-cpufreq.c:143**: `if (unlikely(!policy))`
- **drivers/cpufreq/scmi-cpufreq.c:46**: `if (unlikely(!policy))`

The longhaul driver was an **outlier** - it should have had this check
all along.

### Historical Context

The vulnerable code path was created across two commits:
- **2013 (b43a7ffbf33be7)**: Viresh Kumar added `cpufreq_cpu_get(0)`
  without NULL check
- **2014 (7aa0557fae5ce2)**: Srivatsa S. Bhat added `policy->cur`
  dereference, making the bug exploitable

The bug has existed for **~11 years** across **33 commits** to this
file. The longhaul driver targets legacy VIA processors, which explains
why this wasn't caught earlier - limited hardware deployment.

### Backport Suitability Assessment

**Criteria Analysis:**

1. ✅ **Fixes a bug affecting users** - YES: Prevents kernel crashes
2. ✅ **Small and contained** - YES: Only 3 lines added
3. ✅ **Clear side effects** - NO unwanted side effects; purely defensive
4. ✅ **No architectural changes** - NO: Simple NULL check only
5. ✅ **Not touching critical subsystems** - Only affects longhaul driver
6. ⚠️ **Explicit stable mention** - NO Cc: stable tag, but should have
   one
7. ✅ **Follows stable rules** - YES: Important bugfix, minimal risk

**Risk Assessment:**
- **Regression risk**: **VERY LOW** - The check only triggers on error
  paths
- **Testing impact**: Minimal - Only affects VIA C5/C6 processors
- **Code complexity**: Trivial - Standard NULL pointer check
- **Dependency risk**: None - Self-contained change

### Recommendations

1. **BACKPORT to all stable trees** where commit 7aa0557fae5ce2 exists
   (v3.15+)
2. **Priority**: MEDIUM-HIGH (fixes crashes, but affects legacy
   hardware)
3. **Add Fixes tag**: Should reference `Fixes: 7aa0557fae5ce ("cpufreq:
   longhaul: Fix double invocation...")`
4. **Add Cc: stable** tag in backport

### Conclusion

This is a **textbook example** of a good stable backport candidate:
- Fixes a real crash bug
- Minimal code change with zero regression risk
- Follows established kernel patterns
- No architectural or functional changes
- Self-contained to a single driver

The only reason this hasn't caused more reports is the limited
deployment of VIA C5/C6 processors. However, for users with this
hardware, this bug can cause **immediate kernel crashes** on module
unload, making it a significant reliability issue.

**STRONGLY RECOMMEND: YES for stable backport**

 drivers/cpufreq/longhaul.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/cpufreq/longhaul.c b/drivers/cpufreq/longhaul.c
index ba0e08c8486a6..49e76b44468aa 100644
--- a/drivers/cpufreq/longhaul.c
+++ b/drivers/cpufreq/longhaul.c
@@ -953,6 +953,9 @@ static void __exit longhaul_exit(void)
 	struct cpufreq_policy *policy = cpufreq_cpu_get(0);
 	int i;
 
+	if (unlikely(!policy))
+		return;
+
 	for (i = 0; i < numscales; i++) {
 		if (mults[i] == maxmult) {
 			struct cpufreq_freqs freqs;
-- 
2.51.0