All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Pei Xiao <xiaopei01@kylinos.cn>,
	Guenter Roeck <linux@roeck-us.net>,
	Sasha Levin <sashal@kernel.org>,
	linux-hwmon@vger.kernel.org
Subject: [PATCH AUTOSEL 6.18-6.17] hwmon: (emc2305) fix device node refcount leak in error path
Date: Thu, 11 Dec 2025 21:08:57 -0500	[thread overview]
Message-ID: <20251212020903.4153935-5-sashal@kernel.org> (raw)
In-Reply-To: <20251212020903.4153935-1-sashal@kernel.org>

From: Pei Xiao <xiaopei01@kylinos.cn>

[ Upstream commit 4910da6b36b122db50a27fabf6ab7f8611b60bf8 ]

The for_each_child_of_node() macro automatically manages device node
reference counts during normal iteration. However, when breaking out
of the loop early with return, the current iteration's node is not
automatically released, leading to a reference count leak.

Fix this by adding of_node_put(child) before returning from the loop
when emc2305_set_single_tz() fails.

This issue could lead to memory leaks over multiple probe cycles.

Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
Link: https://lore.kernel.org/r/tencent_5CDC08544C901D5ECA270573D5AEE3117108@qq.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of Commit: hwmon: (emc2305) fix device node refcount leak in
error path

### 1. COMMIT MESSAGE ANALYSIS

**Subject:** Clear "fix" language indicates a bug fix targeting a
"refcount leak" in an "error path"

**Body explanation:**
- The `for_each_child_of_node()` macro manages device node reference
  counts internally
- When breaking out of the loop early with `return`, the current node's
  reference is NOT automatically released
- This causes a reference count leak leading to memory leaks over
  multiple probe cycles

**Tags present:**
- `Signed-off-by` from author and maintainer (Guenter Roeck)
- `Link:` to mailing list discussion

**Tags missing:**
- No `Cc: stable@vger.kernel.org`
- No `Fixes:` tag

### 2. CODE CHANGE ANALYSIS

The fix is extremely small and surgical:

```c
for_each_child_of_node(dev->of_node, child) {
    ret = emc2305_set_single_tz(dev, child, i);
- if (ret != 0)
+   if (ret != 0) {
+       of_node_put(child);
        return ret;
+   }
    i++;
}
```

**Technical mechanism:**
- `for_each_child_of_node()` calls `of_node_get()` on each child
  internally
- On normal loop completion, the macro decrements the refcount
- On early exit (return/break), the caller must manually call
  `of_node_put()` to release the reference
- Without this, each failed probe leaves an unreleased reference →
  memory leak

**Root cause:** Missing required cleanup call when breaking out of
device tree iterator macro

**Why fix is correct:** This is the standard, well-documented pattern in
the Linux kernel for handling early exits from
`for_each_child_of_node()`. Adding `of_node_put(child)` before return is
textbook correct.

### 3. CLASSIFICATION

- **Bug type:** Resource leak (reference count / memory leak)
- **Category:** Standard bug fix
- **Security:** Not a security issue
- **New features:** None

### 4. SCOPE AND RISK ASSESSMENT

| Metric | Value |
|--------|-------|
| Lines changed | 3 (effectively +1 functional line) |
| Files touched | 1 |
| Complexity | Very low |
| Risk | Near zero |

**Risk analysis:**
- The fix only adds a cleanup call in an error path that already returns
  immediately
- Cannot possibly affect normal operation
- The `of_node_put()` function is well-tested core kernel infrastructure
- Adding required cleanup where it was missing cannot cause regression

### 5. USER IMPACT

**Affected users:** Those with EMC2305 fan controller hardware using
device tree

**Trigger conditions:**
1. Device must have child nodes in device tree
2. `emc2305_set_single_tz()` must fail
3. Must happen repeatedly over time

**Severity:** Low to medium - memory leak that accumulates over multiple
failed probe cycles. Not a crash or security issue, but can eventually
exhaust memory on long-running systems.

