All of lore.kernel.org
 help / color / mirror / Atom feed
From: Francesco Dolcini <francesco@dolcini.it>
To: Doruk Tan Ozturk <doruk@0sec.ai>
Cc: Francesco Dolcini <francesco@dolcini.it>,
	Brian Norris <briannorris@chromium.org>,
	Kees Cook <kees@kernel.org>,
	linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] wifi: mwifiex: validate HT/VHT capability and operation IE lengths
Date: Wed, 15 Jul 2026 18:34:58 +0200	[thread overview]
Message-ID: <20260715163458.GA149147@francesco-nb> (raw)
In-Reply-To: <20260715162800.1922-1-doruk@0sec.ai>

On Wed, Jul 15, 2026 at 06:28:00PM +0200, Doruk Tan Ozturk wrote:
> > why break and not return -EINVAL? (this in general, not only on this
> > specific one).
> 
> To skip the one malformed optional element and keep parsing the rest of the
> beacon, like the FH/DS/CF/IBSS cases just above in the same loop. Happy to
> switch to -EINVAL if you'd rather reject the whole BSS.

maybe I am missing something, but I see return -EINVAL; when the packet
is malformed. see for example

		case WLAN_EID_VENDOR_SPECIFIC:
			vendor_ie = (struct ieee_types_vendor_specific *)
					current_ptr;

			/* 802.11 requires at least 3-byte OUI. */
			if (element_len < sizeof(vendor_ie->vend_hdr.oui.oui))
				return -EINVAL;


My advise would be to do the same we are already doing, and unless I am
wrong, it means that we skip the whole frame if a corruption is
detected.

Francesco



  reply	other threads:[~2026-07-15 16:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-09 10:08 [PATCH] wifi: mwifiex: validate HT/VHT capability and operation IE lengths Doruk Tan Ozturk
2026-07-15 14:40 ` Francesco Dolcini
2026-07-15 16:28   ` Doruk Tan Ozturk
2026-07-15 16:34     ` Francesco Dolcini [this message]
2026-07-15 18:33       ` Doruk Tan Ozturk
2026-07-15 18:55 ` [PATCH v2] " Doruk Tan Ozturk

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=20260715163458.GA149147@francesco-nb \
    --to=francesco@dolcini.it \
    --cc=briannorris@chromium.org \
    --cc=doruk@0sec.ai \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --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 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.