From: Greg KH <gregkh@linuxfoundation.org>
To: Sherlock Fang <wf27@st-andrews.ac.uk>
Cc: "security@kernel.org" <security@kernel.org>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: {Disarmed} Two potential 1-byte BOF in cfg80211.c of driver MWIFIEX
Date: Mon, 16 Sep 2024 00:45:05 +0200 [thread overview]
Message-ID: <2024091654-flagship-untried-1c23@gregkh> (raw)
In-Reply-To: <AM6PR06MB55447E199A092E593B82986AA0672@AM6PR06MB5544.eurprd06.prod.outlook.com>
On Sun, Sep 15, 2024 at 06:12:21PM +0000, Sherlock Fang wrote:
> Dear Security Team,
>
>
> I have used static code analysis tools to scan the Linux Kernel of the latest build, and with collaborative help from Prof. Yueqi Chen, we have been able to manually confirm the presence of two 1-byte BOF in drivers/net/wireless/marvell/mwifiex/cfg80211.c
>
> At both line https://github.com/torvalds/linux/blob/master/drivers/net/wireless/marvell/mwifiex/cfg80211.c#L2679 and https://github.com/torvalds/linux/blob/master/drivers/net/wireless/marvell/mwifiex/cfg80211.c#L2777, the calls to
>
> memcpy(&priv->vs_ie[i].ie, ie, sizeof(*ie) + ie->len);
>
> are theoretically possible to cause a buffer overflow since the destination buffer is an array of bytes with a size defined by MWIFIEX_MAX_VSIE_LEN<https://github.com/torvalds/linux/blob/master/drivers/net/wireless/marvell/mwifiex/ioctl.h#L416> of 256 bytes, which is the maximum amount of data that can safely be stored in priv->vs_ie[i].ie<https://github.com/torvalds/linux/blob/master/drivers/net/wireless/marvell/mwifiex/main.h#L483>. The size parameter "sizeof(*ie) + ie->len" theoretically has the maximum value of "2 + 255 = 257" given that len is of type u8 which has upper limit of 255, and sizeof(*ie) is equivalent to sizeof(struct ieee_types_header<https://github.com/torvalds/linux/blob/master/drivers/net/wireless/marvell/mwifiex/main.h#L343>), that is just the size of two u8 field (two bytes).
>
> Our suggested fix would be to add a check before calling memcpy:
>
> If (sizeof(*ie) + ie->len > sizeof(&priv->vs_ie[i].ie)) {
> continue;
> }
>
> memcpy(&priv->vs_ie[i].ie, ie, sizeof(*ie) + ie->len);
Great, can you submit a real patch for this so that it can be reviewed
and accepted if ok?
Also, you are sure that the data being copied could really be that big,
right? Where does it come from?
thanks,
greg k-h
next parent reply other threads:[~2024-09-15 22:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AM6PR06MB55447E199A092E593B82986AA0672@AM6PR06MB5544.eurprd06.prod.outlook.com>
2024-09-15 22:45 ` Greg KH [this message]
2024-09-16 6:57 ` {Disarmed} Two potential 1-byte BOF in cfg80211.c of driver MWIFIEX 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=2024091654-flagship-untried-1c23@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=linux-wireless@vger.kernel.org \
--cc=security@kernel.org \
--cc=wf27@st-andrews.ac.uk \
/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