linux-kernel - [PATCH] init: fix in-place parameter modification regression

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 12 Oct 2013 20:05:00 +0200
From:	Krzysztof Mazur <krzysiek@...lesie.net>
To:	linux-kernel@...r.kernel.org
Cc:	Pawel Moll <pawel.moll@....com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Krzysztof Mazur <krzysiek@...lesie.net>
Subject: [PATCH] init: fix in-place parameter modification regression

Before commit 026cee0086fe1df4cf74691cf273062cc769617d
("params: <level>_initcall-like kernel parameters") the __setup
parameter parsing code could modify parameter in the
static_command_line buffer and such modifications were kept. After
that commit such modifications are destroyed during per-initcall level
parameter parsing because the same static_command_line buffer is used
and only parameters for appropriate initcall level are parsed.

That change broke at least parsing "ubd" parameter in the ubd driver
when the COW file is used.

Now the separate buffer is used for per-initcall parameter parsing,
like in parsing early params.

Signed-off-by: Krzysztof Mazur <krzysiek@...lesie.net>
---
Hi,

this patch fixes an old Linux 3.4 regression in ubd parameter parsing.
It was previously reported by the David Fernández in the
"ubd option parsing problem when using cow filesystems in kernel 3.4"
thread on user-mode-linux-devel mailing list
(http://marc.info/?t=134009640700003&r=1&w=2).
The bug still exists in the Linux 3.12-rc4.

I've been using a different patch that changed the ubd driver. I just
copied the parsed filename to separate buffer, but I think it's better
to fix generic code.

Maybe the tmp_cmdline should be shared with the parse_early_param().

Regards,
Krzysiek

 init/main.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/init/main.c b/init/main.c
index 63d3e8f..e5b322a 100644
--- a/init/main.c
+++ b/init/main.c
@@ -742,12 +742,13 @@ static char *initcall_level_names[] __initdata = {

 static void __init do_initcall_level(int level)
 {
+	static __initdata char tmp_cmdline[COMMAND_LINE_SIZE];
 	extern const struct kernel_param __start___param[], __stop___param[];
 	initcall_t *fn;

-	strcpy(static_command_line, saved_command_line);
+	strcpy(tmp_cmdline, saved_command_line);
 	parse_args(initcall_level_names[level],
-		   static_command_line, __start___param,
+		   tmp_cmdline, __start___param,
 		   __stop___param - __start___param,
 		   level, level,
 		   &repair_env_string);
-- 
1.8.4.652.g0d6e0ce

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/