[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140609153033.GC22049@redhat.com>
Date: Mon, 9 Jun 2014 11:30:33 -0400
From: Vivek Goyal <vgoyal@...hat.com>
To: Dave Young <dyoung@...hat.com>
Cc: WANG Chao <chaowang@...hat.com>, mjg59@...f.ucam.org,
bhe@...hat.com, jkosina@...e.cz, greg@...ah.com,
kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
bp@...en8.de, ebiederm@...ssion.com, hpa@...or.com,
akpm@...ux-foundation.org
Subject: Re: [PATCH 07/13] kexec: Implementation of new syscall
kexec_file_load
On Mon, Jun 09, 2014 at 10:11:22AM +0800, Dave Young wrote:
[..]
> > > > + image->cmdline_buf = vzalloc(cmdline_len);
> > >
> > > You should validate the upper/lower boundary of cmdline_len before
> > > calling vzalloc. When cmdline_len is 0 or too large, vmalloc failure
> > > message would be fired.
> >
> > What's the upper length of vzalloc(). I think if it is too big to alloc,
> > then vzalloc() should return me an error?
>
> function __vmalloc_node_range:
> if (!size || (size >> PAGE_SHIFT) > totalram_pages)
> goto fail;
>
> So I think only checking cmdline_len == 0 is enough.
>
> For the upper length shouldn't it be stripped to COMMAND_LINE_SIZE?
We might be booting a newer kernel supporting bigger command line size
as compared to running kernel. So we query bzImage header to figure out
what's the maximum command line length supported.
Just that currently that check happens later during image load time.
Thanks
Vivek
--
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/
Powered by blists - more mailing lists