Commit c9e92cfd authored by William Lee Irwin III's avatar William Lee Irwin III Committed by Linus Torvalds

[PATCH] fix duplicate environment variables passed to init

 * 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: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
parent 67fdb651
......@@ -269,6 +269,8 @@ static int __init unknown_bootoption(char *param, char *val)
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 {
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment