[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20091123184646.ba8aadc8.akpm@linux-foundation.org>
Date: Mon, 23 Nov 2009 18:46:46 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Roel Kluin <roel.kluin@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] vt: Don't exceed max_font_size on copy in
con_font_get()
On Mon, 23 Nov 2009 21:23:42 +0100 Roel Kluin <roel.kluin@...il.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@...il.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.
--
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