linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Kars Mulder" <kerneldev@karsmulder.nl>
To: "David Laight" <David.Laight@ACULAB.COM>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Pavel Machek" <pavel@ucw.cz>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Kai-Heng Feng" <kai.heng.feng@canonical.com>
Subject: RE: Writing to a const pointer: is this  supposed to happen?
Date: Thu, 02 Jul 2020 23:48:02 +0200	[thread overview]
Message-ID: <297d-5efe5600-1cf-7eab9a80@67481175> (raw)
In-Reply-To: <32182d4126fd49dabac4091b7a6c89e7@AcuMS.aculab.com>

On Thursday, July 02, 2020 09:55 CEST, David Laight wrote: 
> Hmm... sscanf() is also horrid.
> Surprisingly difficult to use correctly.
> 
> It is usually best to use strchr() (and maybe str[c]scn())
> to parse strings.
> For numbers use whatever the kernels current 'favourite' implementation
> of strtoul() is called.

I thought that using sscanf would clean up the code a bit compared to
several haphazard calls, but I can see your point about sscanf being
difficult to use correctly.

The kernel functions kstrtou16 seem to expect a null-terminated string
as argument. Since there are no null-bytes after the numbers we want to
parse, it becomes necessary to copy at least part of the strings to a
buffer.

If we're copying strings to buffers anyway, I think the simplest
solution would be to just kstrdup the entire parameter and not touch
the rest of the string parsing code. This has the disadvantage of
having an extra memory allocation to keep track of.

Since the parameter is currently restricted to 128 characters at
most, it may alternatively be possible to copy the parameter to
a 128-byte buffer on the stack. This has the advantage of having
to keep track of one less memory allocation, but the disadvantage
of using 128 bytes more stack space; I'm not sure whether that's
acceptable.

Here's a sample patch involving kstrdup:

---
 drivers/usb/core/quirks.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index e0b77674869c..3b64b0be2563 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -25,17 +25,23 @@ static unsigned int quirk_count;
 
 static char quirks_param[128];
 
-static int quirks_param_set(const char *val, const struct kernel_param *kp)
+static int quirks_param_set(const char *value, const struct kernel_param *kp)
 {
-	char *p, *field;
+	char *val, *p, *field;
 	u16 vid, pid;
 	u32 flags;
 	size_t i;
 	int err;
 
+	val = kstrdup(value, GFP_KERNEL);
+	if (!val)
+		return -ENOMEM;
+
 	err = param_set_copystring(val, kp);
-	if (err)
+	if (err) {
+		kfree(val);
 		return err;
+	}
 
 	mutex_lock(&quirk_mutex);
 
@@ -60,6 +66,7 @@ static int quirks_param_set(const char *val, const struct kernel_param *kp)
 	if (!quirk_list) {
 		quirk_count = 0;
 		mutex_unlock(&quirk_mutex);
+		kfree(val);
 		return -ENOMEM;
 	}
 
@@ -144,6 +151,7 @@ static int quirks_param_set(const char *val, const struct kernel_param *kp)
 
 unlock:
 	mutex_unlock(&quirk_mutex);
+	kfree(val);
 
 	return 0;
 }
--
2.27.0


  reply	other threads:[~2020-07-02 21:48 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-22 11:35 Writing to a const pointer: is this supposed to happen? Kars Mulder
2020-06-23 19:55 ` Pavel Machek
2020-06-24 12:34   ` Kars Mulder
2020-06-24 13:10     ` Greg Kroah-Hartman
2020-06-24 15:25       ` Kars Mulder
2020-06-27 10:24         ` David Laight
2020-07-01 23:03           ` Kars Mulder
2020-07-02  7:55             ` David Laight
2020-07-02 21:48               ` Kars Mulder [this message]
2020-07-03  8:13                 ` David Laight
2020-07-03 13:23                   ` Kars Mulder
2020-07-04 11:55                     ` Pavel Machek
2020-07-05 21:53                       ` [PATCH] usb: core: fix quirks_param_set() writing to a const pointer Kars Mulder
2020-07-06 10:34                         ` Greg Kroah-Hartman
2020-07-06 12:57                           ` Kars Mulder
2020-07-06 13:07                             ` Greg Kroah-Hartman
2020-07-06 13:58                               ` Kars Mulder
     [not found] <CAHp75Ve4O+OmVttjhtKepFWwZLU6tFMx5vNpPVJdB58mcLFm3w@mail.gmail.com>
2020-07-04 20:32 ` Writing to a const pointer: is this supposed to happen? Kars Mulder
2020-07-04 20:54   ` Andy Shevchenko
2020-07-05 18:27     ` Kars Mulder
     [not found] <CAHp75Vf9ygQ++DL4ETMy54d=x6oS1qqHLhfyh58f7JCVvM17yA@mail.gmail.com>
2020-07-05 19:38 ` Kars Mulder
     [not found] <CAHp75Ve3m=UK9r2o8bDotQWQBLz-fV8CO_VcTmWjdLW1p5wE-w@mail.gmail.com>
2020-07-05 20:48 ` Kars Mulder

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=297d-5efe5600-1cf-7eab9a80@67481175 \
    --to=kerneldev@karsmulder.nl \
    --cc=David.Laight@ACULAB.COM \
    --cc=gregkh@linuxfoundation.org \
    --cc=kai.heng.feng@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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 NNTP newsgroup(s).