Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #90555 > unrolled thread

Re: Weird characters in virtual terminal consoles from (CTRL-ALT) F2 to F6 and over F7

Started byWilliam Burrow <wbkernel@gmail.com>
First post2025-12-22 03:20 +0100
Last post2025-12-23 19:00 +0100
Articles 6 — 5 participants

Back to article view | Back to linux.debian.kernel

Contents

  Re: Weird characters in virtual terminal consoles from (CTRL-ALT) F2  to F6 and over F7 William Burrow <wbkernel@gmail.com> - 2025-12-22 03:20 +0100
    Re: Weird characters in virtual terminal consoles from (CTRL-ALT) F2  to F6 and over F7 Helge Deller <deller@kernel.org> - 2025-12-22 11:10 +0100
      Re: Weird characters in virtual terminal consoles from (CTRL-ALT) F2  to F6 and over F7 Gianluca Renzi <icjtqr@gmail.com> - 2025-12-22 11:10 +0100
        Re: Weird characters in virtual terminal consoles from (CTRL-ALT) F2  to F6 and over F7 Gianluca Renzi <gianlucarenzi@eurek.it> - 2025-12-22 12:20 +0100
          Re: Weird characters in virtual terminal consoles from (CTRL-ALT) F2  to F6 and over F7 Camaleón <noelamac@gmail.com> - 2025-12-22 16:30 +0100
            Re: Weird characters in virtual terminal consoles from (CTRL-ALT) F2  to F6 and over F7 William Burrow <wbkernel@gmail.com> - 2025-12-23 19:00 +0100

#90555 — Re: Weird characters in virtual terminal consoles from (CTRL-ALT) F2 to F6 and over F7

FromWilliam Burrow <wbkernel@gmail.com>
Date2025-12-22 03:20 +0100
SubjectRe: Weird characters in virtual terminal consoles from (CTRL-ALT) F2 to F6 and over F7
Message-ID<M4DGF-4Isq-3@gated-at.bofh.it>
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 <junjie.cao@intel.com>
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.
.
The procedure to identify this commit was as follows.  First the
problem occurred only after installing the 5.10.247 kernel from the
mentioned repo.  The 5.10.246 release did not have the problem.  So
the 5.10.246 release is a known good commit.  It was also noticed that
there were several commits labelled as fbdev soon after the latter
release.  It was verified that commit ef226cacf564 had the problem,
see below.  The bisect then only had to work through about a dozen
commits.  Far easier than between 5.10.244 and 5.10.247.
.
It should be possible to verify that this commit is the issue with
just two builds, the discovered commit ( 0998a6cb232674 ) which has
the issue and the immediate prior commit, which should not have the
issue.
.
Hopefully, this problem can be resolved easily.  I am not familiar
with this area of the code and font handling, so no suggestion.
Sorry.
.
----------- One of several commits labelled fbdev with the problem -------------
commit ef226cacf564f06e52a3b2a04b4924de5e22bca6 (HEAD)
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Mon Oct 27 16:43:37 2025 +0800

   fbdev: valkyriefb: Fix reference count leak in valkyriefb_init
------------------------
.
.
Thanks for your time and Happy Holidays,
Willam Burrow.
.


