All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zong-Zhe Yang <kevin_yang@realtek.com>
To: Johannes Berg <johannes@sipsolutions.net>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: RE: [PATCH] wifi: mac80211: fix NULL dereference at band check in starting tx ba session
Date: Fri, 14 Jun 2024 07:53:54 +0000	[thread overview]
Message-ID: <2f22d58d3f7b4da9a7887fc0bfa3d264@realtek.com> (raw)
In-Reply-To: <c3ce5ca1cb434c2ff4b9ee3a1be9d81bf5ae01b2.camel@sipsolutions.net>

Johannes Berg <johannes@sipsolutions.net> wrote:

> On Thu, 2024-05-30 at 13:49 +0000, Zong-Zhe Yang wrote:
> >
> > I think there are two points here.
> >
> > 1. the way to avoid this NULL dereference (Current patch just followed
> > original logic and made it runnable on both MLD and non-MLD.)
> >
> > According to comments, I will change to check
> ht_supported/vht_supported/has_he/has_eht.
> > Then, it doesn't need to reference chanreq.oper.chan here. So, there won't be NULL
> dereference.
> >
> > 2. the check logic when MLD
> > (Current patch didn't consider this properly.)
> >
> > According to spec., BA agreement does once per TID and apply to all corresponding links.
> > So, I am thinking maybe I check the conditions on all valid_links when MLD.
> > And, only check deflink when non-MLD.
> 
> Well, spec also requires that you have EHT (on all links) to be able to do MLO in the first place,
> so you shouldn't be connected. IOW, checking one link should be sufficient? And that can even
> be deflink, because for a STA that's always used as the assoc link (unlike for vif)
> 

Then I am thinking to just check ht_supported/vht_supported/has_he/has_eht on sta deflink,
whether non-MLD connection or MLD connection.
Any further suggestions?


  reply	other threads:[~2024-06-14  7:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-23  8:22 [PATCH] wifi: mac80211: fix NULL dereference at band check in starting tx ba session kevin_yang
2024-05-25 10:01 ` Kalle Valo
2024-05-27  6:46   ` Zong-Zhe Yang
2024-05-27  8:51     ` Kalle Valo
2024-05-29 13:22 ` Johannes Berg
2024-05-30 13:49   ` Zong-Zhe Yang
2024-06-07 17:26     ` Johannes Berg
2024-06-14  7:53       ` Zong-Zhe Yang [this message]
2024-06-17 12:37       ` Zong-Zhe Yang

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=2f22d58d3f7b4da9a7887fc0bfa3d264@realtek.com \
    --to=kevin_yang@realtek.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@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 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.