On Fri, Mar 3, 2017 at 4:56 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 3 March 2017 at 14:54, Eric Blake <ebl...@redhat.com> wrote: >>> + ret = -TARGET_EFAULT; >>> + break; >>> + } >>> argp = alloca((argc + 1) * sizeof(void *)); >>> envp = alloca((envc + 1) * sizeof(void *)); >> >> ...Uggh. You're using alloca() but allowing an allocation of way more >> than 4k. That means a guest can cause corruption of the stack (or, with >> large enough arguments, even escape out of the stack) before you even >> get to the execve() call to even worry about E2BIG issues. > > Yeah, linux-user is shot through with that kind of alloca() usage. > > (It's not great, but it's not a security hole because we already > give the guest binary complete control to do anything it likes. > Worth fixing bugs if we run into them, though.)
It could be a security hole if a benign guest userspace process decides to allow a remote client to specify a bunch of environment variables or so. E.g. HTTP servers with CGI support pass HTTP headers on as environment variables whose names start with "HTTP_"; however, since HTTP servers usually limit the request size, this isn't actually exploitable in that case. But there could theoretically be similar scenarios.