Bug report: kernel oops in vmw_fb_dirty_flush()

[Keyu Tao]

Hi Rusin,

Thank you for your timely response. I tested that this bug is not 
reproducible in v6.2-rc5 yesterday.

On 1/31/23 03:54, Zack Rusin wrote:
> 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