linux-kernel - Re: [PATCH v2] gpu: vga: limit kmalloc'ed memory size

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]

Date:	Mon, 22 Nov 2010 10:09:15 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Vasiliy Kulikov <segoon@...nwall.com>
Cc:	kernel-janitors@...r.kernel.org, Dave Airlie <airlied@...hat.com>,
	Tiago Vignatti <tiago.vignatti@...ia.com>,
	Mike Travis <travis@....com>, "H. Peter Anvin" <hpa@...or.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] gpu: vga: limit kmalloc'ed memory size

On Mon, 22 Nov 2010 20:11:03 +0300 Vasiliy Kulikov <segoon@...nwall.com> wrote:

> count is not checked before kmalloc() call.  Too big value would
> generate stack dump.  To prevent this limit 'count' maximum value.
> 1024 looks OK - the data should be the string of tens of bytes.
> 
> Signed-off-by: Vasiliy Kulikov <segoon@...nwall.com>
> ---
>  Compile tested only.
> 
>  v1 had incorrect comment text, as Dan Rosenberg noticed.
> 
>  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 > 1024)
> +		count = 1024;
>  
>  	kbuf = kmalloc(count + 1, GFP_KERNEL);
>  	if (!kbuf)

Bit ugly, that.

Arguably we should just let the allocation attempt pass through to
kmalloc() and let kmalloc() return an error if it was too large.  Possibly
we need a __GFP_NOWARN in there somewhere.  Please send us that stack
dump?

The code should be using strndup_user() anyway.  And perhaps
strndup_user() needs __GFP_NOWARN treatment.

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