Linux Framebuffer Layer development
 help / color / mirror / Atom feed
From: Yao Yiqi <yaoyiqi3@huawei.com>
To: <deller@gmx.de>, <tzimmermann@suse.de>, <simona@ffwll.ch>
Cc: <dri-devel@lists.freedesktop.org>, <linux-fbdev@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: [PATCH 1/2] fbcon: Rebuild rotated font buffer on font change
Date: Wed, 14 Oct 2026 08:51:01 +0000	[thread overview]
Message-ID: <20261014085102.497789-1-yaoyiqi3@huawei.com> (raw)

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: stable@vger.kernel.org
Signed-off-by: Yao Yiqi <yaoyiqi3@huawei.com>
---
 drivers/video/fbdev/core/fbcon.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 01715873ea49..5cef18043bdb 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2432,6 +2432,17 @@ static int fbcon_do_set_font(struct vc_data *vc, int w, int h, int charcount,
 	else if (!vc->vc_hi_font_mask && charcount == 512)
 		set_vc_hi_font(vc, true);
 
+	/*
+	 * The rotated font buffer is sized from the new font's width, height
+	 * and charcount. Rebuild it for the visible console before the redraw
+	 * below, as fbcon_switch() and fbcon_modechanged() already do. The
+	 * redraw reaches the rotated bitops through hide_cursor(), and those
+	 * index the buffer with the new cell size and character codes, so a
+	 * stale, too-small buffer is read out of bounds.
+	 */
+	if (con_is_visible(vc) && par->bitops->rotate_font)
+		par->bitops->rotate_font(info, vc);
+
 	if (resize) {
 		int cols, rows;
 
-- 
2.34.1


             reply	other threads:[~2026-10-14  9:09 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-14  8:51 Yao Yiqi [this message]
2026-10-14  8:51 ` [PATCH 2/2] fbcon: Retry rotated font allocation after failure Yao Yiqi
2026-10-14 19:58 ` [PATCH 1/2] fbcon: Rebuild rotated font buffer on font change Helge Deller

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=20261014085102.497789-1-yaoyiqi3@huawei.com \
    --to=yaoyiqi3@huawei.com \
    --cc=deller@gmx.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    /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