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
