Message ID | 20231013-strncpy-drivers-net-wireless-ath-ath10k-mac-c-v1-1-24e40201afa3@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp2139923vqb; Fri, 13 Oct 2023 13:34:12 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGSMRwWhfL0/VEX3eftonhHrUzoViJDIWbv/gkG+fMQfssguPrklU5vBgYTC/E++rdV6sMW X-Received: by 2002:a05:6870:164c:b0:1e9:e605:27a1 with SMTP id c12-20020a056870164c00b001e9e60527a1mr2605282oae.2.1697229251988; Fri, 13 Oct 2023 13:34:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697229251; cv=none; d=google.com; s=arc-20160816; b=y4xL9GL2j5vs5+JjpdTS+RlfMC6mtzTiPSFNvVMGezEbn17cDM0EFbUNnJOpn/g+Uk PjYQbHCUZCS3HTaev/nMwgmanVayMe8wR6+LRb6OuMojtGSN5UXUkf2WfZsdn11qy1dN Iq90JFAetaM05R73uyvMadKvWCYv4FnzwUN5Dm+5mP2v/Ub1Sq8sLcJ47uL7yfQP93QH 8w452iwb3aJeuHaY+IuYw1yUftqtAsUEjOAx8LCOJKgVs2ZttNruBNogZY16se1NpsGg /I5oa8Q+um0EHqGcR+Qbm8hPB4wX/iE+0v3RGmFZJvdmIpOynKzQm8LIVJHfJ1H3rSCQ WFWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :dkim-signature; bh=eG6A8LXGdf5DishXidGUjCut3MBs3ddn444r7C+ElXE=; fh=PioQG4/XMIEUsRALhg6vVwlM6RQLJN9AQXGiXGQHe/o=; b=FtnY8IdZOFu39exD2KzevDAXN48hX0n7k0Yt40X1AorYUYywGtD5lJ1bX516u92g5c yYPrGpO5p3U9+z4MnOOkx4ZmDWf6mHGqN6WcyZ3Cv1g7grqiRBF5pbMs6YE43WFQJw4/ djOpew/vXiWCLofjAKLnQFt7mzLePASmk2cNq/UtZ6G1Ye426r5dPgwS2zb93jRKbrSk zMDuUJGWSjm/4BJkuqTMoU91YYfYqShwpE+/EEVmpXYXR71pkRUnQEtnVGb1pE2yy2Y/ l+XIm1qzm7vtv+Th7c3WREfTfQDsKsFyOw7xB8K7v/dey8pyj1F5gqDc+7Gu6ysSnwyn Ymng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=2GLPtszD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from pete.vger.email (pete.vger.email. [2620:137:e000::3:6]) by mx.google.com with ESMTPS id e3-20020a636903000000b005895b62fe76si5148774pgc.462.2023.10.13.13.34.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Oct 2023 13:34:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=2GLPtszD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by pete.vger.email (Postfix) with ESMTP id A0A6C83BD982; Fri, 13 Oct 2023 13:34:09 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232076AbjJMUdv (ORCPT <rfc822;rua109.linux@gmail.com> + 19 others); Fri, 13 Oct 2023 16:33:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38608 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231468AbjJMUdu (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 13 Oct 2023 16:33:50 -0400 Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6856D83 for <linux-kernel@vger.kernel.org>; Fri, 13 Oct 2023 13:33:49 -0700 (PDT) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-5a7ac9c1522so39508927b3.0 for <linux-kernel@vger.kernel.org>; Fri, 13 Oct 2023 13:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1697229228; x=1697834028; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=eG6A8LXGdf5DishXidGUjCut3MBs3ddn444r7C+ElXE=; b=2GLPtszDPum7mvEFFd7ZG16lA3MmeTdMHTlFft9GmpFMwSsT9ZZKIfhGdlCfmHi2FX ZjuZMfsxXLbPvhhi9NdsObNaE1pZl3cT2P3AACBXiPkjpHetoMx+yFIlOBfPq0rHmE6m Q0bEOF9BoBUd4FAmDDRMlCIMmHn93EOhLLtbGVCIlJbTXnOpPFNOX+wWDSXZD2xMsZbt gsa7AgLr/5atERjPTKUu+h1H4OB6LMzbK19DxVYEST6XziN3W2B36hLiSY/N83IIXsYp eS6l0gdaGQtgaooXyrDGtquM0gA2prIzokC3X/Xu7upj5Q96JW1+ZiHNPIs8Hol87akv 4exw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697229228; x=1697834028; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=eG6A8LXGdf5DishXidGUjCut3MBs3ddn444r7C+ElXE=; b=Ibto03Sl/BX45rviClaaxcynW/dgiApZxv62kf+hS849UyWRaHcQh/T/qZnvZis65+ DNXh1JpMWbqd2yJNlMDRHzpihsSeBO3m34Sh25WYTn/d0gn09VLGEPWgWVzpkZoW95rr WlSmi6V+ow3ztRbg55njSavORrcLPlmy2c5p+HDKFLgFKDcGLQ06X7gBDEO8/1Whz0+9 Vx67uUhf/0vSpBlgyLNG/qqD7WIwPQIU6124fyMmfInuJJG+1NO4WFABnT7GxQAWpiPx WSJtQYfeO1JMIl9ZTyV/HN4CJ2ktfvXMO0o4ybL8BPDYAJDuZ5Cl0kzLqlRjFMTz2OTN fRxg== X-Gm-Message-State: AOJu0Yw3zDCjRpqs28tCpMAoLs/a4+f6kcpAtyRByxXo0QTEeDKJu16Q D001kYWlfH4dq7/Cnz8M8mPha7uVU8/mGtiMAw== X-Received: from jstitt-linux1.c.googlers.com ([fda3:e722:ac3:cc00:2b:ff92:c0a8:23b5]) (user=justinstitt job=sendgmr) by 2002:a25:5056:0:b0:d9a:3dac:6c1a with SMTP id e83-20020a255056000000b00d9a3dac6c1amr284177ybb.11.1697229228652; Fri, 13 Oct 2023 13:33:48 -0700 (PDT) Date: Fri, 13 Oct 2023 20:33:48 +0000 Mime-Version: 1.0 X-B4-Tracking: v=1; b=H4sIAKupKWUC/x2NQQrCMBBFr1Jm7UDS0AheRVyE9GsHNZaZ0Cqld zfK4y/e5r+NDCowOnUbKRYxeZUm/tBRnlK5gWVsTr3rg3c+sFUtef7wqLJAjQsqr6J4wIxTnX7 z7s7PlLlxDGkYYoyIidrnrLjK+987X/b9C0V4zo5/AAAA X-Developer-Key: i=justinstitt@google.com; a=ed25519; pk=tC3hNkJQTpNX/gLKxTNQKDmiQl6QjBNCGKJINqAdJsE= X-Developer-Signature: v=1; a=ed25519-sha256; t=1697229227; l=2804; i=justinstitt@google.com; s=20230717; h=from:subject:message-id; bh=bIMAUwS6tKmB9c3Rk81R/5V5UUFo1cBwPXaV7yFWMoA=; b=CMqSCYBAwjGQ8NqCJLEe3oWu/b2U+C4UYTWSlc/PUeeYHnfx5MQOccK4vtSKlHLLgk37gUzWa wuqPSkQzuGcBq8W/yBQzKG3d3WsDrMe0sr4hx8u6ZKodNLkDgwsgk/2 X-Mailer: b4 0.12.3 Message-ID: <20231013-strncpy-drivers-net-wireless-ath-ath10k-mac-c-v1-1-24e40201afa3@google.com> Subject: [PATCH] ath10k: replace deprecated strncpy with strtomem_pad From: Justin Stitt <justinstitt@google.com> To: Kalle Valo <kvalo@kernel.org>, Jeff Johnson <quic_jjohnson@quicinc.com> Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, Justin Stitt <justinstitt@google.com> Content-Type: text/plain; charset="utf-8" X-Spam-Status: No, score=-8.4 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Fri, 13 Oct 2023 13:34:09 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779673859846139152 X-GMAIL-MSGID: 1779673859846139152 |
Series |
ath10k: replace deprecated strncpy with strtomem_pad
|
|
Commit Message
Justin Stitt
Oct. 13, 2023, 8:33 p.m. UTC
strncpy() is deprecated [1] and we should prefer less ambiguous
interfaces.
In this case, arvif->u.ap.ssid has its length maintained by
arvif->u.ap.ssid_len which indicates it may not need to be
NUL-terminated, although by virtue of using strtomem_pad (with NUL-byte
pad character) and having a destination size larger than the source,
ssid will, incidentally, be NUL-terminated here.
As strtomem_pad() docs say:
* @dest: Pointer of destination character array (marked as __nonstring)
* @src: Pointer to NUL-terminated string
* @pad: Padding character to fill any remaining bytes of @dest after copy
*
* This is a replacement for strncpy() uses where the destination is not
* a NUL-terminated string, but with bounds checking on the source size, and
* an explicit padding character. If padding is not required, use strtomem().
Let's also mark ath10k_vif.u.ap.ssid as __nonstring.
It is unclear to me whether padding is strictly necessary. Perhaps we
should opt for just strtomem() -- padding certainly doesn't hurt,
though.
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt <justinstitt@google.com>
---
Note: build-tested only.
Found with: $ rg "strncpy\("
---
drivers/net/wireless/ath/ath10k/core.h | 2 +-
drivers/net/wireless/ath/ath10k/mac.c | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
---
base-commit: cbf3a2cb156a2c911d8f38d8247814b4c07f49a2
change-id: 20231013-strncpy-drivers-net-wireless-ath-ath10k-mac-c-c73a55666e6a
Best regards,
--
Justin Stitt <justinstitt@google.com>
Comments
On 10/13/2023 1:33 PM, Justin Stitt wrote: > strncpy() is deprecated [1] and we should prefer less ambiguous > interfaces. > > In this case, arvif->u.ap.ssid has its length maintained by > arvif->u.ap.ssid_len which indicates it may not need to be > NUL-terminated, although by virtue of using strtomem_pad (with NUL-byte > pad character) and having a destination size larger than the source, > ssid will, incidentally, be NUL-terminated here. > > As strtomem_pad() docs say: > * @dest: Pointer of destination character array (marked as __nonstring) > * @src: Pointer to NUL-terminated string > * @pad: Padding character to fill any remaining bytes of @dest after copy > * > * This is a replacement for strncpy() uses where the destination is not > * a NUL-terminated string, but with bounds checking on the source size, and > * an explicit padding character. If padding is not required, use strtomem(). > > Let's also mark ath10k_vif.u.ap.ssid as __nonstring. what criteria is used to determine whether or not to use __nonstring? doesn't the use of u8 vs char already communicate that distinction? just want to know what other u8 arrays might require this. FWIW the documentation referenced by the __nonstring macro explicitly refers to "type array of char, signed char, or unsigned char" > > It is unclear to me whether padding is strictly necessary. Perhaps we > should opt for just strtomem() -- padding certainly doesn't hurt, > though. concur that padding probably isn't necessary but doesn't hurt, and will prevent confusion if looking at this member in a crashdump > > Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] > Link: https://github.com/KSPP/linux/issues/90 > Cc: linux-hardening@vger.kernel.org > Signed-off-by: Justin Stitt <justinstitt@google.com> Either with or without the __nonstring... Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
On Fri, Oct 13, 2023 at 05:58:03PM -0700, Jeff Johnson wrote: > On 10/13/2023 1:33 PM, Justin Stitt wrote: > > strncpy() is deprecated [1] and we should prefer less ambiguous > > interfaces. > > > > In this case, arvif->u.ap.ssid has its length maintained by > > arvif->u.ap.ssid_len which indicates it may not need to be > > NUL-terminated, although by virtue of using strtomem_pad (with NUL-byte > > pad character) and having a destination size larger than the source, > > ssid will, incidentally, be NUL-terminated here. > > > > As strtomem_pad() docs say: > > * @dest: Pointer of destination character array (marked as __nonstring) > > * @src: Pointer to NUL-terminated string > > * @pad: Padding character to fill any remaining bytes of @dest after copy > > * > > * This is a replacement for strncpy() uses where the destination is not > > * a NUL-terminated string, but with bounds checking on the source size, and > > * an explicit padding character. If padding is not required, use strtomem(). > > > > Let's also mark ath10k_vif.u.ap.ssid as __nonstring. > > what criteria is used to determine whether or not to use __nonstring? > doesn't the use of u8 vs char already communicate that distinction? > just want to know what other u8 arrays might require this. > FWIW the documentation referenced by the __nonstring macro explicitly refers > to "type array of char, signed char, or unsigned char" The use of __nonstring is for byte arrays that are _not_ expected to be %NUL terminated. Unfortunately "char" vs "u8" isn't distinguished by the compiler. All byte arrays are treated as C strings unless __nonstring is used. > > It is unclear to me whether padding is strictly necessary. Perhaps we > > should opt for just strtomem() -- padding certainly doesn't hurt, > > though. > > concur that padding probably isn't necessary but doesn't hurt, and will > prevent confusion if looking at this member in a crashdump > > > > > Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] > > Link: https://github.com/KSPP/linux/issues/90 > > Cc: linux-hardening@vger.kernel.org > > Signed-off-by: Justin Stitt <justinstitt@google.com> > > Either with or without the __nonstring... > Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Yup, it looks like the ssid member is passed around with memcpy() everywhere else. Reviewed-by: Kees Cook <keescook@chromium.org>
On 10/18/2023 4:35 PM, Kees Cook wrote: > On Fri, Oct 13, 2023 at 05:58:03PM -0700, Jeff Johnson wrote: >>> Let's also mark ath10k_vif.u.ap.ssid as __nonstring. >> >> what criteria is used to determine whether or not to use __nonstring? >> doesn't the use of u8 vs char already communicate that distinction? >> just want to know what other u8 arrays might require this. >> FWIW the documentation referenced by the __nonstring macro explicitly refers >> to "type array of char, signed char, or unsigned char" > > The use of __nonstring is for byte arrays that are _not_ expected to be > %NUL terminated. Unfortunately "char" vs "u8" isn't distinguished by the > compiler. All byte arrays are treated as C strings unless __nonstring is > used. So is the plan to annotate every single binary blob array in the kernel as __nonstring? I suspect those outnumber string arrays.
Justin Stitt <justinstitt@google.com> writes: > strncpy() is deprecated [1] and we should prefer less ambiguous > interfaces. > > In this case, arvif->u.ap.ssid has its length maintained by > arvif->u.ap.ssid_len which indicates it may not need to be > NUL-terminated, although by virtue of using strtomem_pad (with NUL-byte > pad character) and having a destination size larger than the source, > ssid will, incidentally, be NUL-terminated here. > > As strtomem_pad() docs say: > * @dest: Pointer of destination character array (marked as __nonstring) > * @src: Pointer to NUL-terminated string > * @pad: Padding character to fill any remaining bytes of @dest after copy > * > * This is a replacement for strncpy() uses where the destination is not > * a NUL-terminated string, but with bounds checking on the source size, and > * an explicit padding character. If padding is not required, use strtomem(). > > Let's also mark ath10k_vif.u.ap.ssid as __nonstring. > > It is unclear to me whether padding is strictly necessary. Perhaps we > should opt for just strtomem() -- padding certainly doesn't hurt, > though. > > Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] > Link: https://github.com/KSPP/linux/issues/90 > Cc: linux-hardening@vger.kernel.org > Signed-off-by: Justin Stitt <justinstitt@google.com> > --- > Note: build-tested only. > > Found with: $ rg "strncpy\(" > --- > drivers/net/wireless/ath/ath10k/core.h | 2 +- > drivers/net/wireless/ath/ath10k/mac.c | 3 +-- > 2 files changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h > index 4b5239de4018..ba9795a8378a 100644 > --- a/drivers/net/wireless/ath/ath10k/core.h > +++ b/drivers/net/wireless/ath/ath10k/core.h > @@ -607,7 +607,7 @@ struct ath10k_vif { > u8 tim_bitmap[64]; > u8 tim_len; > u32 ssid_len; > - u8 ssid[IEEE80211_MAX_SSID_LEN]; > + u8 ssid[IEEE80211_MAX_SSID_LEN] __nonstring; > bool hidden_ssid; > /* P2P_IE with NoA attribute for P2P_GO case */ > u32 noa_len; > diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c > index 03e7bc5b6c0b..7daa007bd8b3 100644 > --- a/drivers/net/wireless/ath/ath10k/mac.c > +++ b/drivers/net/wireless/ath/ath10k/mac.c > @@ -6125,8 +6125,7 @@ static void ath10k_bss_info_changed(struct ieee80211_hw *hw, > > if (ieee80211_vif_is_mesh(vif)) { > /* mesh doesn't use SSID but firmware needs it */ > - strncpy(arvif->u.ap.ssid, "mesh", > - sizeof(arvif->u.ap.ssid)); > + strtomem_pad(arvif->u.ap.ssid, "mesh", '\0'); > arvif->u.ap.ssid_len = 4; > } > } Using NUL-termination with SSID makes me always cringe as back in the day we had so many bad implementations which didn't use SSID with specific length parameter. The firmware should only check for ssid_len (though I didn't check) so I find confusing that here we are suddenly NUL-terminating it. What about using just memcpy() to make it clear it's not really a proper string: arvif->u.ap.ssid_len = 4; memcpy(arvif->u.ap.ssid, "mesh", arvif->u.ap.ssid_len);
On 10/24/2023 6:03 AM, Kalle Valo wrote: > What about using just memcpy() to make it clear it's not really a proper > string: > > arvif->u.ap.ssid_len = 4; > memcpy(arvif->u.ap.ssid, "mesh", arvif->u.ap.ssid_len); > In the "changed & BSS_CHANGED_SSID" case that comes soon after this we just set the length and use memcpy without clearing the rest of the buffer, so doing the same here, as you suggest, would be consistent. /jeff
On Tue, Oct 24, 2023 at 07:11:51AM -0700, Jeff Johnson wrote: > On 10/24/2023 6:03 AM, Kalle Valo wrote: > > What about using just memcpy() to make it clear it's not really a proper > > string: > > > > arvif->u.ap.ssid_len = 4; > > memcpy(arvif->u.ap.ssid, "mesh", arvif->u.ap.ssid_len); > > > > In the "changed & BSS_CHANGED_SSID" case that comes soon after this we just > set the length and use memcpy without clearing the rest of the buffer, so > doing the same here, as you suggest, would be consistent. Ah, please ignore my other email asking about memcpy safety -- I'm reading threads backwards. :)
On 10/24/2023 2:43 PM, Kees Cook wrote: > On Tue, Oct 24, 2023 at 07:11:51AM -0700, Jeff Johnson wrote: >> On 10/24/2023 6:03 AM, Kalle Valo wrote: >>> What about using just memcpy() to make it clear it's not really a proper >>> string: >>> >>> arvif->u.ap.ssid_len = 4; >>> memcpy(arvif->u.ap.ssid, "mesh", arvif->u.ap.ssid_len); >>> >> >> In the "changed & BSS_CHANGED_SSID" case that comes soon after this we just >> set the length and use memcpy without clearing the rest of the buffer, so >> doing the same here, as you suggest, would be consistent. > > Ah, please ignore my other email asking about memcpy safety -- I'm > reading threads backwards. :) > And I'm replying without first reading through my mail queue
On Tue, Oct 24, 2023 at 04:25:35PM -0700, Jeff Johnson wrote: > On 10/24/2023 2:43 PM, Kees Cook wrote: > > On Tue, Oct 24, 2023 at 07:11:51AM -0700, Jeff Johnson wrote: > > > On 10/24/2023 6:03 AM, Kalle Valo wrote: > > > > What about using just memcpy() to make it clear it's not really a proper > > > > string: > > > > > > > > arvif->u.ap.ssid_len = 4; > > > > memcpy(arvif->u.ap.ssid, "mesh", arvif->u.ap.ssid_len); > > > > > > > > > > In the "changed & BSS_CHANGED_SSID" case that comes soon after this we just > > > set the length and use memcpy without clearing the rest of the buffer, so > > > doing the same here, as you suggest, would be consistent. > > > > Ah, please ignore my other email asking about memcpy safety -- I'm > > reading threads backwards. :) > > > And I'm replying without first reading through my mail queue *high five* :)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h index 4b5239de4018..ba9795a8378a 100644 --- a/drivers/net/wireless/ath/ath10k/core.h +++ b/drivers/net/wireless/ath/ath10k/core.h @@ -607,7 +607,7 @@ struct ath10k_vif { u8 tim_bitmap[64]; u8 tim_len; u32 ssid_len; - u8 ssid[IEEE80211_MAX_SSID_LEN]; + u8 ssid[IEEE80211_MAX_SSID_LEN] __nonstring; bool hidden_ssid; /* P2P_IE with NoA attribute for P2P_GO case */ u32 noa_len; diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 03e7bc5b6c0b..7daa007bd8b3 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -6125,8 +6125,7 @@ static void ath10k_bss_info_changed(struct ieee80211_hw *hw, if (ieee80211_vif_is_mesh(vif)) { /* mesh doesn't use SSID but firmware needs it */ - strncpy(arvif->u.ap.ssid, "mesh", - sizeof(arvif->u.ap.ssid)); + strtomem_pad(arvif->u.ap.ssid, "mesh", '\0'); arvif->u.ap.ssid_len = 4; } }