From: William Lee Irwin III <wli@holomorphy.com>
* Fixed argument processing bug in init/main.c (Eric Delaunay)
This fixes Debian BTS #58566.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=58566
From: Eric Delaunay <delaunay@lix.polytechnique.fr>
Message-Id: <200002201918.UAA02327@jazz.pontchartrain.fr>
Subject: pb in handling parameters on kernel command line
To: submit@bugs.debian.org (debian bug tracking system)
Hello, I found some bugs in kernel command line parser. AFAIK, they are not
Debian nor sparc specific but I'm not subscribed to linux-kernel mailing list
and since I'm involved with boot-floppies (mainly for sparc), I think I'm right
to report it here. Feel free to forward it upstream (I checked the latest
2.3.46 sources and it seems these bugs are still there).
These bugs are not release critical. The latter just not gives the user a
chance to overwrite TERM env var at boot time. It could be just
inconvenient for serial console boot, and in this case, our busybox' init is
already enforcing TERM=vt102.
Nevertheless if it could not be fixed before the release, I could even write a
workaround in busybox' init (it's just a matter of rewriting getenv()).
At last, it does not affect sysvinit package because serial console tty is
controlled by a getty process which is reading terminal settings on its command
line (take a look in inittab for T0 entries, if any).
Ok, here is my modest contribution to kernel hacking. I don't know much about
kernel internals but it seems that argument parsing is a bit broken.
One trivial patch for command line like "init=/bin/sh console=prom" where
console=prom is replaced by lot of spaces in previous call to setup_arch() on
sparc, therefore the line parsed by parse_options() is really
"init=/bin/sh " and a lot of null args are pushed into argv_init.
The other patch is for command line like "TERM=vt100" where both default & user
TERM entries are pushed into the env array.
Taking a look into /proc/1/environ, it shows up:
HOME=/
TERM=linux
TERM=vt100
It appears that ash (maybe other shells too) is giving the latter entry but
glibc getenv() is giving the former. It is therefore impossible to get entry
from the user in a C program like busybox' init (used in Debian boot-floppies).
I guess getenv() is not written to support duplicate entries, therefore the
kernel should avoid such construct.
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
25-akpm/init/main.c | 2 ++
1 files changed, 2 insertions(+)
diff -puN init/main.c~fix-duplicate-environment-variables-passed-to-init init/main.c
--- 25/init/main.c~fix-duplicate-environment-variables-passed-to-init 2004-06-13 21:27:35.902636264 -0700
+++ 25-akpm/init/main.c 2004-06-13 21:27:35.907635504 -0700
@@ -278,6 +278,8 @@ static int __init unknown_bootoption(cha
panic_later = "Too many boot env vars at `%s'";
panic_param = param;
}
+ if (!strncmp(param, envp_init[i], val - param))
+ break;
}
envp_init[i] = param;
} else {
_