mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Zong-Zhe Yang <kevin_yang@realtek.com>
To: Fedor Pchelkin <pchelkin@ispras.ru>
Cc: Ping-Ke Shih <pkshih@realtek.com>,
	Bernie Huang <phhuang@realtek.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"lvc-project@linuxtesting.org" <lvc-project@linuxtesting.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: RE: [PATCH rtw-next 1/2] wifi: rtw89: fix use-after-free in rtw89_core_tx_kick_off_and_wait()
Date: Fri, 22 Aug 2025 07:52:20 +0000	[thread overview]
Message-ID: <b534be02ec354e5e9d5808f82b7127b9@realtek.com> (raw)
In-Reply-To: <20250821113341-4d93a84ec8bcd73321acd2b7-pchelkin@ispras>

Fedor Pchelkin <pchelkin@ispras.ru> wrote:
> 
> [...]
> 
> > >
> > >  drivers/net/wireless/realtek/rtw89/core.c | 15 ++++++++---
> > > drivers/net/wireless/realtek/rtw89/core.h | 32
> > > ++++++++++++++--------- drivers/net/wireless/realtek/rtw89/pci.c  |
> > > 6 +++--
> > >  3 files changed, 36 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/realtek/rtw89/core.c
> > > b/drivers/net/wireless/realtek/rtw89/core.c
> > > index 57590f5577a3..826540319027 100644
> > > --- a/drivers/net/wireless/realtek/rtw89/core.c
> > > +++ b/drivers/net/wireless/realtek/rtw89/core.c
> > > @@ -1088,6 +1088,7 @@ int rtw89_core_tx_kick_off_and_wait(struct
> > > rtw89_dev *rtwdev, struct sk_buff *sk
> > >         struct rtw89_tx_skb_data *skb_data = RTW89_TX_SKB_CB(skb);
> > >         struct rtw89_tx_wait_info *wait;
> > >         unsigned long time_left;
> > > +       bool free_wait = true;
> > >         int ret = 0;
> > >
> > >         wait = kzalloc(sizeof(*wait), GFP_KERNEL); @@ -1097,7
> > > +1098,8 @@ int rtw89_core_tx_kick_off_and_wait(struct rtw89_dev *rtwdev, struct
> sk_buff *sk
> > >         }
> > >
> > >         init_completion(&wait->completion);
> > > -       rcu_assign_pointer(skb_data->wait, wait);
> > > +       spin_lock_init(&wait->owner_lock);
> > > +       skb_data->wait = wait;
> > >
> > >         rtw89_core_tx_kick_off(rtwdev, qsel);
> > >         time_left = wait_for_completion_timeout(&wait->completion,
> > > @@ -1107,8 +1109,15 @@ int rtw89_core_tx_kick_off_and_wait(struct
> > > rtw89_dev *rtwdev, struct sk_buff *sk
> > >         else if (!wait->tx_done)
> > >                 ret = -EAGAIN;
> > >
> > > -       rcu_assign_pointer(skb_data->wait, NULL);
> > > -       kfree_rcu(wait, rcu_head);
> >
> > Please consider the following.
> > (moving "rcu_assign_pointer(skb_data->wait, NULL)" to be under "if
> > (time_left == 0)")
> >
> 
> There is still a tiny race window. Suppose wait_for_completion_timeout() exits with a timeout,
> so time_left is 0. If completing side goes on in parallel just after that, it has a chance to
> proceed and free skb_data before the below if (time_left == 0) fragment is executed.

Okay, logically it sounds right.

> 
> >     if (time_left == 0) {
> >         rcu_assign_pointer(skb_data->wait, NULL);
> >         ret = -ETIMEDOUT;
> >     } else if (!wait->tx_done) {
> >         ret = -EAGAIN;
> >     }
> >
> >     kfree_rcu(wait, rcu_head);
> >
> > If completing side does run as expected (potential racing mentioned in
> > this patch), there is no real need to assign NULL back.
> 
> Actually the race happens regardless of wait_for_completion_timeout() exit status, it's briefly
> mentioned in the race diagram inside commit message (but the diagram can show only one
> possible concurrency scenario). I agree this may be improved and described more explicitly
> though.

Will appreciate to see that in next version. Thanks.

> 
> As for the patch itself, currently I can't see another way of fixing that other than introducing
> locks on both waiting and completing side.

I took some time on thinking this. The following is another idea.
The skb, which are sent by tx_wait_complete, are owned by driver.
They don't come from stack, so we don't need to do ieee80211_tx_status_ni.
Based on above, some rough points of the new idea are listed below.

1.
    Let rtw89_core_tx_wait_complete
        return true/false to indicate whether tx_wait or not

2.
    Add some new field into rtw89_tx_wait_info
        e.g. list_head, skb, finished

3.
    Add a list_head to rtwdev
    Add a work func doing things as
        for each wait in rtwdev->XXX_list:
            if !wait->finished:
                wait_for_completion()
            free wait->skb
            free wait

4.
         [waiting side]                               [completing side]
    wait_for_completion_timeout()                          ...
             ...                               /* make complete the last step */
             ...                               if (rtw89_core_tx_wait_complete)
             ...                                      return;
             ...
    // not assign NULL back to skb_data->wait
        if time_left != 0:
            wait-> finished = true
        wait->skb = skb
        add wait to rtwdev->XXX_list
        queue above work

Please help evaluate the new idea.
Thank you.


  reply	other threads:[~2025-08-22  7:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-20 14:13 [PATCH rtw-next 0/2] a couple of fixes for rtw89 Fedor Pchelkin
2025-08-20 14:13 ` [PATCH rtw-next 1/2] wifi: rtw89: fix use-after-free in rtw89_core_tx_kick_off_and_wait() Fedor Pchelkin
2025-08-21  4:01   ` Zong-Zhe Yang
2025-08-21  9:11     ` Fedor Pchelkin
2025-08-22  7:52       ` Zong-Zhe Yang [this message]
2025-08-20 14:13 ` [PATCH rtw-next 2/2] wifi: rtw89: avoid circular locking dependency in ser_state_run() Fedor Pchelkin

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=b534be02ec354e5e9d5808f82b7127b9@realtek.com \
    --to=kevin_yang@realtek.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lvc-project@linuxtesting.org \
    --cc=pchelkin@ispras.ru \
    --cc=phhuang@realtek.com \
    --cc=pkshih@realtek.com \
    --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

all inboxes | Powered by JetHome®