On Fri, Jan 02, 2026 at 05:26:22PM +0100, Ben Hutchings wrote:
Hello stable maintainers,
Several Debian users reported a regression after updating to kernel version 5.10.247.
Commit f0982400648a ("fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds"), a backport of upstream commit 3637d34b35b2, depends on vc_data::vc_font.charcount being initialised correctly.
However, before commit a1ac250a82a5 ("fbcon: Avoid using FNTCHARCNT() and hard-coded built-in font charcount") in 5.11, this member was set to 256 for VTs initially created with a built-in font and 0 for VTs initially created with a user font.
Since Debian normally sets a user font before creating VTs 2 and up, those additional VTs became unusable. VT 1 also doesn't work correctly if the user font has > 256 characters, and the bounds check is ineffective if it has < 256 characters.
This can be fixed by backporting the following commits from 5.11:
7a089ec7d77f console: Delete unused con_font_copy() callback implementations 259a252c1f4e console: Delete dummy con_font_set() and con_font_default() callback implementations 4ee573086bd8 Fonts: Add charcount field to font_desc 4497364e5f61 parisc/sticore: Avoid hard-coding built-in font charcount a1ac250a82a5 fbcon: Avoid using FNTCHARCNT() and hard-coded built-in font charcount
These all apply without fuzz and builds cleanly for x86_64 and parisc64.
I tested on x86_64 that:
- VT 2 works again
- bit_putcs_aligned() is setting charcnt = 256
- After loading a font with 512 characters, bit_putcs_aligned() sets charcnt = 512 and is able to display characters at positions >= 256
All now queued up, thanks!
greg k-h