CVE-2026-74635

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: bitblit: bound-check glyph index in bit_cursor()<br /> <br /> bit_cursor() fetches the glyph under the cursor with<br /> <br /> c = scr_readw(vc_pos);<br /> src = vc_font.data + ((c &amp; charmask) * w * height);<br /> <br /> where charmask is 0x1ff when vc_hi_font_mask is set. The screen buffer<br /> value comes directly from scr_readw() and may be larger than the current<br /> font&amp;#39;s glyph count.<br /> <br /> Syzkaller triggers this via vcs_write(). The Call Trace shows<br /> vcs_write() in vc_screen.c writing an arbitrary 16-bit value with<br /> writev() to /dev/vcsa, which vcs_write_buf() in vc_screen.c stores via<br /> vcs_scr_writew() without checking charcount. The stored value is later<br /> read in bit_cursor() in bitblit.c.<br /> <br /> When the font is changed from a font with 512 glyphs to a font with<br /> 256 glyphs, the screen buffer can retain characters with the high<br /> bit set from the previous mode, which could also produce the same<br /> out-of-bounds access.<br /> <br /> BUG: KASAN: global-out-of-bounds in soft_cursor+0x378/0x6bc drivers/video/fbdev/core/softcursor.c:70<br /> Read of size 16 at addr ffff800086c57970<br /> <br /> Call Trace:<br /> soft_cursor+0x378/0x6bc drivers/video/fbdev/core/softcursor.c:70<br /> bit_cursor+0xa90/0x1108 drivers/video/fbdev/core/bitblit.c:365<br /> fbcon_cursor+0x344/0x498 drivers/video/fbdev/core/fbcon.c:1427<br /> hide_cursor+0xdc/0x2d0 drivers/tty/vt/vt.c:883<br /> update_region+0x100/0x18c drivers/tty/vt/vt.c:669<br /> vcs_write+0x8ec/0xaf0 drivers/tty/vt/vc_screen.c:685<br /> <br /> bit_putcs_aligned() and bit_putcs_unaligned() already clamp the glyph<br /> index to vc_font.charcount. Apply the same clamp in bit_cursor() after<br /> extracting the attribute and masking, before indexing fontdata.<br /> <br /> The fix completes the bounds checking started in commit 18c4ef4e765a<br /> ("fbdev: bitblit: bound-check glyph index in bit_putcs*"), which missed<br /> the cursor path.<br /> <br /> This change should be safe because the clamp reuses the existing<br /> contract from fbcon: charcount is maintained under console_lock in<br /> con_font_set() and fbcon_font_set(), and hi_font_mask is cleared when<br /> switching from 512 to 256 glyphs. When stale screen data with high bits<br /> remains after a font switch, or when vcs_write() stores an arbitrary<br /> value, clamping the index to 0 prevents the out-of-bounds read without<br /> changing cursor semantics — the same fallback bit_putcs uses.