Re: [PATCH v2] fbcon: Set fb_display[i]->mode to NULL when the mode is released

[Helge Deller <deller@gmx.de>]

On 10/10/25 10:16, Quanmin Yan wrote:
> Recently, we discovered the following issue through syzkaller:
> 
> BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0
> Read of size 4 at addr ff11000001b3c69c by task syz.xxx
> ...
> Call Trace:
>   <TASK>
>   dump_stack_lvl+0xab/0xe0
>   print_address_description.constprop.0+0x2c/0x390
>   print_report+0xb9/0x280
>   kasan_report+0xb8/0xf0
>   fb_mode_is_equal+0x285/0x2f0
>   fbcon_mode_deleted+0x129/0x180
>   fb_set_var+0xe7f/0x11d0
>   do_fb_ioctl+0x6a0/0x750
>   fb_ioctl+0xe0/0x140
>   __x64_sys_ioctl+0x193/0x210
>   do_syscall_64+0x5f/0x9c0
>   entry_SYSCALL_64_after_hwframe+0x76/0x7e
> 
> Based on experimentation and analysis, during framebuffer unregistration,
> only the memory of fb_info->modelist is freed, without setting the
> corresponding fb_display[i]->mode to NULL for the freed modes. This leads
> to UAF issues during subsequent accesses. Here's an example of reproduction
> steps:
> 1. With /dev/fb0 already registered in the system, load a kernel module
>     to register a new device /dev/fb1;
> 2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP);
> 3. Switch console from fb to VGA (to allow normal rmmod of the ko);
> 4. Unload the kernel module, at this point fb1's modelist is freed, leaving
>     a wild pointer in fb_display[];
> 5. Trigger the bug via system calls through fb0 attempting to delete a mode
>     from fb0.
> 
> Add a check in do_unregister_framebuffer(): if the mode to be freed exists
> in fb_display[], set the corresponding mode pointer to NULL.
> 
> Signed-off-by: Quanmin Yan <yanquanmin1@huawei.com>
> --- 
>   drivers/video/fbdev/core/fbcon.c | 19 +++++++++++++++++++
>   drivers/video/fbdev/core/fbmem.c |  1 +
>   include/linux/fbcon.h            |  2 ++
>   3 files changed, 22 insertions(+)

applied.

Thanks!
Helge