In __print_txpwr_map(), memory is allocated to bufp via vzalloc().
If max_valid_addr is 0, the function returns -EOPNOTSUPP immediately
without freeing bufp, leading to a memory leak.

Fix this by freeing the temporary buffer bufp in the error path.

Compile tested only. Issue found using a prototype static analysis tool
and code review.

Fixes: 036042e15770 ("wifi: rtw89: debug: txpwr table supports Wi-Fi 7 chips")
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
---
 drivers/net/wireless/realtek/rtw89/debug.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtw89/debug.c b/drivers/net/wireless/realtek/rtw89/debug.c
index 1264c2f82600..c7bd1d0212b6 100644
--- a/drivers/net/wireless/realtek/rtw89/debug.c
+++ b/drivers/net/wireless/realtek/rtw89/debug.c
@@ -834,8 +834,10 @@ static ssize_t __print_txpwr_map(struct rtw89_dev *rtwdev, char *buf, size_t buf
 	else
 		max_valid_addr = map->addr_to;
 
-	if (max_valid_addr == 0)
+	if (max_valid_addr == 0) {
+		vfree(bufp);
 		return -EOPNOTSUPP;
+	}
 
 	for (addr = map->addr_from; addr <= max_valid_addr; addr += 4) {
 		ret = rtw89_mac_txpwr_read32(rtwdev, RTW89_PHY_0, addr, &val);
-- 
2.34.1

…
> Fix this by freeing the temporary buffer bufp in the error path.
…

How do you think about to use an attribute like “__free(vfree)”?
https://elixir.bootlin.com/linux/v6.19-rc5/source/drivers/net/wireless/realtek/rtw89/debug.c#L815-L858

Regards,
Markus

Markus Elfring <Markus.Elfring@web.de> wrote:
> 
> …
> > Fix this by freeing the temporary buffer bufp in the error path.
> …
> 
> How do you think about to use an attribute like “__free(vfree)”?
> https://elixir.bootlin.com/linux/v6.19-rc5/source/drivers/net/wireless/realtek/rtw89/debug.c#
> L815-L858
> 

Using __free(XXX) is fine to me.
But, I don't seem to see DEFINE_FREE(vfree, ...) yet.
So perhaps, need to use __free(kvfree).

> But, I don't seem to see DEFINE_FREE(vfree, ...) yet.
…

Would you dare to support the addition of such a macro call anyhow?
https://elixir.bootlin.com/linux/v6.19-rc5/source/include/linux/cleanup.h#L157-L161

Regards,
Markus

For the record, everyone, please just ignore Markus. I've told him
numerous times to just leave us alone.

johannes

Zilin Guan <zilin@seu.edu.cn> wrote:
> 
> In __print_txpwr_map(), memory is allocated to bufp via vzalloc().
> If max_valid_addr is 0, the function returns -EOPNOTSUPP immediately
> without freeing bufp, leading to a memory leak.
> 
> Fix this by freeing the temporary buffer bufp in the error path.
> 
> Compile tested only. Issue found using a prototype static analysis tool
> and code review.
> 
> Fixes: 036042e15770 ("wifi: rtw89: debug: txpwr table supports Wi-Fi 7 chips")
> Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
> ---
>  drivers/net/wireless/realtek/rtw89/debug.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtw89/debug.c
> b/drivers/net/wireless/realtek/rtw89/debug.c
> index 1264c2f82600..c7bd1d0212b6 100644
> --- a/drivers/net/wireless/realtek/rtw89/debug.c
> +++ b/drivers/net/wireless/realtek/rtw89/debug.c
> @@ -834,8 +834,10 @@ static ssize_t __print_txpwr_map(struct rtw89_dev *rtwdev, char
> *buf, size_t buf
>         else
>                 max_valid_addr = map->addr_to;
> 
> -       if (max_valid_addr == 0)
> +       if (max_valid_addr == 0) {
> +               vfree(bufp);
>                 return -EOPNOTSUPP;
> +       }

Thank you for catching this.
Since the decision for max_valid_addr doesn't depend on bufp,
how about moving vzalloc down here ?

> 
>         for (addr = map->addr_from; addr <= max_valid_addr; addr += 4) {
>                 ret = rtw89_mac_txpwr_read32(rtwdev, RTW89_PHY_0, addr, &val);
> --
> 2.34.1
> 

On Fri, Jan 16, 2026 at 08:23:57AM +0000, Zong-Zhe Yang wrote:
> > @@ -834,8 +834,10 @@ static ssize_t __print_txpwr_map(struct rtw89_dev *rtwdev, char
> > *buf, size_t buf
> >         else
> >                 max_valid_addr = map->addr_to;
> > 
> > -       if (max_valid_addr == 0)
> > +       if (max_valid_addr == 0) {
> > +               vfree(bufp);
> >                 return -EOPNOTSUPP;
> > +       }
> 
> Thank you for catching this.
> Since the decision for max_valid_addr doesn't depend on bufp,
> how about moving vzalloc down here ?
> 
> > 
> >         for (addr = map->addr_from; addr <= max_valid_addr; addr += 4) {
> >                 ret = rtw89_mac_txpwr_read32(rtwdev, RTW89_PHY_0, addr, &val);
> > --
> > 2.34.1
> > 

Thanks for your suggestion. I agree that moving vzalloc() after the check 
is a cleaner solution. I will send a v2 patch to address this.

Best Regards,
Zilin Guan