[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20260128223332.2806589-15-sashal@kernel.org>
Date: Wed, 28 Jan 2026 17:33:13 -0500
From: Sasha Levin <sashal@...nel.org>
To: patches@...ts.linux.dev,
stable@...r.kernel.org
Cc: Kaushlendra Kumar <kaushlendra.kumar@...el.com>,
Mark Brown <broonie@...nel.org>,
Sasha Levin <sashal@...nel.org>,
linux-kernel@...r.kernel.org
Subject: [PATCH AUTOSEL 6.18-6.6] regmap: maple: free entry on mas_store_gfp() failure
From: Kaushlendra Kumar <kaushlendra.kumar@...el.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@...el.com>
Link: https://patch.msgid.link/20260105031820.260119-1-kaushlendra.kumar@intel.com
Signed-off-by: Mark Brown <broonie@...nel.org>
Signed-off-by: Sasha Levin <sashal@...nel.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
Powered by blists - more mailing lists