Bug report: kernel oops in vmw_fb_dirty_flush()

[Zack Rusin]

On Tue, 2023-01-31 at 00:36 +0800, Keyu Tao wrote:
> !! External Email
> 
> Hi vmwgfx maintainers,
> 
> An out-of-bound access in vmwgfx specific framebuffer implementation can
> be easily triggered by fbterm (a framebuffer terminal emulator) when it
> is going to scroll screen.
> 
> With some debugging, it seems that vmw_fb_dirty_flush() cannot handle
> the vinfo.yoffset correctly after calling `ioctl(fbdev_fd,
> FBIOPAN_DISPLAY, &vinfo);`, and then subsequent access to the mapped
> memory area causes the oops.
> 
> As current mainline vmwgfx implementation (in Linux 6.2-rc) has removed
> this framebuffer implementation, this bug can be triggered only in Linux
> stable. I have tested it with vanilla 6.1.8 and 5.10.165 and they all oops.
> 
> This bug is reported in
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.debian.org%2
> Fcgi-
> bin%2Fbugreport.cgi%3Fbug%3D1029602&data=05%7C01%7Czackr%40vmware.com%7C63862e731c
> 3b4a97796808db02e03145%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C63810693415592
> 2769%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=uVOtDBAyn%2BDx5w8r1twuKO4Xd0Lma6zCr2ie3lQ%2BRR
> E%3D&reserved=0> first, and
> the maintainer there suggests me to report this issue to upstream :)
> 
> Relevant information (for self-compiled Linux 6.1.8):
> 
> - /proc/version: Linux version 6.1.8 (tao at mira) (gcc (Debian 10.2.1-6)
> 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #7 SMP
> PREEMPT_DYNAMIC Mon Jan 30 21:09:02 CST 2023
> 
> - Linux distribution: Debian GNU/Linux 11 (bullseye)
> 
> - Architecture (uname -mi): x86_64 unknown
> 
> - Virtualization software: VMware Fusion 13 Player
> 
> - How to reproduce:
>    1. Install (or compile) fbterm
>    2. Run fbterm under a tty (by a user with read & write permission to
> /dev/fb0, usually users in video group), and try to make it scroll (for
> example by pressing Enter for a few seconds)
>    3. The graphics hang and it oops.
> 

Thanks a lot for the detailed report. Is there any chance that you could try any of
the 6.2 rc releases to see if you can reproduce? We removed all of the hand rolled
fb code and ported it to drm helpers in change:
df42523c12f8 ("drm/vmwgfx: Port the framebuffer code to drm fb helpers")
which for the first time got into the official kernel in v6.2-rc1 . So any kernel
after that shouldn't crash with fbterm, if anyone could verify that'd be much
appreciated.

z