[PATCH AUTOSEL 6.18-6.6] regmap: maple: free entry on mas_store_gfp() failure

[PATCH AUTOSEL 6.18-6.6] regmap: maple: free entry on mas_store_gfp() failure

[Sasha Levin]

From: Kaushlendra Kumar <kaushlendra.kumar@intel.com>

[ Upstream commit f3f380ce6b3d5c9805c7e0b3d5bc28d9ec41e2e8 ]

regcache_maple_write() allocates a new block ('entry') to merge
adjacent ranges and then stores it with mas_store_gfp().
When mas_store_gfp() fails, the new 'entry' remains allocated and
is never freed, leaking memory.

Free 'entry' on the failure path; on success continue freeing the
replaced neighbor blocks ('lower', 'upper').

Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com>
Link: https://patch.msgid.link/20260105031820.260119-1-kaushlendra.kumar@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

### SUMMARY

**What the commit fixes:**
A memory leak in `regcache_maple_write()` where the allocated `entry`
block is not freed when `mas_store_gfp()` fails. This is a clear
resource leak bug.

**Why it matters to stable users:**
- Memory leaks affect system stability over time, especially on long-
  running embedded systems that commonly use regmap
- Under memory pressure scenarios, this leak compounds the problem
- regmap is core infrastructure used by many hardware drivers

**Stable kernel criteria assessment:**
1. ✅ **Obviously correct**: The fix follows standard kernel error
   handling patterns - allocate, try to use, free on failure
2. ✅ **Fixes a real bug**: Memory leak is a real, user-visible issue
3. ✅ **Important issue**: Memory leaks can lead to system
   instability/OOM
4. ✅ **Small and contained**: ~8 lines changed in a single file, single
   function
5. ✅ **No new features**: Pure bug fix
6. ✅ **Clean backport**: Self-contained fix with no dependencies

**Risk vs Benefit:**
- **Risk**: Very low - the change only affects the error path of
  `mas_store_gfp()` failure
- **Benefit**: Fixes a memory leak in widely-used infrastructure code
- The logic is straightforward and the fix is obviously correct

**Affected versions:**
- The regcache-maple.c file was introduced in v6.4
- Applicable to stable trees: 6.4.y, 6.6.y (LTS), and newer

**Concerns:**
- None - this is a textbook stable backport candidate

**YES**

 drivers/base/regmap/regcache-maple.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/base/regmap/regcache-maple.c b/drivers/base/regmap/regcache-maple.c
