From: Yuran Pereira <yuran.pereira@hotmail.com>
The simple_str* family of functions perform no error checking in
scenarios where the input value overflows the intended output variable.
This results in these functions successfully returning even when the
output does not match the input string.
Or as it was mentioned [1], "...simple_strtol(), simple_strtoll(),
simple_strtoul(), and simple_strtoull() functions explicitly ignore
overflows, which may lead to unexpected results in callers."
Hence, the use of those functions is discouraged.
This patch replaces all uses of the simple_strto* series of functions
with their safer kstrto* alternatives.
Side effects of this patch:
- Every string to long or long long conversion using kstrto* is now
checked for failure.
- kstrto* errors are handled with appropriate `KDB_BADINT` wherever
applicable.
- A good side effect is that we end up saving a few lines of code
since unlike in simple_strto* functions, kstrto functions do not
need an additional "end pointer" variable, and the return values
of the latter can be directly checked in an "if" statement without
the need to define additional `ret` or `err` variables.
This, of course, results in cleaner, yet still easy to understand
code.
[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#simple-strtol-simple-strtoll-simple-strtoul-simple-strtoull
Link: https://lore.kernel.org/20241028191916.GA918454@lichtman.org
Signed-off-by: Yuran Pereira <yuran.pereira@hotmail.com>
[nir: addressed review comments by fixing styling, invalid conversion and a missing error return]
Signed-off-by: Nir Lichtman <nir@lichtman.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
---
kernel/debug/kdb/kdb_main.c | 69 +++++++++++--------------------------
1 file changed, 21 insertions(+), 48 deletions(-)
diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
index f5f7d7fb5936..f8703ab760d9 100644
--- a/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -306,8 +306,8 @@ static int kdbgetulenv(const char *match, unsigned long *value)
return KDB_NOTENV;
if (strlen(ep) == 0)
return KDB_NOENVVALUE;
-
- *value = simple_strtoul(ep, NULL, 0);
+ if (kstrtoul(ep, 0, value))
+ return KDB_BADINT;
return 0;
}
@@ -402,42 +402,23 @@ static void kdb_printenv(void)
*/
int kdbgetularg(const char *arg, unsigned long *value)
{
- char *endp;
- unsigned long val;
-
- val = simple_strtoul(arg, &endp, 0);
-
- if (endp == arg) {
- /*
- * Also try base 16, for us folks too lazy to type the
- * leading 0x...
- */
- val = simple_strtoul(arg, &endp, 16);
- if (endp == arg)
+ /*
+ * If the first fails, also try base 16, for us
+ * folks too lazy to type the leading 0x...
+ */
+ if (kstrtoul(arg, 0, value)) {
+ if (kstrtoul(arg, 16, value))
return KDB_BADINT;
}
-
- *value = val;
-
return 0;
}
int kdbgetu64arg(const char *arg, u64 *value)
{
- char *endp;
- u64 val;
-
- val = simple_strtoull(arg, &endp, 0);
-
- if (endp == arg) {
-
- val = simple_strtoull(arg, &endp, 16);
- if (endp == arg)
+ if (kstrtou64(arg, 0, value)) {
+ if (kstrtou64(arg, 16, value))
return KDB_BADINT;
}
-
- *value = val;
-
return 0;
}
@@ -473,10 +454,10 @@ int kdb_set(int argc, const char **argv)
*/
if (strcmp(argv[1], "KDBDEBUG") == 0) {
unsigned int debugflags;
- char *cp;
+ int ret;
- debugflags = simple_strtoul(argv[2], &cp, 0);
- if (cp == argv[2] || debugflags & ~KDB_DEBUG_FLAG_MASK) {
+ ret = kstrtouint(argv[2], 0, &debugflags);
+ if (ret || debugflags & ~KDB_DEBUG_FLAG_MASK) {
kdb_printf("kdb: illegal debug flags '%s'\n",
argv[2]);
return 0;
@@ -1619,10 +1600,10 @@ static int kdb_md(int argc, const char **argv)
if (!argv[0][3])
valid = 1;
else if (argv[0][3] == 'c' && argv[0][4]) {
- char *p;
- repeat = simple_strtoul(argv[0] + 4, &p, 10);
+ if (kstrtouint(argv[0] + 4, 10, &repeat))
+ return KDB_BADINT;
mdcount = ((repeat * bytesperword) + 15) / 16;
- valid = !*p;
+ valid = 1;
}
last_repeat = repeat;
} else if (strcmp(argv[0], "md") == 0)
@@ -2083,15 +2064,10 @@ static int kdb_dmesg(int argc, const char **argv)
if (argc > 2)
return KDB_ARGCOUNT;
if (argc) {
- char *cp;
- lines = simple_strtol(argv[1], &cp, 0);
- if (*cp)
+ if (kstrtoint(argv[1], 0, &lines))
lines = 0;
- if (argc > 1) {
- adjust = simple_strtoul(argv[2], &cp, 0);
- if (*cp || adjust < 0)
- adjust = 0;
- }
+ if (argc > 1 && (kstrtoint(argv[2], 0, &adjust) || adjust < 0))
+ adjust = 0;
}
/* disable LOGGING if set */
@@ -2428,14 +2404,12 @@ static int kdb_help(int argc, const char **argv)
static int kdb_kill(int argc, const char **argv)
{
long sig, pid;
- char *endp;
struct task_struct *p;
if (argc != 2)
return KDB_ARGCOUNT;
- sig = simple_strtol(argv[1], &endp, 0);
- if (*endp)
+ if (kstrtol(argv[1], 0, &sig))
return KDB_BADINT;
if ((sig >= 0) || !valid_signal(-sig)) {
kdb_printf("Invalid signal parameter.<-signal>\n");
@@ -2443,8 +2417,7 @@ static int kdb_kill(int argc, const char **argv)
}
sig = -sig;
- pid = simple_strtol(argv[2], &endp, 0);
- if (*endp)
+ if (kstrtol(argv[2], 0, &pid))
return KDB_BADINT;
if (pid <= 0) {
kdb_printf("Process ID must be large than 0.\n");
--
2.45.2Hi, On Fri, Nov 1, 2024 at 3:36 AM Steven Rostedt <rostedt@goodmis.org> wrote: > > From: Yuran Pereira <yuran.pereira@hotmail.com> > > The simple_str* family of functions perform no error checking in > scenarios where the input value overflows the intended output variable. > This results in these functions successfully returning even when the > output does not match the input string. > > Or as it was mentioned [1], "...simple_strtol(), simple_strtoll(), > simple_strtoul(), and simple_strtoull() functions explicitly ignore > overflows, which may lead to unexpected results in callers." > Hence, the use of those functions is discouraged. > > This patch replaces all uses of the simple_strto* series of functions > with their safer kstrto* alternatives. > > Side effects of this patch: > - Every string to long or long long conversion using kstrto* is now > checked for failure. > - kstrto* errors are handled with appropriate `KDB_BADINT` wherever > applicable. > - A good side effect is that we end up saving a few lines of code > since unlike in simple_strto* functions, kstrto functions do not > need an additional "end pointer" variable, and the return values > of the latter can be directly checked in an "if" statement without > the need to define additional `ret` or `err` variables. > This, of course, results in cleaner, yet still easy to understand > code. > > [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#simple-strtol-simple-strtoll-simple-strtoul-simple-strtoull > > Link: https://lore.kernel.org/20241028191916.GA918454@lichtman.org > Signed-off-by: Yuran Pereira <yuran.pereira@hotmail.com> > [nir: addressed review comments by fixing styling, invalid conversion and a missing error return] > Signed-off-by: Nir Lichtman <nir@lichtman.org> > Reviewed-by: Douglas Anderson <dianders@chromium.org> > Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> > --- > kernel/debug/kdb/kdb_main.c | 69 +++++++++++-------------------------- > 1 file changed, 21 insertions(+), 48 deletions(-) FWIW, I personally have no objection to this patch and patch #3/3 in Nir's series (#5/11 in your email thread) going through the ftrace tree, I'm not actually the maintainer of kdb/kgdb. I'm a reviewer and I try my best to help, but officially you should probably have Daniel Thompson's Ack for them. ...or at least make sure he's CCed here saying that you've picked them up. I've added him to the conversation here. -Doug
On Fri, 1 Nov 2024 07:21:05 -0700 Doug Anderson <dianders@chromium.org> wrote: > FWIW, I personally have no objection to this patch and patch #3/3 in > Nir's series (#5/11 in your email thread) going through the ftrace > tree, I'm not actually the maintainer of kdb/kgdb. I'm a reviewer and > I try my best to help, but officially you should probably have Daniel > Thompson's Ack for them. ...or at least make sure he's CCed here > saying that you've picked them up. > > I've added him to the conversation here. Sure, I can even drop this patch if need be. Thanks for adding Daniel to the Cc. I probably should have run these patches through get maintainers to make sure everyone was accounted for. -- Steve
On Fri, Nov 01, 2024 at 10:31:28AM -0400, Steven Rostedt wrote: > On Fri, 1 Nov 2024 07:21:05 -0700 > Doug Anderson <dianders@chromium.org> wrote: > > > FWIW, I personally have no objection to this patch and patch #3/3 in > > Nir's series (#5/11 in your email thread) going through the ftrace > > tree, I'm not actually the maintainer of kdb/kgdb. I'm a reviewer and > > I try my best to help, but officially you should probably have Daniel > > Thompson's Ack for them. ...or at least make sure he's CCed here > > saying that you've picked them up. > > > > I've added him to the conversation here. > > Sure, I can even drop this patch if need be. Thanks for adding Daniel to > the Cc. I probably should have run these patches through get maintainers to > make sure everyone was accounted for. I haven't had a chance to review or hoover up the kdb/kgdb patches for this cycle yet (mixture of travel and other things) but they are queued up in my TODO list for next week. I presume the tracing tree is involved because one of them changes the kdb ftrace command? Are there dependencies between that and other patches in the seriesm? Daniel.
On Fri, Nov 01, 2024 at 06:22:04PM +0000, Daniel Thompson wrote: > On Fri, Nov 01, 2024 at 10:31:28AM -0400, Steven Rostedt wrote: > > On Fri, 1 Nov 2024 07:21:05 -0700 > > Doug Anderson <dianders@chromium.org> wrote: > > > > > FWIW, I personally have no objection to this patch and patch #3/3 in > > > Nir's series (#5/11 in your email thread) going through the ftrace > > > tree, I'm not actually the maintainer of kdb/kgdb. I'm a reviewer and > > > I try my best to help, but officially you should probably have Daniel > > > Thompson's Ack for them. ...or at least make sure he's CCed here > > > saying that you've picked them up. > > > > > > I've added him to the conversation here. > > > > Sure, I can even drop this patch if need be. Thanks for adding Daniel to > > the Cc. I probably should have run these patches through get maintainers to > > make sure everyone was accounted for. > > > I presume the tracing tree is involved because one of them changes the > kdb ftrace command? Are there dependencies between that and other > patches in the seriesm? I assume that is the reason, I just used the same recipient list that the original author of the patch series used a couple of months ago. The patch series is mostly around migrating to usage of better string to int conversion functions, so technically each change is not really dependant on the others. BTW, Thanks for the reviews Doug and for applying Steven. Nir. > > > Daniel.
On Fri, 1 Nov 2024 18:42:28 +0000 Nir Lichtman <nir@lichtman.org> wrote: > I assume that is the reason, I just used the same recipient list that > the original author of the patch series used a couple of months ago. > The patch series is mostly around migrating to usage of better string > to int conversion functions, so technically each change is not really > dependant on the others. > > BTW, Thanks for the reviews Doug and for applying Steven. Note, it's now in Daniel's court. I dropped the patches from linux-next. I took Doug's Reviewed-by tags as saying it can go through my tree. But that was jumping the gun. Sorry for the confusion. -- Steve
On Fri, Nov 01, 2024 at 02:54:39PM -0400, Steven Rostedt wrote: > On Fri, 1 Nov 2024 18:42:28 +0000 > Nir Lichtman <nir@lichtman.org> wrote: > > > BTW, Thanks for the reviews Doug and for applying Steven. > > Note, it's now in Daniel's court. I dropped the patches from linux-next. > > I took Doug's Reviewed-by tags as saying it can go through my tree. But > that was jumping the gun. > > Sorry for the confusion. Yah just saw that after sending the e-mail, no worries, still thanks :) Nir > > -- Steve
On Fri, 1 Nov 2024 18:22:04 +0000 Daniel Thompson <daniel.thompson@linaro.org> wrote: > I presume the tracing tree is involved because one of them changes the > kdb ftrace command? Are there dependencies between that and other > patches in the seriesm? Nope, I'll drop them from my queue. You can add to the tracing patch: Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org> -- Steve
© 2016 - 2024 Red Hat, Inc.