Re: Proper /proc/pid/cmdline behavior when command line is corrupt?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jan Engelhardt wrote:

http://www.x86-64.org/documentation/abi.pdf#search=%22argv%20envp%20x86%20ABI%22
page 29 figure 3.9 lists the data block in question as "Information
block, including argument strings, environment strings, auxiliary
information", but does not specify it further, like how it is laid out.

What it does mention is "argument pointers" (aka argv[N]) and their
exact position. In fact, right below the figure is the explanation:
"Argument strings, environment strings, and the auxiliary information
appear in no specific order within the information block and they need
not be compactly allocated."

...

Thank you for sending me that document. It seems that the bottom line is that the environment-follows-the-commandline assumption is *not* valid for future kernels, and may well not be valid for other architectures either.

I would suggest that for an application to overwrite the end of its own commandline buffer is undefined behavior.*

I'd also further suggest that the current implementation of proc_pid_cmdline() is essentially _guessing_ that the user has overwritten the end of the buffer and also guessing that the extra data can be found in the environment buffer.

Further, if a terminating nul still can't be found in the leading part of the environment buffer, proc_pid_cmdline() arbitrarily truncates the return value at the one-page mark with no attempt to insert a terminating nul. It seems to me that if we accept that it's ok to arbitrarily truncate the return value, then a better choice of truncation point would be the end of the commandline buffer.

In addition, since the code is looking for missing data in the environment buffer, we can reasonably assume that the user has inadvertantly and hopelessly corrupted their own environment. I submit that in this case, all bets are off and it doesn't really matter *what* we do at this point -- the results are undefined and can't possibly be correct.


What that means for your future patch:

The way how the arg and env strings are laid out are, as far as I can tell, defined in fs/binfmt_elf.c:create_elf_tables(). And proc_pid_cmdline() depends on this layout, yes. However, since the layout is not used anywhere outside the kernel (so says the PDF), there should not be a problem. If you modify the layout, make sure it is consistent within the kernel. It is unspecified for userspace, and a user program accessing this area nonetheless is doing so at its own risk.

Thank you for pointing this out. I'm not planning to change the layout, but perhaps a comment should be added to create_elf_tables() warning that proc_pid_cmdline() will need to be modified if the layout is ever modified.

Anyway; does anybody know why the original code was done this way, or of any applications that depend on that behavior?


Hope this helps.

Immensely.  Thank you.

	-ed falk


*Actually, by the looks of things, for a process to write to its own commandline buffer *at all* is undefined behavior, since the spec makes no guarantees of the layout of the information block.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux