CVE-2023-54116
Severity CVSS v4.0:
Pending analysis
Type:
Unavailable / Other
Publication date:
24/12/2025
Last modified:
24/12/2025
Description
In the Linux kernel, the following vulnerability has been resolved:<br />
<br />
drm/fbdev-generic: prohibit potential out-of-bounds access<br />
<br />
The fbdev test of IGT may write after EOF, which lead to out-of-bound<br />
access for drm drivers with fbdev-generic. For example, run fbdev test<br />
on a x86+ast2400 platform, with 1680x1050 resolution, will cause the<br />
linux kernel hang with the following call trace:<br />
<br />
Oops: 0000 [#1] PREEMPT SMP PTI<br />
[IGT] fbdev: starting subtest eof<br />
Workqueue: events drm_fb_helper_damage_work [drm_kms_helper]<br />
[IGT] fbdev: starting subtest nullptr<br />
<br />
RIP: 0010:memcpy_erms+0xa/0x20<br />
RSP: 0018:ffffa17d40167d98 EFLAGS: 00010246<br />
RAX: ffffa17d4eb7fa80 RBX: ffffa17d40e0aa80 RCX: 00000000000014c0<br />
RDX: 0000000000001a40 RSI: ffffa17d40e0b000 RDI: ffffa17d4eb80000<br />
RBP: ffffa17d40167e20 R08: 0000000000000000 R09: ffff89522ecff8c0<br />
R10: ffffa17d4e4c5000 R11: 0000000000000000 R12: ffffa17d4eb7fa80<br />
R13: 0000000000001a40 R14: 000000000000041a R15: ffffa17d40167e30<br />
FS: 0000000000000000(0000) GS:ffff895257380000(0000) knlGS:0000000000000000<br />
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br />
CR2: ffffa17d40e0b000 CR3: 00000001eaeca006 CR4: 00000000001706e0<br />
Call Trace:<br />
<br />
? drm_fbdev_generic_helper_fb_dirty+0x207/0x330 [drm_kms_helper]<br />
drm_fb_helper_damage_work+0x8f/0x170 [drm_kms_helper]<br />
process_one_work+0x21f/0x430<br />
worker_thread+0x4e/0x3c0<br />
? __pfx_worker_thread+0x10/0x10<br />
kthread+0xf4/0x120<br />
? __pfx_kthread+0x10/0x10<br />
ret_from_fork+0x2c/0x50<br />
<br />
CR2: ffffa17d40e0b000<br />
---[ end trace 0000000000000000 ]---<br />
<br />
The is because damage rectangles computed by<br />
drm_fb_helper_memory_range_to_clip() function is not guaranteed to be<br />
bound in the screen&#39;s active display area. Possible reasons are:<br />
<br />
1) Buffers are allocated in the granularity of page size, for mmap system<br />
call support. The shadow screen buffer consumed by fbdev emulation may<br />
also choosed be page size aligned.<br />
<br />
2) The DIV_ROUND_UP() used in drm_fb_helper_memory_range_to_clip()<br />
will introduce off-by-one error.<br />
<br />
For example, on a 16KB page size system, in order to store a 1920x1080<br />
XRGB framebuffer, we need allocate 507 pages. Unfortunately, the size<br />
1920*1080*4 can not be divided exactly by 16KB.<br />
<br />
1920 * 1080 * 4 = 8294400 bytes<br />
506 * 16 * 1024 = 8290304 bytes<br />
507 * 16 * 1024 = 8306688 bytes<br />
<br />
line_length = 1920*4 = 7680 bytes<br />
<br />
507 * 16 * 1024 / 7680 = 1081.6<br />
<br />
off / line_length = 507 * 16 * 1024 / 7680 = 1081<br />
DIV_ROUND_UP(507 * 16 * 1024, 7680) will yeild 1082<br />
<br />
memcpy_toio() typically issue the copy line by line, when copy the last<br />
line, out-of-bound access will be happen. Because:<br />
<br />
1082 * line_length = 1082 * 7680 = 8309760, and 8309760 > 8306688<br />
<br />
Note that userspace may still write to the invisiable area if a larger<br />
buffer than width x stride is exposed. But it is not a big issue as<br />
long as there still have memory resolve the access if not drafting so<br />
far.<br />
<br />
- Also limit the y1 (Daniel)<br />
- keep fix patch it to minimal (Daniel)<br />
- screen_size is page size aligned because of it need mmap (Thomas)<br />
- Adding fixes tag (Thomas)



