Re: [syzbot] [hardening?] [mm?] BUG: bad usercopy in con_font_op

[Kees Cook <keescook@chromium.org>]

On Fri, Mar 03, 2023 at 01:37:55PM -0800, syzbot wrote:
> dashboard link: https://syzkaller.appspot.com/bug?extid=3af17071816b61e807ed
> [...]
> usercopy: Kernel memory exposure attempt detected from page alloc (offset 0, size 4194560)!
> [...]
> Call Trace:
>  <TASK>
>  check_heap_object mm/usercopy.c:200 [inline]
>  __check_object_size mm/usercopy.c:251 [inline]
>  __check_object_size+0x50a/0x6e0 mm/usercopy.c:213
>  check_object_size include/linux/thread_info.h:215 [inline]
>  check_copy_size include/linux/thread_info.h:251 [inline]
>  copy_to_user include/linux/uaccess.h:168 [inline]
>  con_font_get drivers/tty/vt/vt.c:4580 [inline]
>  con_font_op+0x397/0xf10 drivers/tty/vt/vt.c:4674

This is coming from the folio checking:

        } else if (folio_test_large(folio)) {
                offset = ptr - folio_address(folio);
                if (n > folio_size(folio) - offset)
                        usercopy_abort("page alloc", NULL, to_user, offset, n);
        }

triggered by copy_to_user of the font.data allocation:

#define max_font_width  64
#define max_font_height 128
#define max_font_glyphs 512
#define max_font_size   (max_font_glyphs*max_font_width*max_font_height)
	...
        font.data = kvmalloc(max_font_size, GFP_KERNEL);
	...
        if (op->data && copy_to_user(op->data, font.data, c))
                rc = -EFAULT;

it is correctly seeing "c" (4194560 in the report) as larger than
"max_font_size" (4194304, seen reported by "folio_size(folio)"). The
"c" calculation comes from:

        unsigned int vpitch = op->op == KD_FONT_OP_GET_TALL ? op->height : 32;
	...
                rc = vc->vc_sw->con_font_get(vc, &font, vpitch);
	...
        c = (font.width+7)/8 * vpitch * font.charcount;

So yes, 4194560 is larger than 4194304, and a memory exposure was,
in fact, blocked here.

Given the recent work in this area, I'm not sure which calculation is
wrong, max_font_size or c. Samuel?

-Kees

-- 
Kees Cook