From: Felix Fietkau <nbd@nbd.name>
To: Johannes Berg <johannes@sipsolutions.net>,
Dan Carpenter <dan.carpenter@oracle.com>
Cc: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>,
Ryder Lee <ryder.lee@mediatek.com>,
Shayne Chen <shayne.chen@mediatek.com>,
Sean Wang <sean.wang@mediatek.com>, Kalle Valo <kvalo@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
MeiChia Chiu <meichia.chiu@mediatek.com>,
Money Wang <Money.Wang@mediatek.com>,
linux-wireless@vger.kernel.org,
linux-mediatek@lists.infradead.org,
kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] mt76: mt7915: fix a couple information leaks
Date: Fri, 7 Jan 2022 11:08:28 +0100 [thread overview]
Message-ID: <97dbf02a-e3c7-aa4a-c404-45fc6189dc10@nbd.name> (raw)
In-Reply-To: <f61c6a25c7ad1ed452b4facf38c7e451d47c5dc0.camel@sipsolutions.net>
On 2022-01-07 10:18, Johannes Berg wrote:
> On Fri, 2022-01-07 at 10:36 +0300, Dan Carpenter wrote:
>> Unfortunately this code has stumbled into some deep C standards
>> nonsense. These two structs have a 3 byte struct hole at the end. If
>> you partially initialize a struct then the C standard specifies that
>> all the struct holes are zeroed out. But when you initialize all the
>> members of the struct, as this code does, then struct holes may be left
>> with uninitialized stack data. This is from C11 section 6.7.9 and how
>> it is implemented in GCC.
>
> Wow, nice find ...
>
>> + memset(&data, 0, sizeof(data));
>> + data.cmd = cpu_to_le32(MURU_SET_TXC_TX_STATS_EN);
>> + data.enable = enabled;
>>
>
> Maybe add a comment? This is not going to be obvious in the future.
>
>> return mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD(MURU_CTRL),
>> &data,
>> sizeof(data), false);
>
> Or maybe instead just mark the thing __packed (and/or explicitly add the
> padding if needed), it seems weird that we'd send something to the
> *firmware* that has a struct layout subject to compiler/arch padding
> rules.
I would also prefer explicitly adding the padding and leaving the rest
of the code as-is.
- Felix
WARNING: multiple messages have this Message-ID (diff)
From: Felix Fietkau <nbd@nbd.name>
To: Johannes Berg <johannes@sipsolutions.net>,
Dan Carpenter <dan.carpenter@oracle.com>
Cc: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>,
Ryder Lee <ryder.lee@mediatek.com>,
Shayne Chen <shayne.chen@mediatek.com>,
Sean Wang <sean.wang@mediatek.com>, Kalle Valo <kvalo@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
MeiChia Chiu <meichia.chiu@mediatek.com>,
Money Wang <Money.Wang@mediatek.com>,
linux-wireless@vger.kernel.org,
linux-mediatek@lists.infradead.org,
kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] mt76: mt7915: fix a couple information leaks
Date: Fri, 7 Jan 2022 11:08:28 +0100 [thread overview]
Message-ID: <97dbf02a-e3c7-aa4a-c404-45fc6189dc10@nbd.name> (raw)
In-Reply-To: <f61c6a25c7ad1ed452b4facf38c7e451d47c5dc0.camel@sipsolutions.net>
On 2022-01-07 10:18, Johannes Berg wrote:
> On Fri, 2022-01-07 at 10:36 +0300, Dan Carpenter wrote:
>> Unfortunately this code has stumbled into some deep C standards
>> nonsense. These two structs have a 3 byte struct hole at the end. If
>> you partially initialize a struct then the C standard specifies that
>> all the struct holes are zeroed out. But when you initialize all the
>> members of the struct, as this code does, then struct holes may be left
>> with uninitialized stack data. This is from C11 section 6.7.9 and how
>> it is implemented in GCC.
>
> Wow, nice find ...
>
>> + memset(&data, 0, sizeof(data));
>> + data.cmd = cpu_to_le32(MURU_SET_TXC_TX_STATS_EN);
>> + data.enable = enabled;
>>
>
> Maybe add a comment? This is not going to be obvious in the future.
>
>> return mt76_mcu_send_msg(&dev->mt76, MCU_EXT_CMD(MURU_CTRL),
>> &data,
>> sizeof(data), false);
>
> Or maybe instead just mark the thing __packed (and/or explicitly add the
> padding if needed), it seems weird that we'd send something to the
> *firmware* that has a struct layout subject to compiler/arch padding
> rules.
I would also prefer explicitly adding the padding and leaving the rest
of the code as-is.
- Felix
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
next prev parent reply other threads:[~2022-01-07 10:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-07 7:36 [PATCH] mt76: mt7915: fix a couple information leaks Dan Carpenter
2022-01-07 7:36 ` Dan Carpenter
2022-01-07 9:18 ` Johannes Berg
2022-01-07 9:18 ` Johannes Berg
2022-01-07 10:08 ` Felix Fietkau [this message]
2022-01-07 10:08 ` Felix Fietkau
2022-01-07 10:21 ` Johannes Berg
2022-01-07 10:21 ` 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=97dbf02a-e3c7-aa4a-c404-45fc6189dc10@nbd.name \
--to=nbd@nbd.name \
--cc=Money.Wang@mediatek.com \
--cc=dan.carpenter@oracle.com \
--cc=johannes@sipsolutions.net \
--cc=kernel-janitors@vger.kernel.org \
--cc=kvalo@kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=lorenzo.bianconi83@gmail.com \
--cc=matthias.bgg@gmail.com \
--cc=meichia.chiu@mediatek.com \
--cc=ryder.lee@mediatek.com \
--cc=sean.wang@mediatek.com \
--cc=shayne.chen@mediatek.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.