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:03:05 +0200 [thread overview]
Message-ID: <1286560985.3612.12.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <AANLkTin6nwrhcGdnGxg_gMGSrD_GBc-R51qiendF4iAc@mail.gmail.com>
On Fri, 2010-10-08 at 10:56 -0700, Javier Cardona wrote:
> We believe Christian's second patch fixes a null-pointer de-reference
> that would be triggered by a PLINK_OPEN frame with
> mismatching/incompatible mesh configuration. Let's analyze that case:
>
> void mesh_rx_plink_frame(...)
> (...)
> sta = sta_info_get(sdata, mgmt->sa); <-- will return null
> if (!sta && ftype != PLINK_OPEN) { <-- false for PLINK_OPEN frames
> (...)
> if (ftype != PLINK_CLOSE && (!mesh_matches_local(&elems, sdata))) {
> <-- true for PLINK_OPEN, non-compatible mesh config
> (...)
> spin_lock_bh(&sta->lock); <-- boom!
Good point. I glossed over the part here and just looked at the else
branch with !sta.
> The patch not only solves this problem, but also responds correctly to
> non-compatible PLINK_OPEN frames by generating a PLINK_CLOSE with the
> right reason code.
But then you can't ever actually properly process a *matching*
PLINK_OPEN frame, afaict, because those definitely do have
"!sta && ftype == PLINK_OPEN"
which is how the "if (!sta && ftype != PLINK_OPEN) return" came about,
afaict.
So I still don't think it's quite correct to fix it this way.
johannes
next prev parent reply other threads:[~2010-10-08 18:03 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 [this message]
2010-10-08 18:25 ` Javier Cardona
2010-10-08 18:28 ` Johannes Berg
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=1286560985.3612.12.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).