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;