CVE-2024-26798

In the Linux kernel, the following vulnerability has been resolved:

fbcon: always restore the old font data in fbcondoset_font()

Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when vcresize() failed) started restoring old font data upon failure (of vcresize()). But it performs so only for user fonts. It means that the "system"/internal fonts are not restored at all. So in result, the very first call to fbcondosetfont() performs no restore at all upon failing vcresize().

This can be reproduced by Syzkaller to crash the system on the next invocation of fontget(). It's rather hard to hit the allocation failure in vcresize() on the first fontset(), but not impossible. Esp. if fault injection is used to aid the execution/failure. It was demonstrated by Sirius: BUG: unable to handle page fault for address: fffffffffffffff8 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0 Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:fbcongetfont+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286 Call Trace: <TASK> confontget drivers/tty/vt/vt.c:4558 [inline] confontop+0x1fc/0xf20 drivers/tty/vt/vt.c:4673 vtkioctl drivers/tty/vt/vtioctl.c:474 [inline] vtioctl+0x632/0x2ec0 drivers/tty/vt/vtioctl.c:752 ttyioctl+0x6f8/0x1570 drivers/tty/ttyio.c:2803 vfsioctl fs/ioctl.c:51 [inline] ...

So restore the font data in any case, not only for user fonts. Note the later 'if' is now protected by 'olduserfont' and not 'olddata' as the latter is always set now. (And it is supposed to be non-NULL. Otherwise we would see the bug above again.)