---------------Previous message --------------------
> Got it.
>
> At the moment I am very busy at work, so I cannot have the time to test them
> all.
>
> After Dec 23th I will do the tests on my home machine. Basically it's the
> same OS and kernel and same hardware, but a little older.
>
> AFAIK the issue is in the production machine, that's a different hardware at
> all (it's a MiniPC against a Dell Precision 3630 Workstation)
>
> Maybe both have an integrated Intel Graphic Card.
>
> I will check later.

Ack, for now we put ourself then in wait position unless someone else
affected can do the same bisect procedure and narrow down the
problematic commit earlier.

Thank you,

Regards,
Salvatore

[toc] | [next] | [standalone]

#90557

FromHelge Deller <deller@kernel.org>
Date2025-12-22 11:10 +0100
Message-ID<M4L1v-4NSv-5@gated-at.bofh.it>
In reply to#90555
* William Burrow <wbkernel@gmail.com>:
> 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 <junjie.cao@intel.com>
> 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 <deller@gmx.de>
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/

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 <gianlucarenzi@eurek.it>
Signed-off-by: Helge Deller <deller@gmx.de>
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) {

[toc] | [prev] | [next] | [standalone]

#90558

FromGianluca Renzi <icjtqr@gmail.com>
Date2025-12-22 11:10 +0100
Message-ID<M4L1v-4NSv-3@gated-at.bofh.it>
In reply to#90557

[Multipart message — attachments visible in raw view] — view raw

Wow! So you found the culprit.
>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 <deller@kernel.org> ha scritto:

> * William Burrow <wbkernel@gmail.com>:
> > 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 <junjie.cao@intel.com>
> > 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 <deller@gmx.de>
> 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/
>
> 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 <gianlucarenzi@eurek.it>
> Signed-off-by: Helge Deller <deller@gmx.de>
> 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) {
>
>

[toc] | [prev] | [next] | [standalone]

#90559

FromGianluca Renzi <gianlucarenzi@eurek.it>
Date2025-12-22 12:20 +0100
Message-ID<M4M7g-4OBu-11@gated-at.bofh.it>
In reply to#90558
On 12/22/25 11:13, Helge Deller wrote:
> 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?
>
The issue is not present with the kernel 5.10.0-36-amd64, only in kernel 
5.10.0-37-amd64 (5.10.247-1)

I have a couple of Debian 12 machines laying around, and this bug is not 
present for sure.

I do not remember which kernel they can have, but it's the stable Debian 
12 version.


> 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 <deller@kernel.org 
>> <mailto:deller@kernel.org>> ha scritto:
>>
>>     * William Burrow <wbkernel@gmail.com <mailto:wbkernel@gmail.com>>:
>>      > 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 <junjie.cao@intel.com 
>> <mailto:junjie.cao@intel.com>>
>>      > 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 <deller@gmx.de <mailto:deller@gmx.de>>
>>     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 <gianlucarenzi@eurek.it 
>> <mailto:gianlucarenzi@eurek.it>>
>>     Signed-off-by: Helge Deller <deller@gmx.de <mailto:deller@gmx.de>>
>>     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) {
>>
>

-- 
Eurek s.r.l.                          |
Electronic Engineering                | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy  | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377  | Fax:   +39-(0)542-609212

Invito alla riservatezza:
La  presente richiesta di  quotazione tramite posta elettronica contiene
informazioni personali e riservate. E' vietato divulgarne il contenuto a
persone diverse  dal destinatario.  Si prega i riceventi non autorizzati
di  mantenere  il  riserbo,  di informare  tempestivamente  il  mittente
dell'errore di trasmissione e di eliminare quanto per  errore pervenuto,
ivi  compresi  eventuali  allegati.  La  diffusione,  distribuzione  e/o
copiatura  delle  informazioni  trasmesse da parte di qualsiasi soggetto
diverso  dal  destinatario  e' proibita, sia ai sensi dell'art. 616 c.p.
che  ai  sensi  del  D.Lgs.196/2003  e adeguamento del nuovo Regolamento
Europeo nr. 679/2016

Invitation to privacy:
This  request  for  an  e-mail  quote  includes   personal  and  private
information. Making its content known to anyone other than the recipient
is forbidden.  Unauthorized  recipients are kindly requested to maintain
secrecy,  promptly  inform  the sender of the wrong reception and delete
what   has   been  accidentally  received,  including  any  attachments.
Spreading,  distributing  and  /  or copying the provided information by
anyone  other  than  the  addressee  is  forbidden,  according  both  to
art. 616 C.P.  and  to  D.Lgs.196  /  2003  and adaptation of the new EU
Regulation n. 679/2016

[toc] | [prev] | [next] | [standalone]

#90564

FromCamaleón <noelamac@gmail.com>
Date2025-12-22 16:30 +0100
Message-ID<M4Q1b-4R81-1@gated-at.bofh.it>
In reply to#90559
El 2025-12-22 a las 11:59 +0100, Gianluca Renzi escribió:
> On 12/22/25 11:13, Helge Deller wrote:
> > On 12/22/25 11:09, Gianluca Renzi wrote:
> > > Wow! So you found the culprit.

My deepest congrats (and a bunch of thanks) to William Burrow and 
Gianluca Renzi for their finding, testing, reporting (finally, «time 
spent») and the overall well job done! :-)

> > 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?
> > 
> The issue is not present with the kernel 5.10.0-36-amd64, only in kernel
> 5.10.0-37-amd64 (5.10.247-1)
> 
> I have a couple of Debian 12 machines laying around, and this bug is not
> present for sure.
> 
> I do not remember which kernel they can have, but it's the stable Debian 12
> version.

(...)

Well, I do confirm I CANNOT reproduce the «©©©©©©©©©©©©©©©©©©©©©©©©©©©©» 
copyright issue neither on my Debian testing (kernel image 
6.17.9+deb14) nor Debian stable (kernel image 6.1.0-41).

Cheers,

-- 
Camaleón

[toc] | [prev] | [next] | [standalone]

#90568

FromWilliam Burrow <wbkernel@gmail.com>
Date2025-12-23 19:00 +0100
Message-ID<M5ePT-57DA-11@gated-at.bofh.it>
In reply to#90564
Hello, all.
Just wanted to report on the status so far.  The patch did not work,
it printed a different weird (mess?) on the screen.  It was not a
recognizable character.  Trying 0x20 resulted in a mostly blank
screen.  The first column had characters in it, sometimes.
.
Next test was to add a printk() to the routines in question.  It was
noted that the charcnt was zero in some (most) cases.  To start were
some characters, ch, between 0x20 and 0x79 inclusive (on my machine).
Then a long list of ch == 0x20 and the charcnt == 0.  Not sure if this
is expected or if it indicates a bug somewhere else.
.
The charcnt variable was added by Junjie Cao in the patch that caused
the problem.  The patch looks like a good idea to avoid a buffer
overrun.  Maybe if charcnt is zero, the routine should just return
early?
.
Let me know and I will test it out.
.
William Burrow.
.

On Mon, Dec 22, 2025 at 11:09 AM Camaleón <noelamac@gmail.com> wrote:
>
> El 2025-12-22 a las 11:59 +0100, Gianluca Renzi escribió:
> > On 12/22/25 11:13, Helge Deller wrote:
> > > On 12/22/25 11:09, Gianluca Renzi wrote:
> > > > Wow! So you found the culprit.
>
> My deepest congrats (and a bunch of thanks) to William Burrow and
> Gianluca Renzi for their finding, testing, reporting (finally, «time
> spent») and the overall well job done! :-)
>
> > > 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?
> > >
> > The issue is not present with the kernel 5.10.0-36-amd64, only in kernel
> > 5.10.0-37-amd64 (5.10.247-1)
> >
> > I have a couple of Debian 12 machines laying around, and this bug is not
> > present for sure.
> >
> > I do not remember which kernel they can have, but it's the stable Debian 12
> > version.
>
> (...)
>
> Well, I do confirm I CANNOT reproduce the «©©©©©©©©©©©©©©©©©©©©©©©©©©©©»
> copyright issue neither on my Debian testing (kernel image
> 6.17.9+deb14) nor Debian stable (kernel image 6.1.0-41).
>
> Cheers,
>
> --
> Camaleón

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web