From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Diksha Kumari <dikshakdevgan@gmail.com>,
Mukesh Kumar Chaurasiya <mkchauras@linux.ibm.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 memory leak on failure path
Date: Wed, 18 Feb 2026 21:03:39 -0500 [thread overview]
Message-ID: <20260219020422.1539798-3-sashal@kernel.org> (raw)
In-Reply-To: <20260219020422.1539798-1-sashal@kernel.org>
From: Diksha Kumari <dikshakdevgan@gmail.com>
[ Upstream commit abe850d82c8cb72d28700673678724e779b1826e ]
cfg80211_inform_bss_frame() may return NULL on failure. In that case,
the allocated buffer 'buf' is not freed and the function returns early,
leading to potential memory leak.
Fix this by ensuring that 'buf' is freed on both success and failure paths.
Signed-off-by: Diksha Kumari <dikshakdevgan@gmail.com>
Reviewed-by: Mukesh Kumar Chaurasiya <mkchauras@linux.ibm.com>
Link: https://patch.msgid.link/20260113091712.7071-1-dikshakdevgan@gmail.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 bug has been present since the original commit `554c0a3abf216c`
(Hans de Goede, 2017-03-29) — this is a long-standing bug.
## Verification Summary
- **git blame** confirmed the buggy code (the `goto exit` skipping
`kfree(buf)`) has been present since commit `554c0a3abf216c` from
March 2017 — this is a long-standing bug present in all stable trees
that carry this driver.
- **Code reading** confirmed `buf` is allocated at line 283 with
`kzalloc(MAX_BSSINFO_LEN, GFP_ATOMIC)` and only freed at line 321,
which is skipped when `goto exit` is taken at line 318.
- **The fix is trivially correct**: it changes `goto exit` to `goto
free_buf`, where `free_buf` is placed before `kfree(buf)`, ensuring
the buffer is always freed.
- The function `rtw_cfg80211_inform_bss()` is called during WiFi
scanning, which happens regularly — this leak is in a hot path, not a
one-time init path.
- This is a **staging driver**. Per stable kernel conventions, staging
changes are "usually not stable material." However, rtl8723bs is
widely used and this is a genuine, trivially-correct memory leak fix.
## Decision
This is a clear, trivially correct memory leak fix that meets all stable
kernel criteria:
- Fixes a real bug (memory leak on error path)
- Small and contained (3 lines changed in 1 file)
- Obviously correct
- No risk of regression
- Long-standing bug (since 2017) present in all stable trees carrying
this driver
The only concern is that this is a staging driver, which weakens the
case slightly. However, the rtl8723bs driver is widely used (common
Realtek WiFi chipset in budget devices), the fix is trivially correct,
and memory leaks in scanning code can cause real user-visible issues
(memory exhaustion over time). The fix was reviewed and accepted by Greg
Kroah-Hartman.
**YES**
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index 60edeae1cffe7..476ab055e53e5 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -315,9 +315,10 @@ struct cfg80211_bss *rtw_cfg80211_inform_bss(struct adapter *padapter, struct wl
len, notify_signal, GFP_ATOMIC);
if (unlikely(!bss))
- goto exit;
+ goto free_buf;
cfg80211_put_bss(wiphy, bss);
+free_buf:
kfree(buf);
exit:
--
2.51.0
next parent reply other threads:[~2026-02-19 2:04 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 ` Sasha Levin [this message]
2026-02-19 2:04 ` [PATCH AUTOSEL 6.19-5.15] staging: rtl8723bs: fix missing status update on sdio_alloc_irq() failure 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=20260219020422.1539798-3-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=dikshakdevgan@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=mkchauras@linux.ibm.com \
--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