### 6. STABILITY INDICATORS

- Accepted by hwmon subsystem maintainer (Guenter Roeck)
- Simple, well-understood fix pattern
- No complex interactions possible

### 7. DEPENDENCY CHECK

- No dependencies on other commits
- `for_each_child_of_node()` and `of_node_put()` are long-standing
  kernel APIs
- The emc2305 driver must exist in the target stable tree

---

## Summary

**What the commit fixes:** A device node reference count leak in the
emc2305 hwmon driver that occurs when `emc2305_set_single_tz()` fails
during probe. This can lead to memory leaks over multiple probe cycles.

**Stable kernel rules assessment:**
1. ✅ **Obviously correct:** Standard kernel pattern, textbook fix
2. ✅ **Fixes real bug:** Yes, reference count leak causing memory leak
3. ⚠️ **Important issue:** Moderate severity - memory leak in error path
4. ✅ **Small and contained:** 3 lines changed in 1 file
5. ✅ **No new features:** Pure bug fix
6. ✅ **Clean application:** Should apply cleanly

**Risk vs Benefit:**
- **Risk:** Essentially zero - adds required cleanup in error path
- **Benefit:** Prevents memory leak on systems using this hardware

**Concerns:**
- No explicit `Cc: stable` tag from maintainer
- Bug requires specific error condition to trigger
- Affects only specific hardware

**Verdict:** Despite the lack of explicit stable tagging, this fix is a
textbook example of a safe backport candidate. The fix is trivially
correct, follows a well-established kernel pattern, has zero risk of
regression, and fixes a real (if low-severity) resource leak. Similar
`for_each_child_of_node()` refcount leak fixes are regularly backported
to stable trees.

**YES**

 drivers/hwmon/emc2305.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/emc2305.c b/drivers/hwmon/emc2305.c
index 60809289f8169..84cb9b72cb6c2 100644
--- a/drivers/hwmon/emc2305.c
+++ b/drivers/hwmon/emc2305.c
@@ -685,8 +685,10 @@ static int emc2305_probe(struct i2c_client *client)
 			i = 0;
 			for_each_child_of_node(dev->of_node, child) {
 				ret = emc2305_set_single_tz(dev, child, i);
-				if (ret != 0)
+				if (ret != 0) {
+					of_node_put(child);
 					return ret;
+				}
 				i++;
 			}
 		} else {
-- 
2.51.0


  parent reply	other threads:[~2025-12-12  2:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-12  2:08 [PATCH AUTOSEL 6.18-5.15] platform/x86/intel/hid: Add Dell Pro Rugged 10/12 tablet to VGBS DMI quirks Sasha Levin
2025-12-12  2:08 ` [PATCH AUTOSEL 6.18-5.10] nvme-fc: don't hold rport lock when putting ctrl Sasha Levin
2025-12-12  2:08 ` [PATCH AUTOSEL 6.18-6.17] hwmon: (emc2305) fix double put in emc2305_probe_childs_from_dt Sasha Levin
2025-12-12  2:08 ` [PATCH AUTOSEL 6.18-6.17] platform/x86: wmi-gamezone: Add Legion Go 2 Quirks Sasha Levin
2025-12-12  2:08 ` Sasha Levin [this message]
2025-12-12  2:08 ` [PATCH AUTOSEL 6.18-6.12] nvme-fabrics: add ENOKEY to no retry criteria for authentication failures Sasha Levin
2025-12-12  2:08 ` [PATCH AUTOSEL 6.18-6.6] i2c: designware: Disable SMBus interrupts to prevent storms from mis-configured firmware Sasha Levin
2025-12-12  2:09 ` [PATCH AUTOSEL 6.18-6.6] MIPS: ftrace: Fix memory corruption when kernel is located beyond 32 bits Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251212020903.4153935-5-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=patches@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    --cc=xiaopei01@kylinos.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.