linux-kernel - Re: [syzbot] [hardening?] [mm?] BUG: bad usercopy in con_font

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 3 Mar 2023 14:07:04 -0800
From:   Kees Cook <keescook@...omium.org>
To:     Samuel Thibault <samuel.thibault@...-lyon.org>,
        syzbot <syzbot+3af17071816b61e807ed@...kaller.appspotmail.com>
Cc:     akpm@...ux-foundation.org, linux-hardening@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        syzkaller-bugs@...glegroups.com, Jiri Slaby <jirislaby@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [syzbot] [hardening?] [mm?] BUG: bad usercopy in con_font_op

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