On 12/22/25 11:09, Gianluca Renzi wrote:
Wow! So you found the culprit.
Well, it seems pretty likely that you get the "copyright symbol", because ch gets assigned "0". The question is: Why does this happen? It shouldn't. Does it only happens with old kernels (5.x), or does it happen with latest Linux kernels (>= 6.8) too? Helge
From Wednesday I will be on Christmas holidays, so I can help if needed Ciao e buona giornata. "GP! In mezzo al campo stai proprio schifoso!" Coach M.Russo Il lun 22 dic 2025, 11:00 Helge Deller <[email protected] <mailto:[email protected]>> ha scritto: * William Burrow <[email protected] <mailto:[email protected]>>: > Hello, Camaleón and Salvatore. > I have a similar problem with the TTYs and am very glad to have found > this message. Hopefully, my reply can make it to the list. > . > The offending commit was fairly easy to find as will be detailed > later. The git bisect on the linux-stable repo found the following > commit as the problem: > . > ------------ First commit to cause the problem ------------ > commit 0998a6cb232674408a03e8561dc15aa266b2f53b > Author: Junjie Cao <[email protected] <mailto:[email protected]>> > Date: Mon Oct 20 21:47:01 2025 +0800 > > fbdev: bitblit: bound-check glyph index in bit_putcs* > > commit 18c4ef4e765a798b47980555ed665d78b71aeadf upstream. > ------------ First commit to cause the problem ------------ > . > I leave it as an exercise to the reader to solve the problem created > by this commit. Hopefully, soon. Can someone please try attached patch? Alternatively (if then another char that the "copyright symbol" is visible), we could try replacing it by: ch = 0x20; /* use ASCII space character */ Overall, I'm still puzzled if the original patch is correct. I always thought fonts have 256 or 512 characters, which means the original patch isn't necessary at all. Helge >From 65c6bb3e7d06dba09f6b529a2478ee818c14e6ef Mon Sep 17 00:00:00 2001 From: Helge Deller <[email protected] <mailto:[email protected]>> Date: Mon, 22 Dec 2025 10:19:55 +0100 Subject: [PATCH] fbdev: bitblit: fix bound-check of glyph index in bit_putcs* The patch 18c4ef4e765a ("fbdev: bitblit: bound-check glyph index in bit_putcs*") seems to trigger problems on virtual consoles, which suddently show up with lots of copyright symbols. This is e.g. reported here: https://www.reddit.com/r/debian/comments/1pnrm5t/problem_with_virtual_consoles_covered_with_a/ <https://www.reddit.com/r/debian/comments/1pnrm5t/problem_with_virtual_consoles_covered_with_a/> Try to narrow the issue down. Here we use the "last" char of a given font (instead of char #0), if the previous char exceeds the actual font's glyph count. Reported-by: Gianluca Renzi <[email protected] <mailto:[email protected]>> Signed-off-by: Helge Deller <[email protected] <mailto:[email protected]>> Fixes: 18c4ef4e765a ("fbdev: bitblit: bound-check glyph index in bit_putcs*") diff --git a/drivers/video/fbdev/core/bitblit.c b/drivers/video/fbdev/core/bitblit.c index 085ffb44c51a..6b2f9748cd78 100644 --- a/drivers/video/fbdev/core/bitblit.c +++ b/drivers/video/fbdev/core/bitblit.c @@ -87,7 +87,7 @@ static inline void bit_putcs_aligned(struct vc_data *vc, struct fb_info *info, u16 ch = scr_readw(s++) & charmask; if (ch >= charcnt) - ch = 0; + ch = (charcnt - 1); src = vc->vc_font.data + (unsigned int)ch * cellsize; if (attr) { @@ -126,7 +126,7 @@ static inline void bit_putcs_unaligned(struct vc_data *vc, u16 ch = scr_readw(s++) & charmask; if (ch >= charcnt) - ch = 0; + ch = (charcnt - 1); src = vc->vc_font.data + (unsigned int)ch * cellsize; if (attr) {