index 2319c30283a6d..9cf0384ce7b95 100644
--- a/drivers/base/regmap/regcache-maple.c
+++ b/drivers/base/regmap/regcache-maple.c
@@ -95,12 +95,13 @@ static int regcache_maple_write(struct regmap *map, unsigned int reg,
 
 	mas_unlock(&mas);
 
-	if (ret == 0) {
-		kfree(lower);
-		kfree(upper);
+	if (ret) {
+		kfree(entry);
+		return ret;
 	}
-	
-	return ret;
+	kfree(lower);
+	kfree(upper);
+	return 0;
 }
 
 static int regcache_maple_drop(struct regmap *map, unsigned int min,
-- 
2.51.0

[PATCH AUTOSEL 6.18] tracing: Avoid possible signed 64-bit truncation

[Sasha Levin]

From: Ian Rogers <irogers@google.com>

[ Upstream commit 00f13e28a9c3acd40f0551cde7e9d2d1a41585bf ]

64-bit truncation to 32-bit can result in the sign of the truncated
value changing. The cmp_mod_entry is used in bsearch and so the
truncation could result in an invalid search order. This would only
happen were the addresses more than 2GB apart and so unlikely, but
let's fix the potentially broken compare anyway.

Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Link: https://patch.msgid.link/20260108002625.333331-1-irogers@google.com
Signed-off-by: Ian Rogers <irogers@google.com>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The original buggy code was introduced in v6.15 and later. It's only
present in 6.15+ kernels.

### 8. SUMMARY OF ANALYSIS

**The Bug:**
- The `cmp_mod_entry()` function uses subtraction of two `unsigned long`
  values and returns the result as `int`
- On 64-bit systems, if addresses differ by more than 2^31 (~2GB), the
  truncation from 64-bit to 32-bit can flip the sign
- This would cause `bsearch()` to make wrong decisions about search
  direction
- Result: potentially incorrect module address lookups in trace data

**The Fix:**
- Replaces arithmetic subtraction with simple comparisons
- Returns -1, 0, or 1 directly based on comparisons
- No overflow or truncation possible with the new code
- Logic is more readable and provably correct

**Stable Criteria Evaluation:**
1. ✅ **Obviously correct and tested**: Simple logic, reviewed by
   maintainers
2. ✅ **Fixes a real bug**: Yes, a potential comparator correctness bug
3. ⚠️ **Important issue**: Moderate - unlikely to trigger (requires >2GB
   address separation) but could cause incorrect trace output
4. ✅ **Small and contained**: Only changes one function body (~6 lines)
5. ✅ **No new features**: Pure bug fix
6. ✅ **Applies cleanly**: Should apply to 6.15+ kernels where this code
   exists

**Risk Assessment:**
- Very low risk - the change is small and the new logic is simpler
- The original code has a provable bug (integer overflow on truncation)
- The new code has no such issues

**Concerns:**
- The code only exists in 6.15+ kernels (introduced March 2025)
- The bug is "unlikely" per the author (requires addresses >2GB apart)
- No known real-world reports of this actually causing issues

### DECISION

This is a valid bug fix that:
- Fixes a real (though unlikely to trigger) bug in the comparator
  function
- Is very small and self-contained
- Has been reviewed and acked by the tracing maintainers
- Has near-zero regression risk
- Applies to 6.15+ kernels only

The fix is surgical, obviously correct, and addresses a potential
correctness issue. While the bug is unlikely to trigger in practice
(addresses must be >2GB apart), it could cause silent data corruption in
trace output when it does trigger. The fix is trivial and risk-free.

**YES**

 kernel/trace/trace.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 142e3b737f0bc..907923d5f8bbb 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -6061,10 +6061,10 @@ static int cmp_mod_entry(const void *key, const void *pivot)
 	unsigned long addr = (unsigned long)key;
 	const struct trace_mod_entry *ent = pivot;
 
-	if (addr >= ent[0].mod_addr && addr < ent[1].mod_addr)
-		return 0;
-	else
-		return addr - ent->mod_addr;
+	if (addr < ent[0].mod_addr)
+		return -1;
+
+	return addr >= ent[1].mod_addr;
 }
 
 /**
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.6] regmap: maple: free entry on mas_store_gfp() failure

[Sasha Levin]

From: Kaushlendra Kumar <kaushlendra.kumar@intel.com>

[ Upstream commit f3f380ce6b3d5c9805c7e0b3d5bc28d9ec41e2e8 ]

regcache_maple_write() allocates a new block ('entry') to merge
adjacent ranges and then stores it with mas_store_gfp().
When mas_store_gfp() fails, the new 'entry' remains allocated and
is never freed, leaking memory.

Free 'entry' on the failure path; on success continue freeing the
replaced neighbor blocks ('lower', 'upper').

Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com>
Link: https://patch.msgid.link/20260105031820.260119-1-kaushlendra.kumar@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

### SUMMARY

**What the commit fixes:**
A memory leak in `regcache_maple_write()` where the allocated `entry`
block is not freed when `mas_store_gfp()` fails. This is a clear
resource leak bug.

**Why it matters to stable users:**
- Memory leaks affect system stability over time, especially on long-
  running embedded systems that commonly use regmap
- Under memory pressure scenarios, this leak compounds the problem
- regmap is core infrastructure used by many hardware drivers

**Stable kernel criteria assessment:**
1. ✅ **Obviously correct**: The fix follows standard kernel error
   handling patterns - allocate, try to use, free on failure
2. ✅ **Fixes a real bug**: Memory leak is a real, user-visible issue
3. ✅ **Important issue**: Memory leaks can lead to system
   instability/OOM
4. ✅ **Small and contained**: ~8 lines changed in a single file, single
   function
5. ✅ **No new features**: Pure bug fix
6. ✅ **Clean backport**: Self-contained fix with no dependencies

**Risk vs Benefit:**
- **Risk**: Very low - the change only affects the error path of
  `mas_store_gfp()` failure
- **Benefit**: Fixes a memory leak in widely-used infrastructure code
- The logic is straightforward and the fix is obviously correct

**Affected versions:**
- The regcache-maple.c file was introduced in v6.4
- Applicable to stable trees: 6.4.y, 6.6.y (LTS), and newer

**Concerns:**
- None - this is a textbook stable backport candidate

**YES**

 drivers/base/regmap/regcache-maple.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/base/regmap/regcache-maple.c b/drivers/base/regmap/regcache-maple.c
index 2319c30283a6d..9cf0384ce7b95 100644
--- a/drivers/base/regmap/regcache-maple.c
+++ b/drivers/base/regmap/regcache-maple.c
@@ -95,12 +95,13 @@ static int regcache_maple_write(struct regmap *map, unsigned int reg,
 
 	mas_unlock(&mas);
 
-	if (ret == 0) {
-		kfree(lower);
-		kfree(upper);
+	if (ret) {
+		kfree(entry);
+		return ret;
 	}
-	
-	return ret;
+	kfree(lower);
+	kfree(upper);
+	return 0;
 }
 
 static int regcache_maple_drop(struct regmap *map, unsigned int min,
-- 
2.51.0