From: Calvince Otieno <calvncce@gmail.com>
To: gustavo@embeddedor.com, outreachy@lists.linux.dev
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org,
Calvince Otieno <calvncce@gmail.com>,
Dan Carpenter <dan.carpenter@linaro.org>,
Martyn Welch <martyn@welchs.me.uk>,
Manohar Vanga <manohar.vanga@gmail.com>
Subject: [PATCH v3] staging: vme_user: replace strcpy with strscpy
Date: Thu, 19 Oct 2023 08:47:24 +0300 [thread overview]
Message-ID: <ZTDC7N6GLXZqaevN@lab-ubuntu> (raw)
Checkpatch suggests using strscpy() instead of strcpy().
The advantages of strscpy() are that it always adds a NUL terminator
and prevents read/write overflows if the source string is not properly
terminated.
strcpy() lacks built-in bounds checking for the destination buffer,
making it susceptible to buffer overflows. These overflows can lead
to various unpredictable behaviors.
In this specific context, both strscpy and strcpy performs the same
operation without any functional difference.
The reason for this equivalence is that the driver_name string "vme_fake"
is shorter than the size of the fake_bridge->name array which is defined
as 16 characters (struct vme_bridge {char name[VMENAMSIZ];...}). Thus,
there is no risk of buffer overflow in either case. VMENAMSIZ variable
holds a constant value of 16 (#define VMENAMSIZ 16)
The null-terminated "vme_fake" string
(static const char driver_name[] = "vme_fake";) can be safely copied into
fake_bridge->name using either strscpy or strcpy.
While using strscpy() does not address any bugs, it is considered a better
practice and aligns with checkpatch recommendations.
Signed-off-by: Calvince Otieno <calvncce@gmail.com>
---
Changes in v3:
- Rewrote the commit message
---
Changes in v2:
- Make the commit message more clearer.
- Remove the incident extra line change.
drivers/staging/vme_user/vme_fake.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vme_user/vme_fake.c b/drivers/staging/vme_user/vme_fake.c
index 0e02c194298d..8ab5b43c70a6 100644
--- a/drivers/staging/vme_user/vme_fake.c
+++ b/drivers/staging/vme_user/vme_fake.c
@@ -1091,7 +1091,7 @@ static int __init fake_init(void)
tasklet_init(&fake_device->int_tasklet, fake_VIRQ_tasklet,
(unsigned long)fake_bridge);
- strcpy(fake_bridge->name, driver_name);
+ strscpy(fake_bridge->name, driver_name, sizeof(fake_bridge->name))
/* Add master windows to list */
INIT_LIST_HEAD(&fake_bridge->master_resources);
--
2.34.1
next reply other threads:[~2023-10-19 5:47 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-19 5:47 Calvince Otieno [this message]
2023-10-19 5:50 ` [PATCH v3] staging: vme_user: replace strcpy with strscpy Dan Carpenter
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=ZTDC7N6GLXZqaevN@lab-ubuntu \
--to=calvncce@gmail.com \
--cc=dan.carpenter@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=gustavo@embeddedor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=manohar.vanga@gmail.com \
--cc=martyn@welchs.me.uk \
--cc=outreachy@lists.linux.dev \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).