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

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4501A583.2050500@google.com>
Date:	Fri, 08 Sep 2006 10:16:51 -0700
From:	Edward Falk <efalk@...gle.com>
To:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
CC:	linux-kernel@...r.kernel.org
Subject: Re: Proper /proc/pid/cmdline behavior when command line is corrupt?

Jan Engelhardt wrote:
> Hi Edward,

>>that the environment buffer is assumed to immediately follow the
>>command line buffer.
> 
> 
> The environment buffer is not assumed to be there, it is _known_ to come right
> after the argument string, because that is how the kernel sets it up on execve
> (for x86 at least).

Is that in a spec somewhere?  Otherwise, I would argue that it isn't 
_known_ to come right after the argument string, it just _happens_ to 
come right after the argument string.  This could change in future kernels.

>>I'm currently working on a patch that removes the one page limit on
>>the returned command line buffer but I'm not convinced I should
>>retain this behavior.
> 
> 
> I think yes. proc_pid_cmdline() has these lines:
> 
> 	len = mm->arg_end - mm->arg_start
>   *	if (len > PAGE_SIZE)
>   *		len = PAGE_SIZE;
> 	res = access_process_vm(task, mm->arg_start, buffer, len, 0);
> 
> 
> and @buffer is allocated in the caller as only one page:

True, but that's an arbitrary limitation which I'm in the process of 
removing.  I have a new version of proc_pid_cmdline() which will return 
the entire commandline buffer no matter what its length.  If the 
grab-more-data-from-environment-buffer behavior is actually broken, I'd 
rather not propagate it to the new code.

	-ed falk
-
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/