linux.git/drivers/video/fbdev/core, branch v7.2-rc7

fbdev: bitblit: bound-check glyph index in bit_cursor()

2026-08-08T06:08:58+00:00

bit_cursor() fetches the glyph under the cursor with

	c = scr_readw(vc_pos);
	src = vc_font.data + ((c & charmask) * w * height);

where charmask is 0x1ff when vc_hi_font_mask is set. The screen buffer
value comes directly from scr_readw() and may be larger than the current
font's glyph count.

Syzkaller triggers this via vcs_write(). The Call Trace shows
vcs_write() in vc_screen.c writing an arbitrary 16-bit value with
writev() to /dev/vcsa, which vcs_write_buf() in vc_screen.c stores via
vcs_scr_writew() without checking charcount. The stored value is later
read in bit_cursor() 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 soft_cursor+0x378/0x6bc drivers/video/fbdev/core/softcursor.c:70
  Read of size 16 at addr ffff800086c57970

  Call Trace:
   soft_cursor+0x378/0x6bc drivers/video/fbdev/core/softcursor.c:70
   bit_cursor+0xa90/0x1108 drivers/video/fbdev/core/bitblit.c:365
   fbcon_cursor+0x344/0x498 drivers/video/fbdev/core/fbcon.c:1427
   hide_cursor+0xdc/0x2d0 drivers/tty/vt/vt.c:883
   update_region+0x100/0x18c drivers/tty/vt/vt.c:669
   vcs_write+0x8ec/0xaf0 drivers/tty/vt/vc_screen.c:685

bit_putcs_aligned() and bit_putcs_unaligned() already clamp the glyph
index to vc_font.charcount. Apply the same clamp in bit_cursor() 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 bit_putcs*"), which missed
the cursor path.

This change should be safe because the clamp reuses the existing
contract from fbcon: charcount is maintained under console_lock in
con_font_set() and fbcon_font_set(), and hi_font_mask is cleared when
switching from 512 to 256 glyphs. When stale screen data with high bits
remains after a font switch, or when vcs_write() stores an arbitrary
value, clamping the index to 0 prevents the out-of-bounds read without
changing cursor semantics — the same fallback bit_putcs uses.

Reported-by: syzbot+61b1db46218109869c14@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=61b1db46218109869c14
Link: https://lore.kernel.org/all/6a75205c.01d0871a.3a0d52.0032.GAE@google.com/
Fixes: 18c4ef4e765a ("fbdev: bitblit: bound-check glyph index in bit_putcs*")
Cc: stable@vger.kernel.org
Assisted-by: Hermes:muse-spark-1.2 syzkaller
Signed-off-by: Rik van Riel 
Signed-off-by: Helge Deller

fbdev: Fix out-of-bounds access when rotating console after font resize

2026-08-08T06:08:58+00:00

[BUG]
Recently, we encountered a KASAN warning as follows:

BUG: KASAN: slab-out-of-bounds in ccw_putcs+0x8bd/0xa80
Read of size 1 at addr ff11000110067100 by task bash/1209
CPU: 10 UID: 0 PID: 1209 Comm: bash Not tainted 7.2.0-rc3 #69 PREEMPT(full)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014
 Call Trace:
  
  ...
  kasan_report+0xf0/0x120
  ? ccw_putcs+0x8bd/0xa80
  ccw_putcs+0x8bd/0xa80
  ? __pfx_ccw_putcs+0x10/0x10
  fbcon_putcs+0x338/0x410
  ? __pfx_ccw_putcs+0x10/0x10
  do_update_region+0x21d/0x450
  invert_screen+0x29d/0x5e0
  ? __kmalloc_noprof+0x493/0x640
  ? vc_do_resize+0x17c/0xe50
  clear_selection+0x4c/0x60
  vc_do_resize+0xaee/0xe50
  fbcon_modechanged+0x2bd/0x640
  rotate_all_store+0x298/0x380
  ...

