Re: [PATCH] driver: of: Properly truncate command line if too long

From: Alex Ghiti
Date: Tue Apr 06 2021 - 10:53:21 EST


Le 4/6/21 à 9:40 AM, Rob Herring a écrit :
On Sat, Apr 3, 2021 at 7:09 AM Alex Ghiti <alex@xxxxxxxx> wrote:

Hi,

Le 3/16/21 à 3:38 PM, Alexandre Ghiti a écrit :
In case the command line given by the user is too long, warn about it
and truncate it to the last full argument.

This is what efi already does in commit 80b1bfe1cb2f ("efi/libstub:
Don't parse overlong command lines").

Reported-by: Dmitry Vyukov <dvyukov@xxxxxxxxxx>
Signed-off-by: Alexandre Ghiti <alex@xxxxxxxx>
---
drivers/of/fdt.c | 21 ++++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index dcc1dd96911a..de4c6f9bac39 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -25,6 +25,7 @@
#include <linux/serial_core.h>
#include <linux/sysfs.h>
#include <linux/random.h>
+#include <linux/ctype.h>

#include <asm/setup.h> /* for COMMAND_LINE_SIZE */
#include <asm/page.h>
@@ -1050,9 +1051,27 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,

/* Retrieve command line */
p = of_get_flat_dt_prop(node, "bootargs", &l);
- if (p != NULL && l > 0)
+ if (p != NULL && l > 0) {
strlcpy(data, p, min(l, COMMAND_LINE_SIZE));

+ /*
+ * If the given command line size is larger than
+ * COMMAND_LINE_SIZE, truncate it to the last complete
+ * parameter.
+ */
+ if (l > COMMAND_LINE_SIZE) {
+ char *cmd_p = (char *)data + COMMAND_LINE_SIZE - 1;
+
+ while (!isspace(*cmd_p))
+ cmd_p--;
+
+ *cmd_p = '\0';
+
+ pr_err("Command line is too long: truncated to %d bytes\n",
+ (int)(cmd_p - (char *)data + 1));
+ }
+ }
+
/*
* CONFIG_CMDLINE is meant to be a default in case nothing else
* managed to set the command line, unless CONFIG_CMDLINE_FORCE


Any thought about that ?

It looks fine to me, but this will need to be adapted to the generic
command line support[1][2] when that is merged. So I've been waiting
to see if that's going to happen this cycle.

Ok I'll take a look then, thanks.

Alex


Rob

[1] https://lore.kernel.org/lkml/cover.1616765869.git.christophe.leroy@xxxxxxxxxx/
[2] https://lore.kernel.org/lkml/41021d66db2ab427c14255d2a24bb4517c8b58fd.1617126961.git.danielwa@xxxxxxxxx/