Hi, all.
To summarize the message thread, commit 0998a6cb232 was found to be
the issue. It is unclear why this commit causes an issue. It was
added shortly after kernel v5.10.246 was released, so it was not
necessary to bisect between 5.10.244 and 5.10.247, saving time.
.
In testing, it was found that the variable charcnt is set to zero,
causing the if-statement to trigger. This should not happen. There
may be a bug somewhere else that triggers this.
.
Patching the line after the added if-statement in that commit from ch
= 0 to ch = 32 (space character) does not seem to fix the issue, it
just changes it from a screen of symbols to a (mostly) blank screen.
This is unexpected, since the address for the variable src should be
the same calculated with the change of ch = 32 with this patch or the
code before this patch.
.
Thanks for your time to review this bug.
.
------------------------- suspected commit ----------------------
diff --git a/drivers/video/fbdev/core/bitblit.c
b/drivers/video/fbdev/core/bitblit.c
index bb821b68f88c..4e774010d09f 100644
--- a/drivers/video/fbdev/core/bitblit.c
+++ b/drivers/video/fbdev/core/bitblit.c
@@ -79,12 +79,16 @@ static inline void bit_putcs_aligned(struct
vc_data *vc, struct fb_info *info,
struct fb_image *image, u8 *buf, u8 *dst)
{
u16 charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff;
+ unsigned int charcnt = vc->vc_font.charcount;
u32 idx = vc->vc_font.width >> 3;
u8 *src;
while (cnt--) {
- src = vc->vc_font.data + (scr_readw(s++)&
- charmask)*cellsize;
+ u16 ch = scr_readw(s++) & charmask;
+
+ if (ch >= charcnt)
+ ch = 0;
+ src = vc->vc_font.data + (unsigned int)ch * cellsize;
if (attr) {
update_attr(buf, src, attr, vc);
@@ -112,14 +116,18 @@ static inline void bit_putcs_unaligned(struct vc_data *vc,
u8 *dst)
{
u16 charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff;
+ unsigned int charcnt = vc->vc_font.charcount;
u32 shift_low = 0, mod = vc->vc_font.width % 8;
u32 shift_high = 8;
u32 idx = vc->vc_font.width >> 3;
u8 *src;
while (cnt--) {
- src = vc->vc_font.data + (scr_readw(s++)&
- charmask)*cellsize;
+ u16 ch = scr_readw(s++) & charmask;
+
+ if (ch >= charcnt)
+ ch = 0;
+ src = vc->vc_font.data + (unsigned int)ch * cellsize;
if (attr) {
update_attr(buf, src, attr, vc);
------------------------- suspected commit ----------------------
On Fri, Dec 26, 2025 at 12:48 PM Salvatore Bonaccorso <[email protected]> wrote:
>
> Control: tags -1 - moreinfo
> Control: forwarded -1
> https://lists.debian.org/debian-kernel/2025/12/msg00293.html
> https://lists.debian.org/debian-kernel/2025/12/msg00211.html
>
> Hi,
>
> On Sun, Dec 21, 2025 at 04:19:14PM +0000, Thorsten Glaser wrote:
> > Hi Salvatore,
> >
> > >If you can do the bisect mentioned that would help identifying the
> > >problem.
> >
> > I’m not in a position to do that currently, I don’t have a
> > fast machine anyway and packed light, too. But at least X11
> > works, so I’m fine currently.
> >
> > This is a Thinkpad X61 with Intel integrated graphics, FWIW.
>
> FTR, there is some progress in
> https://lists.debian.org/debian-kernel/2025/12/msg00293.html (which
> retrospectively we should have made a Debian BTS bug from the start
> for easier tracking).
>
> Helge, can you please include the Debian bug #1123750 in next replies?
>
> Regards,
> Salvatore