reproduce:
1) issue two ioctls: first a KDFONTOP ioctl with op.op = KD_FONT_OP_SET,
op.width = 1 and op.height = 1, then a TIOCL_SETSEL ioctl
2) echo 2 > /sys/devices/virtual/graphics/fbcon/rotate_all
3) issue two ioctls: first a KDFONTOP ioctl with op.op = KD_FONT_OP_SET,
op.width = 8 and op.height = 1, then a TIOCL_SETSEL ioctl
4) echo 3 > /sys/devices/virtual/graphics/fbcon/rotate_all

[CAUSE]
The root cause is that fbcon_modechanged() first sets the current rotate's
corresponding ops. Subsequently, during vc_resize(), it may trigger
clear_selection(), and in fbcon_putcs->ccw_putcs[rotate=3], this can result
in an out-of-bounds access to "src". This happens because par->rotated.buf
is reallocated in fbcon_rotate_font():
1) When rotate=2, its size is (width + 7) / 8 * height
2) When rotate=3, its size is (height + 7) / 8 * width

And the call to fbcon_rotate_font() occurs after clear_selection(). In
other words, the fontbuffer is allocated using the size calculated from the
previous rotation 2, but before reallocating it with the new size,
con_putcs is already using the new rotation 3:

rotate_all_store
 fbcon_rotate_all
  fbcon_set_all_vcs
   fbcon_modechanged
    set_blitting_type
    ...
     par->bitops = &ccw_fbcon_bitops
    vc_resize
    ...
     clear_selection
      highlight
      ...
       do_update_region
	fbcon_putcs
	...
	 image.dy = vyres - ((xx + count) * vc->vc_font.width) [1]  // overflow!
	 ccw_putcs_aligned
	  // old buf size is still being used during the read!
	  src = par->rotated.buf + (scr_readw(s--) & charmask) * cellsize
	  fb_pad_aligned_buffer----[src KASAN!!!]	[2]
	  info->fbops->fb_imageblit(info, image)
	   sys_imageblit
	    fb_imageblit
	     fb_address_forward
	      // offset: image->dy * bits_per_line + image->dx * bpp
	      unsigned int bits = (unsigned int)adr->bits + offset
	      adr->address += (bits & ~(BITS_PER_LONG - 1u)) / BITS_PER_BYTE	[3]
	     fb_bitmap_imageblit
	     ...
	      fb_read_offset	// page fault!	[4]
    update_screen
     redraw_screen
     ...
      ccw_cursor
       soft_cursor
        memcpy(src, image->data, dsize)----[src KASAN again!!!]	[5]
     fbcon_switch
      fbcon_rotate_font
       font_data_rotate
	dst = kmalloc_array(charcount, d_cellsize, GFP_KERNEL)
       // the new size is allocated only here!
       par->rotated.buf = buf	[6]

[FIX]
A fairly obvious approach is to follow fbcon_switch(): in
fbcon_modechanged(), call rotate_font() before vc_resize() so that a
correctly sized buffer is allocated in time, as done in [6]. This fix is
necessary, but it is not sufficient on its own.

In [1] it causes an image.dy overflow (ccw_putcs: vyres = 768,
image.dy = 4294967040), because vc_cols has not been updated in time at
this point (it is likewise only updated after clear_selection()). This
allows (xx + count) * width to exceed vyres, causing image.dy to overflow.
Subsequently, address in [3] is incremented by an even larger amount, which
triggers a page fault at [4].

Therefore, a second fix is required in combination with the first: move
clear_selection() earlier, before set_blitting_type() in
fbcon_set_all_vcs(), to prevent the out-of-bounds access. fbcon_rotate()
has a similar problem, so add the same clear there. Since vc_is_sel() is
not exported, the fbdev side is currently forced to call clear_selection()
unconditionally, causing the global selection to be cleared prematurely.
And this will not cause any other significant impact.

Signed-off-by: Zizhi Wo 
Signed-off-by: Helge Deller

fbdev: core: Fix pointer desynchronization in fb_io_read()

2026-08-08T06:08:58+00:00

In fb_io_read(), if copy_to_user() performs a partial copy (e.g., due to
a faulty user buffer), the loop adjusts the chunk size 'c' and updates
the remaining 'count'. However, the hardware 'src' pointer has already
been eagerly advanced by the original chunk size.

If the loop is allowed to continue, the read will resume from an
incorrect, over-advanced offset. Since the remaining 'count' was only
decremented by the successful bytes, this desynchronization causes the
next iterations to execute more hardware reads than originally bounded,
eventually leading to out-of-bounds I/O reads.

Fix this by breaking out of the loop immediately upon a partial
copy_to_user(). A partial copy indicates a faulty user buffer, making
subsequent read attempts futile. Breaking out ensures we return the
number of successfully read bytes without risking out-of-bounds hardware
accesses in subsequent mismatched iterations.

Fixes: 6121cd9ef911 ("fbdev: Move I/O read and write code into helper functions")
Cc: stable@vger.kernel.org
Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
Signed-off-by: Helge Deller

fbdev: serialize mode sysfs access with lock_fb_info()

2026-08-08T06:08:58+00:00

show_mode(), show_modes(), and store_mode() access fb_info->modelist
and fb_info->mode without holding lock_fb_info(). store_modes() takes
lock_fb_info() while replacing the modelist and freeing the old one.

A concurrent reader or writer can load a pointer to an old modelist
entry before store_modes() frees it, then dereference freed memory or
store a stale freed pointer in fb_info->mode.

Take lock_fb_info() in show_mode(), show_modes(), and store_mode() to
serialize with store_modes(). In show_mode(), copy the mode to the
stack and format after dropping the lock. In store_mode(), split
activate() into a _locked variant to avoid double-locking, and hold
the locks for the modelist walk, mode conversion, activation, and
fb_info->mode assignment together.

Cc: stable@vger.kernel.org # v7.1+
Signed-off-by: Melbin K Mathew 
Signed-off-by: Helge Deller

fbdev: clear fb_info->mode before deleting a videomode

2026-08-08T06:08:58+00:00

fb_set_var() can delete a mode from info->modelist when userspace
passes FB_ACTIVATE_INV_MODE through FBIOPUT_VSCREENINFO. The code
checks that the mode being deleted is not the current info->var and
that fbcon is not using it, but it does not check fb_info->mode.

fb_info->mode may still point into the modelist entry being deleted.
If the entry is freed, later mode sysfs reads through show_mode() can
dereference a stale pointer.

Clear fb_info->mode before calling fb_delete_videomode() when it
matches the mode being removed.

Cc: stable@vger.kernel.org # v7.1+
Signed-off-by: Melbin K Mathew 
Signed-off-by: Helge Deller

fbdev: bound mode sysfs output to the sysfs buffer

2026-08-08T06:08:58+00:00

mode_string() uses snprintf() which can return a value larger than the
remaining buffer space. show_modes() accumulates the return value into i
without checking whether i has reached PAGE_SIZE, causing the offset to
advance past the sysfs buffer if the modelist is long enough.

Add a size parameter to mode_string() and use scnprintf() to return
only the bytes actually written. Add an early return when offset
already exceeds the buffer. In show_modes(), stop accumulating once
the buffer is full.

Cc: stable@vger.kernel.org # v7.1+
Signed-off-by: Melbin K Mathew 
Signed-off-by: Helge Deller

fbdev: Fix fb_new_modelist to prevent null-ptr-deref in fb_videomode_to_var

2026-06-26T13:12:45+00:00

info->var, a framebuffer's current mode, is expected to have a matching
entry in info->modelist. var_to_display() relies on this and treats a
failed fb_match_mode() as "This should not happen". fb_set_var() keeps it
true by adding the mode to the list on every change, and
do_register_framebuffer() does the same at registration.

store_modes() replaces the modelist from userspace. fb_new_modelist()
validates the new modes but does not check that info->var still has a
match. It relies on fbcon_new_modelist() to re-point consoles, but that
only handles consoles mapped to the framebuffer. With fbcon unbound there
are none, so info->var is left describing a mode that is no longer in the
list.

A later console takeover runs var_to_display(), where fb_match_mode()
returns NULL and leaves fb_display[i].mode NULL. fbcon_switch() passes it
to display_to_var(), and fb_videomode_to_var() dereferences the NULL mode.

