user/sven/linux.git/drivers/tty/vt, branch v5.12.15

tty: vt: always invoke vc->vc_sw->con_resize callback

2021-05-26T10:59:14Z

commit ffb324e6f874121f7dce5bdae5e05d02baae7269 upstream. syzbot is reporting OOB write at vga16fb_imageblit() [1], for resize_screen() from ioctl(VT_RESIZE) returns 0 without checking whether requested rows/columns fit the amount of memory reserved for the graphical screen if current mode is KD_GRAPHICS. ---------- #include #include #include #include #include #include int main(int argc, char *argv[]) { const int fd = open("/dev/char/4:1", O_RDWR); struct vt_sizes vt = { 0x4100, 2 }; ioctl(fd, KDSETMODE, KD_GRAPHICS); ioctl(fd, VT_RESIZE, &vt); ioctl(fd, KDSETMODE, KD_TEXT); return 0; } ---------- Allow framebuffer drivers to return -EINVAL, by moving vc->vc_mode != KD_GRAPHICS check from resize_screen() to fbcon_resize(). Link: https://syzkaller.appspot.com/bug?extid=1f29e126cf461c4de3b3 [1] Reported-by: syzbot Suggested-by: Linus Torvalds Signed-off-by: Tetsuo Handa Tested-by: syzbot Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

vt: Fix character height handling with VT_RESIZEX

2021-05-26T10:59:13Z

commit 860dafa902595fb5f1d23bbcce1215188c3341e6 upstream. Restore the original intent of the VT_RESIZEX ioctl's `v_clin' parameter which is the number of pixel rows per character (cell) rather than the height of the font used. For framebuffer devices the two values are always the same, because the former is inferred from the latter one. For VGA used as a true text mode device these two parameters are independent from each other: the number of pixel rows per character is set in the CRT controller, while font height is in fact hardwired to 32 pixel rows and fonts of heights below that value are handled by padding their data with blanks when loaded to hardware for use by the character generator. One can change the setting in the CRT controller and it will update the screen contents accordingly regardless of the font loaded. The `v_clin' parameter is used by the `vgacon' driver to set the height of the character cell and then the cursor position within. Make the parameter explicit then, by defining a new `vc_cell_height' struct member of `vc_data', set it instead of `vc_font.height' from `v_clin' in the VT_RESIZEX ioctl, and then use it throughout the `vgacon' driver except where actual font data is accessed which as noted above is independent from the CRTC setting. This way the framebuffer console driver is free to ignore the `v_clin' parameter as irrelevant, as it always should have, avoiding any issues attempts to give the parameter a meaning there could have caused, such as one that has led to commit 988d0763361b ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE"): "syzbot is reporting UAF/OOB read at bit_putcs()/soft_cursor() [1][2], for vt_resizex() from ioctl(VT_RESIZEX) allows setting font height larger than actual font height calculated by con_font_set() from ioctl(PIO_FONT). Since fbcon_set_font() from con_font_set() allocates minimal amount of memory based on actual font height calculated by con_font_set(), use of vt_resizex() can cause UAF/OOB read for font data." The problem first appeared around Linux 2.5.66 which predates our repo history, but the origin could be identified with the old MIPS/Linux repo also at: as commit 9736a3546de7 ("Merge with Linux 2.5.66."), where VT_RESIZEX code in `vt_ioctl' was updated as follows: if (clin) - video_font_height = clin; + vc->vc_font.height = clin; making the parameter apply to framebuffer devices as well, perhaps due to the use of "font" in the name of the original `video_font_height' variable. Use "cell" in the new struct member then to avoid ambiguity. References: [1] https://syzkaller.appspot.com/bug?id=32577e96d88447ded2d3b76d71254fb855245837 [2] https://syzkaller.appspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3 Signed-off-by: Maciej W. Rozycki Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org # v2.6.12+ Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

vt_ioctl: Revert VT_RESIZEX parameter handling removal

2021-05-26T10:59:13Z

commit a90c275eb144c1b755f04769e1f29d832d6daeaf upstream. Revert the removal of code handling extra VT_RESIZEX ioctl's parameters beyond those that VT_RESIZE supports, fixing a functional regression causing `svgatextmode' not to resize the VT anymore. As a consequence of the reverted change when the video adapter is reprogrammed from the original say 80x25 text mode using a 9x16 character cell (720x400 pixel resolution) to say 80x37 text mode and the same character cell (720x592 pixel resolution), the VT geometry does not get updated and only upper two thirds of the screen are used for the VT, and the lower part remains blank. The proportions change according to text mode geometries chosen. Revert the change verbatim then, bringing back previous VT resizing. Signed-off-by: Maciej W. Rozycki Fixes: 988d0763361b ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE") Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

