Linux-Wireless Archive on lore.kernel.org
 help / color / Atom feed
From: Brian Norris <briannorris@chromium.org>
To: Takashi Iwai <tiwai@suse.de>
Cc: linux-wireless@vger.kernel.org,
	Amitkumar Karwar <amitkarwar@gmail.com>,
	Nishant Sarmukadam <nishants@marvell.com>,
	Ganapathi Bhat <gbhat@marvell.com>,
	Xinming Hu <huxinming820@gmail.com>,
	Kalle Valo <kvalo@codeaurora.org>,
	huangwen@venustech.com.cn, Solar Designer <solar@openwall.com>,
	Marcus Meissner <meissner@suse.de>
Subject: Re: [PATCH 2/2] mwifiex: Abort at too short BSS descriptor element
Date: Thu, 13 Jun 2019 11:38:37 -0700
Message-ID: <20190613183835.GA16432@google.com> (raw)
In-Reply-To: <s5hmuile4mg.wl-tiwai@suse.de>

On Thu, Jun 13, 2019 at 08:12:39PM +0200, Takashi Iwai wrote:
> On Thu, 13 Jun 2019 19:49:40 +0200,
> Brian Norris wrote:
> > On Wed, May 29, 2019 at 02:52:20PM +0200, Takashi Iwai wrote:
> > > --- a/drivers/net/wireless/marvell/mwifiex/scan.c
> > > +++ b/drivers/net/wireless/marvell/mwifiex/scan.c
> > > @@ -1269,6 +1269,8 @@ int mwifiex_update_bss_desc_with_ie(struct mwifiex_adapter *adapter,
> > >  			break;
> > >  
> > >  		case WLAN_EID_FH_PARAMS:
> > > +			if (element_len + 2 < sizeof(*fh_param_set))
> > 
> > "element_len + 2" would be much more readable as "total_ie_len". (Same for
> > several other usages in this patch.) I can send such a patch myself as a
> > follow-up I suppose.
> 
> Yes, please.

I'll wait until we straighten out the other (potentially) real bug.
Don't want to make needless conflicts.

> > > +				return -EINVAL;
> > >  			fh_param_set =
> > >  				(struct ieee_types_fh_param_set *) current_ptr;
> > >  			memcpy(&bss_entry->phy_param_set.fh_param_set,
> > 
> > [...]
> > 
> > > @@ -1349,6 +1361,9 @@ int mwifiex_update_bss_desc_with_ie(struct mwifiex_adapter *adapter,
> > >  			break;
> > >  
> > >  		case WLAN_EID_VENDOR_SPECIFIC:
> > > +			if (element_len + 2 < sizeof(vendor_ie->vend_hdr))
> > 
> > Why 'sizeof(vendor_ie->vend_hdr)'? The (mwifiex-specific compare with the
> > ieee80211.h generic struct ieee80211_vendor_ie) ieee_types_vendor_header struct
> > includes the 'oui_subtype' and 'version' fields, which are not standard
> > requirements for the vendor header (in fact, even the 4th byte of the
> > OUI -- "oui_type" -- doesn't appear to be in the 802.11 specification).
> > So it looks to me like you might be rejecting valid vendor headers (that
> > we should just be skipping) that might have vendor-specific content with
> > length 0 or 1 bytes.
> > 
> > It seems like we should only be validating the standard pieces (e.g., up to the
> > length/OUI), and only after an appropriate OUI match, *then* validating the rest of
> > the vendor element (the pieces we'll use later).
> 
> Hm, right, that looks too strict.  Instead we need to check right
> before both memcmp()'s of OUI.

I think this is the right place for one check (the memcmp() is right
after this line anyway) -- the minimum length just should be smaller.

e.g.:

sizeof(struct ieee80211_vendor_ie) // this is still technically 1 byte too large I think
or
offsetof(struct ieee80211_vendor_ie, oui_type) // not sure if this is the cleanest...

If it's smaller than that, we can still say -EINVAL.

Then, we can go with:

if (element_len < sizeof(wpa_oui)
	continue;

or similar.

So, I might say:

	/* Vendor IEs must at least contain the OUI. */
	if (total_ie_len < offsetof(struct ieee80211_vendor_ie, oui_type))
		return -EINVAL;

	/* If the IE still isn't long enough, it's not a match. */
	if (element_len < sizeof(wpa_oui))
		continue;

Brian

  reply index

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-29 12:52 [PATCH 0/2] Buffer overflow / read checks in mwifiex Takashi Iwai
2019-05-29 12:52 ` [PATCH 1/2] mwifiex: Fix possible buffer overflows at parsing bss descriptor Takashi Iwai
2019-05-30 11:22   ` Kalle Valo
2019-05-29 12:52 ` [PATCH 2/2] mwifiex: Abort at too short BSS descriptor element Takashi Iwai
2019-06-13 17:49   ` Brian Norris
2019-06-13 18:12     ` Takashi Iwai
2019-06-13 18:38       ` Brian Norris [this message]
2019-06-13 20:26         ` Brian Norris
2019-06-15  0:19     ` Brian Norris

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=20190613183835.GA16432@google.com \
    --to=briannorris@chromium.org \
    --cc=amitkarwar@gmail.com \
    --cc=gbhat@marvell.com \
    --cc=huangwen@venustech.com.cn \
    --cc=huxinming820@gmail.com \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=meissner@suse.de \
    --cc=nishants@marvell.com \
    --cc=solar@openwall.com \
    --cc=tiwai@suse.de \
    /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

Linux-Wireless Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-wireless/0 linux-wireless/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-wireless linux-wireless/ https://lore.kernel.org/linux-wireless \
		linux-wireless@vger.kernel.org
	public-inbox-index linux-wireless

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-wireless


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git