From nobody Wed Nov 27 02:40:28 2024 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2BB12156C5F; Mon, 14 Oct 2024 08:52:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728895955; cv=none; b=kZRYKhnyeunKt5pFnGQLqt4p2nvy/TsuQsTyUYio15rscrptmtB2txy6IqsXDhWc4IVe7v76Ul0LebNbsegeyunS2bvSHvIRbwQ4ck5059lXVCouSUElVlVlG/6gommbj2hX023doWXhjfB7M6pvk2efEgc+XCroi3+zvmsglnM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728895955; c=relaxed/simple; bh=HQ32Tdu74SJVgjzD2QAR/pXuhPtNi59PWTlnaGaArpc=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=J+n0VBQbvaJ2j0LIcBX1Lcq7PRsMBA74WhWfLZzhYqexZ3aMo1pCslX63tqJLFA6x7WYg5Ym4NOH/I+PPPvGliJGUc/Pp1w1yBWyVg92+KRypGQSr4wT+1cOUducP7OcM7vJpiNHFN9DdAd78JXJt9XPcsAwg/Vf/ZXCnT06Kzg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Y8TsLn/k; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Y8TsLn/k" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4CEF3C4CEC3; Mon, 14 Oct 2024 08:52:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1728895954; bh=HQ32Tdu74SJVgjzD2QAR/pXuhPtNi59PWTlnaGaArpc=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=Y8TsLn/kRsVNCySZ837YrD6FTalwxIrbxCQQ1teZq+PM4TBmjZi0st7mOxrC7YBMz orOc3/F+JVlK6x3Ti3Hoqui/VRP+z75ezSy6Bkmp/Z7NnOF2gWzmXlLocqFTdJ5Sa2 CfJ3tphBiDPcXbukcShzKsYpBawCnxL9KgdCEGPVAIheik2l0LSbe6H1PHTvF5YyBj qspeIryCMj26HTD9DE7X2x4DO7rq+S9+KoC4HcE7EwjyGG4AKfLGWEOF4y0V1/9SSl xgYDBGMnBxxR731WdQggtmAsDGcBqguhzDAonxkuhidxVyAK8x/9jOE0AZiFo4Yopv wAUgAUVWBdNDQ== From: Simon Horman Date: Mon, 14 Oct 2024 09:52:25 +0100 Subject: [PATCH net-next v2 1/2] net: dsa: microchip: copy string using strscpy Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20241014-string-thing-v2-1-b9b29625060a@kernel.org> References: <20241014-string-thing-v2-0-b9b29625060a@kernel.org> In-Reply-To: <20241014-string-thing-v2-0-b9b29625060a@kernel.org> To: Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Cc: Bill Wendling , Daniel Machon , Florian Fainelli , Jiawen Wu , Justin Stitt , Mengyuan Lou , Nathan Chancellor , Nick Desaulniers , Richard Cochran , Vladimir Oltean , Woojung Huh , UNGLinuxDriver@microchip.com, netdev@vger.kernel.org, llvm@lists.linux.dev, linux-kernel@vger.kernel.org X-Mailer: b4 0.14.0 Prior to this patch ksz_ptp_msg_irq_setup() uses snprintf() to copy strings. It does so by passing strings as the format argument of snprintf(). This appears to be safe, due to the absence of format specifiers in the strings, which are declared within the same function. But nonetheless GCC 14 warns about it: .../ksz_ptp.c:1109:55: warning: format string is not a string literal (pote= ntially insecure) [-Wformat-security] 1109 | snprintf(ptpmsg_irq->name, sizeof(ptpmsg_irq->name), name[n= ]); | ^~~~~~~ .../ksz_ptp.c:1109:55: note: treat the string as an argument to avoid this 1109 | snprintf(ptpmsg_irq->name, sizeof(ptpmsg_irq->name), name[n= ]); | ^ | "%s", As what we are really dealing with here is a string copy, it seems make sense to use a function designed for this purpose. In this case null padding is not required, so strscpy is appropriate. And as the destination is an array of fixed size, the 2-argument variant may be used. Reviewed-by: Daniel Machon Signed-off-by: Simon Horman -- v2 - Add Reviewed-by from Daniel Machon - Tweaked patch description, thanks to Daniel Machon --- drivers/net/dsa/microchip/ksz_ptp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/dsa/microchip/ksz_ptp.c b/drivers/net/dsa/microchi= p/ksz_ptp.c index 050f17c43ef6..22fb9ef4645c 100644 --- a/drivers/net/dsa/microchip/ksz_ptp.c +++ b/drivers/net/dsa/microchip/ksz_ptp.c @@ -1106,7 +1106,7 @@ static int ksz_ptp_msg_irq_setup(struct ksz_port *por= t, u8 n) ptpmsg_irq->port =3D port; ptpmsg_irq->ts_reg =3D ops->get_port_addr(port->num, ts_reg[n]); =20 - snprintf(ptpmsg_irq->name, sizeof(ptpmsg_irq->name), name[n]); + strscpy(ptpmsg_irq->name, name[n]); =20 ptpmsg_irq->num =3D irq_find_mapping(port->ptpirq.domain, n); if (ptpmsg_irq->num < 0) --=20 2.45.2 From nobody Wed Nov 27 02:40:28 2024 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EE2BB156C5F; Mon, 14 Oct 2024 08:52:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728895959; cv=none; b=kEXGLhKm9Idv14295k+4tL03Ghng3BG6ugWqIuCWvHV+9IXVhEFqfUK084uyCCz4ZslEEkXsN46mWwy5fRzKMZW/D5VYsjOrxXdcazjr6QxN0J6Ua82UVE0Tcc05aBOvnnRC0tEua6ULV64qoE+cbqGItgloH2nsinHQ8EWxpmc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728895959; c=relaxed/simple; bh=3XMChqUk8p9xN3e3V3TIITrB6Da+CGbGZaKpJzpAmIY=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=uEjcbx1U8NHciBzTXhebgpn7cXX3BrpUJKElNYrJo91H03ky+2p7Aj7bAXPdSX3BYE50rtiS0NMra8vW3DLOPqfXffSnxIvtZqd9ncM551bXSDnVfSSfDVWNi10LF0vGnxySrM+4IkmdPhGgEjMxBkm8X4nfpJuDAvvpSy4o57c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CCPooX2W; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CCPooX2W" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2A12CC4CEC7; Mon, 14 Oct 2024 08:52:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1728895958; bh=3XMChqUk8p9xN3e3V3TIITrB6Da+CGbGZaKpJzpAmIY=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=CCPooX2WLLO2zlzh81zErlzEgxHtaXmUBViCaNDP3/nu7mBP5tB5W2M/HGRaFmSH1 zHHFAYGHbn2RVwWofXCao4prLUIHxUqyMh8qaFf00MsFexiYZ8VZ4nHrhR9ohsJYcI HETJr2/cRx3ObjNr1LKxNorjlCqHkDnBzpvj/8wM+6ObTUoxSYORmRDoDd4cKmkcpQ k0cF46I3K1NnbjVBjdFhZ2pwushzI0csSHd6L+NXi6vPi7K9XaZ/llGt+yK4w3x+h8 Mr+vC51lKe1BxQL48xKUAgva5FhMGJCoAmxGLV52q9YTe+0rybEjNr8L4P7iBrChoY cdp1Ckx+hMwfw== From: Simon Horman Date: Mon, 14 Oct 2024 09:52:26 +0100 Subject: [PATCH net-next v2 2/2] net: txgbe: Pass string literal as format argument of alloc_workqueue() Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20241014-string-thing-v2-2-b9b29625060a@kernel.org> References: <20241014-string-thing-v2-0-b9b29625060a@kernel.org> In-Reply-To: <20241014-string-thing-v2-0-b9b29625060a@kernel.org> To: Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Cc: Bill Wendling , Daniel Machon , Florian Fainelli , Jiawen Wu , Justin Stitt , Mengyuan Lou , Nathan Chancellor , Nick Desaulniers , Richard Cochran , Vladimir Oltean , Woojung Huh , UNGLinuxDriver@microchip.com, netdev@vger.kernel.org, llvm@lists.linux.dev, linux-kernel@vger.kernel.org X-Mailer: b4 0.14.0 Recently I noticed that both gcc-14 and clang-18 report that passing a non-string literal as the format argument of clkdev_create() is potentially insecure. E.g. clang-18 says: .../txgbe_phy.c:582:35: warning: format string is not a string literal (pot= entially insecure) [-Wformat-security] 581 | clock =3D clkdev_create(clk, NULL, clk_name); | ^~~~~~~~ .../txgbe_phy.c:582:35: note: treat the string as an argument to avoid this 581 | clock =3D clkdev_create(clk, NULL, clk_name); | ^ | "%s", It is always the case where the contents of clk_name is safe to pass as the format argument. That is, in my understanding, it never contains any format escape sequences. However, it seems better to be safe than sorry. And, as a bonus, compiler output becomes less verbose by addressing this issue as suggested by clang-18. Compile tested only. Signed-off-by: Simon Horman -- v2 - No changes --- drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c b/drivers/net/e= thernet/wangxun/txgbe/txgbe_phy.c index 3dd89dafe7c7..a0e4920b4761 100644 --- a/drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c +++ b/drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c @@ -578,7 +578,7 @@ static int txgbe_clock_register(struct txgbe *txgbe) if (IS_ERR(clk)) return PTR_ERR(clk); =20 - clock =3D clkdev_create(clk, NULL, clk_name); + clock =3D clkdev_create(clk, NULL, "%s", clk_name); if (!clock) { clk_unregister(clk); return -ENOMEM; --=20 2.45.2