From: Sergey Ryazanov <ryazanov.s.a@gmail.com>
To: Simon Horman <horms@kernel.org>,
Loic Poulain <loic.poulain@linaro.org>,
Johannes Berg <johannes@sipsolutions.net>
Cc: 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>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
netdev@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH net-next] wwan: core: Pass string literal as format argument of dev_set_name()
Date: Tue, 29 Oct 2024 02:22:08 +0200 [thread overview]
Message-ID: <42f19231-dbe3-4fce-8836-75089f280296@gmail.com> (raw)
In-Reply-To: <20241023-wwan-fmt-v1-1-521b39968639@kernel.org>
Hello Simon,
On 23.10.2024 15:15, Simon Horman wrote:
> Both gcc-14 and clang-18 report that passing a non-string literal as the
> format argument of dev_set_name() is potentially insecure.
>
> E.g. clang-18 says:
>
> drivers/net/wwan/wwan_core.c:442:34: warning: format string is not a string literal (potentially insecure) [-Wformat-security]
> 442 | return dev_set_name(&port->dev, buf);
> | ^~~
> drivers/net/wwan/wwan_core.c:442:34: note: treat the string as an argument to avoid this
> 442 | return dev_set_name(&port->dev, buf);
> | ^
> | "%s",
>
> It is always the case where the contents of mod is safe to pass as the
> format argument. That is, in my understanding, it never contains any
> format escape sequences.
>
> But, 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.
> No functional change intended.
>
> Signed-off-by: Simon Horman <horms@kernel.org>
Theoretically, we can pass a string literal there and all the arguments
required to build a proper device name of multiple elements to save some
ticks on the format string processing.
But this will require a deep rework still with intermediate string
formatting. And since the performance of the name allocation is not the
case here, lets go with your solution as way more simple and clear.
Acked-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
> ---
> drivers/net/wwan/wwan_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wwan/wwan_core.c b/drivers/net/wwan/wwan_core.c
> index 17431f1b1a0c..465e2a0d57a3 100644
> --- a/drivers/net/wwan/wwan_core.c
> +++ b/drivers/net/wwan/wwan_core.c
> @@ -431,7 +431,7 @@ static int __wwan_port_dev_assign_name(struct wwan_port *port, const char *fmt)
> return -ENFILE;
> }
>
> - return dev_set_name(&port->dev, buf);
> + return dev_set_name(&port->dev, "%s", buf);
> }
>
> struct wwan_port *wwan_create_port(struct device *parent,
>
next prev parent reply other threads:[~2024-10-29 0:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-23 12:15 [PATCH net-next] wwan: core: Pass string literal as format argument of dev_set_name() Simon Horman
2024-10-29 0:22 ` Sergey Ryazanov [this message]
2024-10-29 18:50 ` patchwork-bot+netdevbpf
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=42f19231-dbe3-4fce-8836-75089f280296@gmail.com \
--to=ryazanov.s.a@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=johannes@sipsolutions.net \
--cc=justinstitt@google.com \
--cc=kuba@kernel.org \
--cc=llvm@lists.linux.dev \
--cc=loic.poulain@linaro.org \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox