All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Cc: Mario Limonciello <superm1@kernel.org>,
	Felix Fietkau <nbd@nbd.name>,
	Lorenzo Bianconi <lorenzo@kernel.org>,
	linux-wireless@vger.kernel.org,
	linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
	Johannes Berg <johannes@sipsolutions.net>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org
Subject: Re: [PATCH v2] wifi: mt76: Fix strscpy buffer overflow in mt76_connac2_load_patch
Date: Tue, 23 Dec 2025 14:54:31 -0700	[thread overview]
Message-ID: <20251223215431.GA3327658@ax162> (raw)
In-Reply-To: <20251205161202.48409-1-mikhail.v.gavrilov@gmail.com>

+ netdev and wireless/networking maintainers

On Fri, Dec 05, 2025 at 09:12:02PM +0500, Mikhail Gavrilov wrote:
> Commit f804a5895eba ("wifi: mt76: Strip whitespace from build ddate") introduced
> a kernel panic/WARN on systems using MediaTek MT7921e (and potentially others
> using mt76_connac_lib) due to an incorrect buffer size calculation.
> 
> The error logged is:
> "strnlen: detected buffer overflow: 17 byte read of buffer size 16"
> 
> This occurs because the field 'hdr->build_date' is a fixed-size array of 16 bytes.
> The patch allocated a 17-byte local buffer 'build_date' but used 'sizeof(build_date)'
> (17) as the read limit for strscpy, causing Fortify Source to correctly detect
> an attempt to read 17 bytes from the 16-byte source field.
> 
> To fix this, replace strscpy with memcpy, which is appropriate for raw data
> copying, and explicitly use the size of the source field (sizeof(hdr->build_date) = 16)
> to limit the read, followed by manual null termination.
> 
> Fixes: f804a5895eba ("wifi: mt76: Strip whitespace from build ddate")
> Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>

I got bit by this regression when installing v6.19-rc2 on my new test
machine, which has an MT7925 (RZ717) chip in it. I don't see this in
either Felix's or the main wireless tree yet but I do understand it is
the end of the year with breaks and such (along with Johannes not
actually being on CC since he is not in the output of get_maintainers.pl
for drivers/net/wireless/mediatek/mt76). If there is not going to be a
wireless pull soon, can this be applied to net directly so that it gets
to Linus soon? It was rather annoying to do a bisect for a regression
that already has a pending fix.

Tested-by: Nathan Chancellor <nathan@kernel.org>

> ---
>  drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c b/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
> index ea99167765b0..d2c4c65ec464 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
> @@ -3125,8 +3125,11 @@ int mt76_connac2_load_patch(struct mt76_dev *dev, const char *fw_name)
>  	}
>  
>  	hdr = (const void *)fw->data;
> -	strscpy(build_date, hdr->build_date, sizeof(build_date));
> -	build_date[16] = '\0';
> +	/* hdr->build_date is 16 bytes. Copy exactly 16 bytes to the 17-byte buffer,
> +	 * and then add the null terminator at index 16.
> +	 */
> +	memcpy(build_date, hdr->build_date, sizeof(hdr->build_date));
> +	build_date[sizeof(hdr->build_date)] = '\0';
>  	strim(build_date);
>  	dev_info(dev->dev, "HW/SW Version: 0x%x, Build Time: %.16s\n",
>  		 be32_to_cpu(hdr->hw_sw_ver), build_date);
> -- 
> 2.52.0
> 


  parent reply	other threads:[~2025-12-23 21:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-05 11:06 [REGRESSION] mt76: fortify panic on mt7921e during firmware load (bisected) Mikhail Gavrilov
2025-12-05 15:45 ` [PATCH] [PATCH] wifi: mt76: Fix strscpy buffer overflow in mt76_connac2_load_patch Mikhail Gavrilov
2025-12-05 16:12 ` [PATCH v2] " Mikhail Gavrilov
2025-12-05 18:14   ` Mario Limonciello
2025-12-13  2:35   ` Eric Biggers
2025-12-13  2:50     ` Mario Limonciello (AMD) (kernel.org)
2025-12-19 20:49   ` Matthew Schwartz
2025-12-23 21:54   ` Nathan Chancellor [this message]
  -- strict thread matches above, loose matches on Subject: below --
2025-12-22 10:48 Filippo Rossoni

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=20251223215431.GA3327658@ax162 \
    --to=nathan@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=johannes@sipsolutions.net \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lorenzo@kernel.org \
    --cc=mikhail.v.gavrilov@gmail.com \
    --cc=nbd@nbd.name \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=superm1@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.