tty: fix memory leak in vc_deallocate

2021-05-12T06:40:03Z

commit 211b4d42b70f1c1660feaa968dac0efc2a96ac4d upstream. syzbot reported memory leak in tty/vt. The problem was in VT_DISALLOCATE ioctl cmd. After allocating unimap with PIO_UNIMAP it wasn't freed via VT_DISALLOCATE, but vc_cons[currcons].d was zeroed. Reported-by: syzbot+bcc922b19ccc64240b42@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Cc: stable Link: https://lore.kernel.org/r/20210327214443.21548-1-paskripkin@gmail.com Signed-off-by: Greg Kroah-Hartman

vt_ioctl: Remove in_interrupt() check

2021-02-09T10:45:04Z

reset_vc() uses a "!in_interrupt()" conditional before resetting the palettes, which is a blocking operation. Since commit 8b6312f4dcc1e ("[PATCH] vt: refactor console SAK processing") all calls are invoked from a workqueue process context, with the blocking console lock always acquired. Remove the "!in_interrupt()" check. Signed-off-by: Ahmed S. Darwish Signed-off-by: Sebastian Andrzej Siewior Link: https://lore.kernel.org/r/20210208181615.381861-2-bigeasy@linutronix.de Signed-off-by: Greg Kroah-Hartman

vt: keyboard, use new API for keyboard_tasklet

2021-01-27T17:08:07Z

This converts the keyboard_tasklet to use the new API in commit 12cc923f1ccc ("tasklet: Introduce new initialization API") The new API changes the argument passed to the callback function, but fortunately the argument isn't used so it is straight forward to use DECLARE_TASKLET_DISABLED() rather than DECLARE_TASKLET_DISABLED_OLD(). Signed-off-by: Emil Renner Berthing Link: https://lore.kernel.org/r/20210127164222.13220-1-kernel@esmil.dk Signed-off-by: Greg Kroah-Hartman

vt: drop old FONT ioctls

2021-01-07T15:17:31Z

Drop support for these ioctls: * PIO_FONT, PIO_FONTX * GIO_FONT, GIO_FONTX * PIO_FONTRESET As was demonstrated by commit 90bfdeef83f1 (tty: make FONTX ioctl use the tty pointer they were actually passed), these ioctls are not used from userspace, as: 1) they used to be broken (set up font on current console, not the open one) and racy (before the commit above) 2) KDFONTOP ioctl is used for years instead Note that PIO_FONTRESET is defunct on most systems as VGA_CONSOLE is set on them for ages. That turns on BROKEN_GRAPHICS_PROGRAMS which makes PIO_FONTRESET just return an error. We are removing KD_FONT_FLAG_OLD here as it was used only by these removed ioctls. kd.h header exists both in kernel and uapi headers, so we can remove the kernel one completely. Everyone includeing kd.h will now automatically get the uapi one. There are now unused definitions of the ioctl numbers and "struct consolefontdesc" in kd.h, but as it is a uapi header, I am not touching these. Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20210105120239.28031-8-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman

vt/consolemap: do font sum unsigned

2021-01-07T15:17:31Z

The constant 20 makes the font sum computation signed which can lead to sign extensions and signed wraps. It's not much of a problem as we build with -fno-strict-overflow. But if we ever decide not to, be ready, so switch the constant to unsigned. Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20210105120239.28031-7-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman

vt: keyboard, defkeymap.c_shipped, approach the unicode table

2021-01-07T15:17:31Z

Commit 5ce2087ed0eb (Fix default compose table initialization) fixed unicode table so that the values are not sign extended. The upstream (kbd package) chose a different approach. They use hexadecimal values. So use the same, so that the output of loadkeys and our shipped file correspond more to each other. Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20210105120239.28031-4-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman

vt: keyboard, defkeymap.c_shipped, approach the definitions

2021-01-07T15:17:31Z

loadkeys (from kbd) generates 'unsigned short' instead of 'u_short' since 2.0.3. It also marks maps as 'static' for longer than kbd's history. So adapt the shipped defkeymap.c to conform more to loadkeys output. Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20210105120239.28031-3-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman