In this case, count can never be -1, since it's limited by various checks in vfs_write() and rw_verify_area(), etc. Even if a very large count is passed (LONG_MAX, for example), the allocation will just fail and the OOM killer won't be involved.
Still, it's probably not a bad idea to limit this value anyway.
> count is not checked before kmalloc() call, if it is -1 then
> kmalloc() returns ZERO_SIZE_PTR. This pointer is then dereferenced.
> Also one may pass too big count to generate OOM condition.
> To prevent this limit 'count' maximum value. PAGE_SIZE looks OK.
>
> Signed-off-by: Vasiliy Kulikov <[email protected]>
> ---
> Compile tested only.
> drivers/gpu/vga/vgaarb.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
> diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
> index c380c65..09e3090 100644
> --- a/drivers/gpu/vga/vgaarb.c
> +++ b/drivers/gpu/vga/vgaarb.c
> @@ -836,6 +836,8 @@ static ssize_t vga_arb_write(struct file *file, const char __user * buf,
> int ret_val;
> int i;
>
> + if (count > PAGE_SIZE)
> + count = PAGE_SIZE;
>
> kbuf = kmalloc(count + 1, GFP_KERNEL);
> if (!kbuf)
On Sun, Nov 21, 2010 at 13:33 -0500, Dan J. Rosenberg wrote:
> In this case, count can never be -1, since it's limited by various checks in vfs_write() and rw_verify_area(), etc.
Correct, I was dummied by similar checks in similar drivers - they do
check such overflows.
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments