From: Johannes Berg <johannes@sipsolutions.net>
To: Javier Cardona <javier@cozybit.com>
Cc: Steve deRosier <steve@cozybit.com>,
Christian Lamparter <chunkeey@googlemail.com>,
"John W. Linville" <linville@tuxdriver.com>,
Luis Carlos Cobo <luisca@cozybit.com>,
linux-wireless@vger.kernel.org
Subject: Re: [RFC v2] mac80211: fix possible null-pointer dereference
Date: Fri, 08 Oct 2010 20:28:34 +0200 [thread overview]
Message-ID: <1286562514.3612.16.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <AANLkTikXeA=Q5C84-aaZeq1+vR8vFdXEEe5GyQfCDqr1@mail.gmail.com>
On Fri, 2010-10-08 at 11:25 -0700, Javier Cardona wrote:
> > But then you can't ever actually properly process a *matching*
> > PLINK_OPEN frame, afaict, because those definitely do have
> > "!sta && ftype == PLINK_OPEN"
>
> Not always: an sta can be created on reception of a beacon or probe
> response (mesh_neighbour_update()), so you could have ftype ==
> PLINK_OPEN and a non-null sta. Buy, yes, I agree that !sta && ftype ==
> PLINK_OPEN is a valid case.
Ah, indeed.
> > which is how the "if (!sta && ftype != PLINK_OPEN) return" came about,
> > afaict.
>
> Yes, and Christian's *second* patch (submitted as RFC on Sept 24) does
> not change that check. The matching PLINK_OPEN would be handled in
> the following branch:
>
> } else if (!sta) {
> /* ftype == PLINK_OPEN */
> u32 rates;
> (...)
> sta = mesh_plink_alloc(sdata, mgmt->sa, rates);
>
> > So I still don't think it's quite correct to fix it this way.
>
> Could it be that we are looking at different patches? Just to be
> sure, let me paste below the one we are referring to as sent by
> Christian:
Ahrg, yes, I always just went back to his first patch.
> ---
> diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
> index ea13a80..8b7efee 100644
> --- a/net/mac80211/mesh_plink.c
> +++ b/net/mac80211/mesh_plink.c
> @@ -412,7 +412,7 @@ void mesh_rx_plink_frame(struct
> ieee80211_sub_if_data *sdata, struct ieee80211_m
> enum plink_event event;
> enum plink_frame_type ftype;
> size_t baselen;
> - bool deactivated;
> + bool deactivated, matches_local = true;
> u8 ie_len;
> u8 *baseaddr;
> __le16 plid, llid, reason;
> @@ -487,6 +487,7 @@ void mesh_rx_plink_frame(struct
> ieee80211_sub_if_data *sdata, struct ieee80211_m
> /* Now we will figure out the appropriate event... */
> event = PLINK_UNDEFINED;
> if (ftype != PLINK_CLOSE && (!mesh_matches_local(&elems, sdata))) {
> + matches_local = false;
> switch (ftype) {
> case PLINK_OPEN:
> event = OPN_RJCT;
> @@ -498,7 +499,15 @@ void mesh_rx_plink_frame(struct
> ieee80211_sub_if_data *sdata, struct ieee80211_m
> /* avoid warning */
> break;
> }
> - spin_lock_bh(&sta->lock);
> + }
> +
> + if (!sta && !matches_local) {
> + rcu_read_unlock();
> + reason = cpu_to_le16(MESH_CAPABILITY_POLICY_VIOLATION);
> + llid = 0;
> + mesh_plink_frame_tx(sdata, PLINK_CLOSE, mgmt->sa, llid,
> + plid, reason);
> + return;
> } else if (!sta) {
> /* ftype == PLINK_OPEN */
> u32 rates;
> @@ -522,7 +531,7 @@ void mesh_rx_plink_frame(struct
> ieee80211_sub_if_data *sdata, struct ieee80211_m
> }
> event = OPN_ACPT;
> spin_lock_bh(&sta->lock);
> - } else {
> + } else if (matches_local) {
> spin_lock_bh(&sta->lock);
> switch (ftype) {
> case PLINK_OPEN:
> @@ -564,6 +573,8 @@ void mesh_rx_plink_frame(struct
> ieee80211_sub_if_data *sdata, struct ieee80211_m
> rcu_read_unlock();
> return;
> }
> + } else {
> + spin_lock_bh(&sta->lock);
> }
Yeah, this looks good. Sorry!
johannes
prev parent reply other threads:[~2010-10-08 18:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-20 22:57 [PATCH] mac80211: fix possible null-pointer dereference Christian Lamparter
2010-09-24 18:00 ` John W. Linville
2010-09-24 22:02 ` [RFC v2] " Christian Lamparter
2010-09-29 5:18 ` Jouni Malinen
2010-09-30 16:27 ` Bob Copeland
2010-09-30 16:52 ` Christian Lamparter
2010-10-01 8:25 ` Dan Carpenter
2010-10-07 22:38 ` Steve deRosier
2010-10-07 22:54 ` Johannes Berg
2010-10-08 17:56 ` Javier Cardona
2010-10-08 18:03 ` Johannes Berg
2010-10-08 18:25 ` Javier Cardona
2010-10-08 18:28 ` Johannes Berg [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=1286562514.3612.16.camel@jlt3.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=chunkeey@googlemail.com \
--cc=javier@cozybit.com \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=luisca@cozybit.com \
--cc=steve@cozybit.com \
/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.