public inbox for linux-staging@lists.linux.dev
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Liang Jie <liangjie@lixiang.com>, fanggeng <fanggeng@lixiang.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Sasha Levin <sashal@kernel.org>,
	linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: [PATCH AUTOSEL 6.19-5.15] staging: rtl8723bs: fix missing status update on sdio_alloc_irq() failure
Date: Wed, 18 Feb 2026 21:04:12 -0500	[thread overview]
Message-ID: <20260219020422.1539798-36-sashal@kernel.org> (raw)
In-Reply-To: <20260219020422.1539798-1-sashal@kernel.org>

From: Liang Jie <liangjie@lixiang.com>

[ Upstream commit 618b4aec12faabc7579a6b0df046842d798a4c7c ]

The return value of sdio_alloc_irq() was not stored in status.
If sdio_alloc_irq() fails after rtw_drv_register_netdev() succeeds,
status remains _SUCCESS and the error path skips resource cleanup,
while rtw_drv_init() still returns success.

Store the return value of sdio_alloc_irq() in status and reuse the
existing error handling which relies on status.

Reviewed-by: fanggeng <fanggeng@lixiang.com>
Signed-off-by: Liang Jie <liangjie@lixiang.com>
Link: https://patch.msgid.link/20251208092730.262499-1-buaajxlj@163.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The driver has a long history with 2020 commits, meaning it's well-
established in the kernel tree and present in stable trees.

## Decision Analysis

**Arguments for YES:**
- Fixes a real bug: resource leak and incorrect success return on error
  path
- Extremely small and surgical change (2 lines)
- Obviously correct - uses the same pattern as the line above it
- Low risk of regression
- The bug has been confirmed by code review (verified above at line 380)
- Reviewed by one reviewer and accepted by Greg Kroah-Hartman

**Arguments for NO:**
- This is a **staging driver** - stable kernel rules note staging
  drivers are usually not stable material
- The bug only triggers on `sdio_alloc_irq()` failure - an error path
- Staging drivers are explicitly called out as usually not appropriate
  for stable

## Verification

- Read the actual source file at
  `drivers/staging/rtl8723bs/os_dep/sdio_intf.c` lines 350-409:
  confirmed the bug at line 380 where `sdio_alloc_irq()` return value is
  discarded while `status` remains `_SUCCESS` from line 376
- Confirmed the cleanup at lines 386-391 uses `status != _SUCCESS`
  checks, so with `status == _SUCCESS`, cleanup of `if1` and `dvobj`
  would be skipped
- Confirmed via `git log` that the driver has extensive history (2020
  commits) and exists in stable trees
- The commit was reviewed and merged by Greg Kroah-Hartman (staging
  maintainer)
- The diff is only 2 lines changed, making it trivially correct

## Final Assessment

While this is a legitimate bug fix that is small, safe, and obviously
correct, it affects a **staging driver**. Staging drivers are generally
considered not stable material because they are experimental, may have
many other bugs, and are expected to be in flux. The bug only triggers
on an error path (`sdio_alloc_irq()` failure), which limits real-world
impact.

However, rtl8723bs is one of the most widely-used staging drivers (found
in many budget ARM tablets and SBCs), and the fix is truly trivial with
zero risk. The resource leak and incorrect return value on IRQ
allocation failure are real bugs that could affect users. Given the
minimal risk and clear correctness, this is a borderline case that leans
toward YES despite being in staging.

**YES**

 drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
index 1d0239eef114b..dc787954126fd 100644
--- a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
+++ b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
@@ -377,7 +377,8 @@ static int rtw_drv_init(
 	if (status != _SUCCESS)
 		goto free_if1;
 
-	if (sdio_alloc_irq(dvobj) != _SUCCESS)
+	status = sdio_alloc_irq(dvobj);
+	if (status != _SUCCESS)
 		goto free_if1;
 
 	status = _SUCCESS;
-- 
2.51.0


      parent reply	other threads:[~2026-02-19  2:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260219020422.1539798-1-sashal@kernel.org>
2026-02-19  2:03 ` [PATCH AUTOSEL 6.19-5.15] staging: rtl8723bs: fix memory leak on failure path Sasha Levin
2026-02-19  2:04 ` Sasha Levin [this message]

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=20260219020422.1539798-36-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=fanggeng@lixiang.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=liangjie@lixiang.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=patches@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox