linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Slaby <jirislaby@kernel.org>
To: Peilin Ye <yepeilin.cs@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
	linux-kernel-mentees@lists.linuxfoundation.org,
	syzkaller-bugs@googlegroups.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] Prevent out-of-bounds access for built-in font data buffers
Date: Fri, 25 Sep 2020 08:46:04 +0200	[thread overview]
Message-ID: <3f754d60-1d35-899c-4418-147d922e29af@kernel.org> (raw)
In-Reply-To: <cover.1600953813.git.yepeilin.cs@gmail.com>

On 24. 09. 20, 15:38, Peilin Ye wrote:
> Hi all,
> 
> syzbot has reported [1] a global out-of-bounds read issue in
> fbcon_get_font(). A malicious user may resize `vc_font.height` to a large
> value in vt_ioctl(), causing fbcon_get_font() to overflow our built-in
> font data buffers, declared in lib/fonts/font_*.c:
> 
> (e.g. lib/fonts/font_8x8.c)
> #define FONTDATAMAX 2048
> 
> static const unsigned char fontdata_8x8[FONTDATAMAX] = {
> 
>         /* 0 0x00 '^@' */
>         0x00, /* 00000000 */
>         0x00, /* 00000000 */
>         0x00, /* 00000000 */
>         0x00, /* 00000000 */
>         0x00, /* 00000000 */
>         0x00, /* 00000000 */
>         0x00, /* 00000000 */
>         0x00, /* 00000000 */
>         [...]
> 
> In order to perform a reliable range check, fbcon_get_font() needs to know
> `FONTDATAMAX` for each built-in font under lib/fonts/. Unfortunately, we
> do not keep that information in our font descriptor,
> `struct console_font`:
> 
> (include/uapi/linux/kd.h)
> struct console_font {
> 	unsigned int width, height;	/* font size */
> 	unsigned int charcount;
> 	unsigned char *data;	/* font data with height fixed to 32 */
> };
> 
> To make things worse, `struct console_font` is part of the UAPI, so we
> cannot add a new field to keep track of `FONTDATAMAX`.

Hi,

but you still can define struct kernel_console_font containing struct
console_font and the 4 more members you need in the kernel. See below.

> Fortunately, the framebuffer layer itself gives us a hint of how to
> resolve this issue without changing UAPI. When allocating a buffer for a
> user-provided font, fbcon_set_font() reserves four "extra words" at the
> beginning of the buffer:
> 
> (drivers/video/fbdev/core/fbcon.c)
> 	new_data = kmalloc(FONT_EXTRA_WORDS * sizeof(int) + size, GFP_USER);

I might be missing something (like coffee in the morning), but why don't
you just:
1) declare struct font_data as
{
  unsigned sum, char_count, size, refcnt;
  const unsigned char data[];
}

Or maybe "struct console_font font" instead of "const unsigned char
data[]", if need be.

2) allocate by:
  kmalloc(struct_size(struct font_data, data, size));

3) use container_of wherever needed

That is you name the data on negative indexes using struct as you
already have to define one.

Then you don't need the ugly macros with negative indexes. And you can
pass this structure down e.g. to fbcon_do_set_font, avoiding potential
mistakes in accessing data[-1] and similar.

thanks,
-- 
js

  parent reply	other threads:[~2020-09-25  6:46 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-10  4:35 KASAN: global-out-of-bounds Read in fbcon_get_font syzbot
2020-01-01 17:40 ` syzbot
2020-09-24 13:38 ` [PATCH 0/3] Prevent out-of-bounds access for built-in font data buffers Peilin Ye
2020-09-24 13:40   ` [PATCH 1/3] fbdev, newport_con: Move FONT_EXTRA_WORDS macros into linux/font.h Peilin Ye
2020-09-24 13:42     ` [PATCH 2/3] Fonts: Support FONT_EXTRA_WORDS macros for built-in fonts Peilin Ye
2020-09-24 13:43       ` [PATCH 3/3] fbcon: Fix global-out-of-bounds read in fbcon_get_font() Peilin Ye
2020-09-24 14:09   ` [PATCH 0/3] Prevent out-of-bounds access for built-in font data buffers Greg Kroah-Hartman
2020-09-24 14:25     ` Peilin Ye
2020-09-24 14:42     ` David Laight
2020-09-24 15:30       ` Peilin Ye
2020-09-24 15:45         ` Dan Carpenter
2020-09-24 16:59           ` Peilin Ye
2020-09-25  8:38     ` Daniel Vetter
2020-09-25  6:46   ` Jiri Slaby [this message]
2020-09-25 10:13     ` Peilin Ye
2020-09-25 13:25       ` Daniel Vetter
2020-09-25 15:35         ` Peilin Ye
2020-09-29  9:09           ` Daniel Vetter
2020-09-29  9:44             ` Peilin Ye
2020-09-29 12:34         ` Peilin Ye
2020-09-29 14:38           ` Daniel Vetter
2020-09-30  7:11             ` Peilin Ye
2020-09-30  9:53               ` Daniel Vetter
2020-09-30 10:55                 ` Peilin Ye
2020-09-30 11:25                   ` Daniel Vetter
2020-09-30 11:52                     ` Greg Kroah-Hartman
2020-09-30 12:58                       ` Peilin Ye
2020-09-30  5:26           ` Jiri Slaby
2020-09-30  7:16             ` Peilin Ye

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3f754d60-1d35-899c-4418-147d922e29af@kernel.org \
    --to=jirislaby@kernel.org \
    --cc=b.zolnierkie@samsung.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel-mentees@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=yepeilin.cs@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).