[PATCH] vt: Don't exceed max_font_size on copy in con_font_get()

[PATCH] vt: Don't exceed max_font_size on copy in con_font_get()

[Roel Kluin]

font.data is kmallocd with max_font_size (defined 65536). Below occurs a
copy_to_user with `c' as a size argument. Ensure we don't copy too much.

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
 drivers/char/vt.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

If it is possible for c to be greater than 65536 then I think we may need this.
Correct?

diff --git a/drivers/char/vt.c b/drivers/char/vt.c
index 0c80c68..045af83 100644
--- a/drivers/char/vt.c
+++ b/drivers/char/vt.c
@@ -3861,6 +3861,10 @@ static int con_font_get(struct vc_data *vc, struct console_font_op *op)
 		goto out;
 
 	c = (font.width+7)/8 * 32 * font.charcount;
+	if (c > max_font_size) {
+		rc = -EINVAL;
+		goto out;
+	}
 
 	if (op->data && font.charcount > op->charcount)
 		rc = -ENOSPC;

Re: [PATCH] vt: Don't exceed max_font_size on copy in con_font_get()

[Andrew Morton]

On Mon, 23 Nov 2009 21:23:42 +0100 Roel Kluin <roel.kluin@gmail.com> wrote:

> font.data is kmallocd with max_font_size (defined 65536). Below occurs a
> copy_to_user with `c' as a size argument. Ensure we don't copy too much.
> 
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
>  drivers/char/vt.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> If it is possible for c to be greater than 65536 then I think we may need this.
> Correct?
> 
> diff --git a/drivers/char/vt.c b/drivers/char/vt.c
> index 0c80c68..045af83 100644
> --- a/drivers/char/vt.c
> +++ b/drivers/char/vt.c
> @@ -3861,6 +3861,10 @@ static int con_font_get(struct vc_data *vc, struct console_font_op *op)
>  		goto out;
>  
>  	c = (font.width+7)/8 * 32 * font.charcount;
> +	if (c > max_font_size) {
> +		rc = -EINVAL;
> +		goto out;
> +	}
>  
>  	if (op->data && font.charcount > op->charcount)
>  		rc = -ENOSPC;

Perhaps it is impossible for `c' to exceed max_font_size here.  The
check in con_font_set() will prevent it.

There are probably other places in the kernel which initialise a
console_font_op, and perhaps one of those is buggy - I didn't check.