Keep the current mode in the list in fb_new_modelist(), the same way
fb_set_var() does.

Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Ian Bridges 
Signed-off-by: Helge Deller

fbcon: fix NULL pointer dereference for a console without vc_data

2026-06-26T13:07:38+00:00

fbcon_new_modelist() runs when a framebuffer's modelist changes. For each
console mapped to it with fb_display[i].mode set, it reads vc_cons[i].d and
passes the vc_num to fbcon_set_disp(). This assumes a console with a mode
set has a vc_data, but it can be NULL. fbcon_set_disp() sets
fb_display[i].mode before it checks vc_data, and fbcon_deinit() leaves the
mode set after the vc_data is freed. fbcon_new_modelist() then dereferences
the NULL vc_data.

Keep fb_display[i].mode set only while the console has a vc_data. Check
vc_data before setting the mode in fbcon_set_disp(), and clear the mode in
fbcon_deinit(). The existing mode check in fbcon_new_modelist() then skips
such consoles.

Reported-by: syzbot+42525d636f430fd5d983@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=42525d636f430fd5d983
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Ian Bridges 
Signed-off-by: Helge Deller

fbdev: fix use-after-free in store_modes()

2026-06-26T12:56:13+00:00

store_modes() replaces a framebuffer's modelist with modes from userspace.
On success it frees the old modelist with fb_destroy_modelist(). Two
fields still point into that freed list.

One pointer is fb_display[i].mode, the mode a console is using.
fbcon_new_modelist() moves these pointers to the new list. It only does so
for consoles still mapped to the framebuffer. An unmapped console is
skipped and keeps its stale pointer. Unbinding fbcon, for example, sets
con2fb_map[i] to -1 but leaves fb_display[i].mode set. An
FBIOPUT_VSCREENINFO ioctl with FB_ACTIVATE_INV_MODE later reaches
fbcon_mode_deleted(). That function reads the stale fb_display[i].mode
through fb_mode_is_equal(). The read is a use-after-free.

The other pointer is fb_info->mode, the current mode. It is set through
the mode sysfs attribute. store_modes() does not update fb_info->mode, so
it is left pointing into the freed list. show_mode(), the attribute's read
handler, dereferences the stale fb_info->mode through mode_string(). The
read is a use-after-free.

Clear both pointers before freeing the list. Commit a1f305893074 ("fbcon:
Set fb_display[i]->mode to NULL when the mode is released") added the
helper fbcon_delete_modelist(). It clears every fb_display[i].mode that
points into a given list. So far it is called only from the unregister
path. Call it from store_modes() too, and set fb_info->mode to NULL.

Reported-by: syzbot+81c7c6b52649fd07299d@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=81c7c6b52649fd07299d
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/all/ajjoDhAi2y4ArSlz@dev/
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Ian Bridges 
Signed-off-by: Helge Deller

fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font()

2026-06-25T16:15:48+00:00

When fbcon_do_set_font() fails (e.g., due to a memory allocation failure
inside vc_resize() under heavy memory pressure), it jumps to the `err_out`
label to roll back the console state. However, the current rollback logic
forgets to restore the `hi_font` state, leading to a severe state machine
corruption.

Earlier in the function, `set_vc_hi_font()` might be called to change
`vc->vc_hi_font_mask` and mutate the screen buffer. If `vc_resize()`
subsequently fails, the `err_out` path restores `vc_font.charcount`
but entirely skips rolling back the `vc_hi_font_mask` and the screen
buffer.

This mismatch leaves the terminal in a desynchronized state. Because
`vc_hi_font_mask` remains set, the VT subsystem will still accept
character indices greater than 255 from userspace and write them to the
screen buffer. Subsequent rendering calls (e.g., `fbcon_putcs()`) will
then use these inflated indices to access the reverted, 256-character
font array, leading to a deterministic out-of-bounds read and potential
kernel memory disclosure.

Fix this by adding the missing rollback logic for the `hi_font` mask
and screen buffer in the error path.

Fixes: a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize() failed")
Cc: stable@vger.kernel.org
Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
Reviewed-by: Thomas Zimmermann 
Signed-off-by: Helge Deller