On 10/14/26 10:51, Yao Yiqi wrote:
fbcon_rotate_font() caches a rotated copy of the console font in par->rotated.buf. The buffer is sized from the font's width, height and charcount, and is rebuilt in fbcon_init(), fbcon_switch() and fbcon_modechanged(), but not in fbcon_do_set_font().When the console font is changed through KDFONTOP/KD_FONT_OP_SET, the new font data and geometry are installed and vc_resize() is called. The resulting redraw reaches the rotated bitops before the buffer is rebuilt: hide_cursor() drives both con_cursor() -> soft_cursor() and fbcon_putc() -> *_putcs(), and they index par->rotated.buf with the new cell size and character codes. A stale, too-small buffer is read out of bounds. KASAN reports, for example: BUG: KASAN: slab-out-of-bounds in soft_cursor Read of size 64 at addr ... memcpy soft_cursor cw_cursor fbcon_cursor hide_cursor redraw_screen vc_do_resize fbcon_do_set_font fbcon_set_font con_font_op vt_ioctl Rebuild the buffer for the visible console right after the new font geometry has been installed and before any redraw, as fbcon_switch() and fbcon_modechanged() already do. Unlike those callers, this one does not fall back to unrotated rendering on failure. The "par->rotate = FB_ROTATE_UR; set_blitting_type(vc, info);" fallback they use does not actually switch to unrotated rendering: set_blitting_type() calls fbcon_set_rotation(), which immediately re-derives par->rotate from par->p->con_rotate. Replicating that pattern here would not change the outcome; a failed rebuild leaves par->rotated.buf NULL, so the rotated ops skip drawing, and the following patch retries the allocation on the next call. Fixes: 6cc50e1c5b57 ("[PATCH] fbcon: Console Rotation - Add support to rotate font bitmap") Cc: [email protected] Signed-off-by: Yao Yiqi <[email protected]> --- drivers/video/fbdev/core/fbcon.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
series applied for further testing to fbdev/for-next. Thanks! Helge
