CVE-2026-74635: fbdev: bitblit: bound-check glyph index in bit_cursor()
In the Linux kernel, the following vulnerability has been resolved:
fbdev: bitblit: bound-check glyph index in bitcursor()
bitcursor() fetches the glyph under the cursor with
c = scrreadw(vcpos); src = vcfont.data + ((c & charmask) w height);
where charmask is 0x1ff when vchifontmask is set. The screen buffer value comes directly from scrreadw() and may be larger than the current font's glyph count.
Syzkaller triggers this via vcswrite(). The Call Trace shows vcswrite() in vcscreen.c writing an arbitrary 16-bit value with writev() to /dev/vcsa, which vcswritebuf() in vcscreen.c stores via vcsscrwritew() without checking charcount. The stored value is later read in bitcursor() in bitblit.c.
When the font is changed from a font with 512 glyphs to a font with 256 glyphs, the screen buffer can retain characters with the high bit set from the previous mode, which could also produce the same out-of-bounds access.
BUG: KASAN: global-out-of-bounds in softcursor+0x378/0x6bc drivers/video/fbdev/core/softcursor.c:70 Read of size 16 at addr ffff800086c57970
Call Trace: softcursor+0x378/0x6bc drivers/video/fbdev/core/softcursor.c:70 bitcursor+0xa90/0x1108 drivers/video/fbdev/core/bitblit.c:365 fbconcursor+0x344/0x498 drivers/video/fbdev/core/fbcon.c:1427 hidecursor+0xdc/0x2d0 drivers/tty/vt/vt.c:883 updateregion+0x100/0x18c drivers/tty/vt/vt.c:669 vcswrite+0x8ec/0xaf0 drivers/tty/vt/vcscreen.c:685
bitputcsaligned() and bitputcsunaligned() already clamp the glyph index to vcfont.charcount. Apply the same clamp in bitcursor() after extracting the attribute and masking, before indexing fontdata.
The fix completes the bounds checking started in commit 18c4ef4e765a ("fbdev: bitblit: bound-check glyph index in bitputcs"), which missed the cursor path.
This change should be safe because the clamp reuses the existing contract from fbcon: charcount is maintained under consolelock in confontset() and fbconfontset(), and hifontmask is cleared when switching from 512 to 256 glyphs. When stale screen data with high bits remains after a font switch, or when vcswrite() stores an arbitrary value, clamping the index to 0 prevents the out-of-bounds read without changing cursor semantics — the same fallback bitputcs uses.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel drivers/video/fbdev/core/softcursor.cto a version that resolves this vulnerability.Patch commit 18c4ef4e765a
Event History
Frequently Asked Questions
What access does an attacker need to trigger the out-of-bounds access?
The triggering path described requires the ability to write arbitrary 16-bit screen-buffer values through writev() to /dev/vcsa. Those values are stored without validating them against the active font's glyph count and are later used when the cursor is rendered.
What conditions can leave a system with invalid glyph values already stored in the screen buffer?
Changing from a font with 512 glyphs to one with 256 glyphs can leave previously stored characters with the high bit set in the screen buffer. When bit_cursor() later reads one of those values, it can calculate an address beyond the current font data.
What can be done while a fix cannot be deployed?
Restrict untrusted users and processes from writing to /dev/vcsa, since the reported reproducer uses that interface to place unchecked values in the screen buffer. Avoid font transitions from 512-glyph fonts to 256-glyph fonts where possible, as this can preserve invalid character indices.