Messages in this thread | | | Date | Tue, 13 Nov 2018 17:55:58 +0100 | From | Oleg Nesterov <> | Subject | Re: [PATCH 2/2] exec: increase BINPRM_BUF_SIZE to 256 |
| |
On 11/12, Andrew Morton wrote:
> On Mon, 12 Nov 2018 17:09:56 +0100 Oleg Nesterov <oleg@redhat.com> wrote: > > > /* sizeof(linux_binprm->buf) */ > > -#define BINPRM_BUF_SIZE 128 > > +#define BINPRM_BUF_SIZE 256 > > > > #endif /* _UAPI_LINUX_BINFMTS_H */ > > It does seem a rather silly restriction, and it's tempting to suggest > reworking the code so that linux_binprm.buf is dynamically sized to > accommodate even ludicrously large strings.
I actually tried to do this ;)
Of course this is possible, but we need some limits anyway, we need to read the file until we find '\n' or '\0' in kmalloc/vmalloc'ed buffer, then split and copy the strings to bprm->vma in reverse order.
So I decided to make the trivial change for now and (hopefully) forget about this problem.
> However it would be basically cost-free to increase > BINPRM_BUF_SIZE up to the point where sizeof(struct linux_binprm) == > PAGE_SIZE?
I don't think we should take sizeof(struct linux_binprm) into account, the new members can come at any time and we can never decrease BINPRM_BUF_SIZE.
Oleg.
| |