CVE-2023-54116: drm/fbdev-generic: prohibit potential out-of-bounds access

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

drm/fbdev-generic: prohibit potential out-of-bounds access

The fbdev test of IGT may write after EOF, which lead to out-of-bound access for drm drivers with fbdev-generic. For example, run fbdev test on a x86+ast2400 platform, with 1680x1050 resolution, will cause the linux kernel hang with the following call trace:

Oops: 0000 [#1] PREEMPT SMP PTI [IGT] fbdev: starting subtest eof Workqueue: events drmfbhelperdamagework [drmkmshelper] [IGT] fbdev: starting subtest nullptr

RIP: 0010:memcpyerms+0xa/0x20 RSP: 0018:ffffa17d40167d98 EFLAGS: 00010246 RAX: ffffa17d4eb7fa80 RBX: ffffa17d40e0aa80 RCX: 00000000000014c0 RDX: 0000000000001a40 RSI: ffffa17d40e0b000 RDI: ffffa17d4eb80000 RBP: ffffa17d40167e20 R08: 0000000000000000 R09: ffff89522ecff8c0 R10: ffffa17d4e4c5000 R11: 0000000000000000 R12: ffffa17d4eb7fa80 R13: 0000000000001a40 R14: 000000000000041a R15: ffffa17d40167e30 FS: 0000000000000000(0000) GS:ffff895257380000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffa17d40e0b000 CR3: 00000001eaeca006 CR4: 00000000001706e0 Call Trace: <TASK> ? drmfbdevgenerichelperfbdirty+0x207/0x330 [drmkmshelper] drmfbhelperdamagework+0x8f/0x170 [drmkmshelper] processonework+0x21f/0x430 workerthread+0x4e/0x3c0 ? pfxworkerthread+0x10/0x10 kthread+0xf4/0x120 ? pfxkthread+0x10/0x10 retfromfork+0x2c/0x50 </TASK> CR2: ffffa17d40e0b000 ---[ end trace 0000000000000000 ]---

The is because damage rectangles computed by drmfbhelpermemoryrangetoclip() function is not guaranteed to be bound in the screen's active display area. Possible reasons are:

1) Buffers are allocated in the granularity of page size, for mmap system call support. The shadow screen buffer consumed by fbdev emulation may also choosed be page size aligned.

2) The DIVROUNDUP() used in drmfbhelpermemoryrangetoclip() will introduce off-by-one error.

For example, on a 16KB page size system, in order to store a 1920x1080 XRGB framebuffer, we need allocate 507 pages. Unfortunately, the size 192010804 can not be divided exactly by 16KB.

1920 1080 4 = 8294400 bytes 506 16 1024 = 8290304 bytes 507 16 1024 = 8306688 bytes

linelength = 19204 = 7680 bytes

507 16 1024 / 7680 = 1081.6

off / linelength = 507 16 1024 / 7680 = 1081 DIVROUNDUP(507 16 1024, 7680) will yeild 1082

memcpytoio() typically issue the copy line by line, when copy the last line, out-of-bound access will be happen. Because:

1082 linelength = 1082 7680 = 8309760, and 8309760 > 8306688

Note that userspace may still write to the invisiable area if a larger buffer than width x stride is exposed. But it is not a big issue as long as there still have memory resolve the access if not drafting so far.

- Also limit the y1 (Daniel) - keep fix patch it to minimal (Daniel) - screensize is page size aligned because of it need mmap (Thomas) - Adding fixes tag (Thomas)