CVE-2023-54116 in Linux
Summary
by MITRE • 12/24/2025
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 drm_fb_helper_damage_work [drm_kms_helper]
[IGT] fbdev: starting subtest nullptr
RIP: 0010:memcpy_erms+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> ? drm_fbdev_generic_helper_fb_dirty+0x207/0x330 [drm_kms_helper]
drm_fb_helper_damage_work+0x8f/0x170 [drm_kms_helper]
process_one_work+0x21f/0x430 worker_thread+0x4e/0x3c0 ? __pfx_worker_thread+0x10/0x10 kthread+0xf4/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 </TASK> CR2: ffffa17d40e0b000 ---[ end trace 0000000000000000 ]---
The is because damage rectangles computed by drm_fb_helper_memory_range_to_clip() 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 DIV_ROUND_UP() used in drm_fb_helper_memory_range_to_clip() 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 1920*1080*4 can not be divided exactly by 16KB.
1920 * 1080 * 4 = 8294400 bytes 506 * 16 * 1024 = 8290304 bytes 507 * 16 * 1024 = 8306688 bytes
line_length = 1920*4 = 7680 bytes
507 * 16 * 1024 / 7680 = 1081.6
off / line_length = 507 * 16 * 1024 / 7680 = 1081 DIV_ROUND_UP(507 * 16 * 1024, 7680) will yeild 1082
memcpy_toio() typically issue the copy line by line, when copy the last line, out-of-bound access will be happen. Because:
1082 * line_length = 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) - screen_size is page size aligned because of it need mmap (Thomas) - Adding fixes tag (Thomas)
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 01/03/2026
The vulnerability described in CVE-2023-54116 affects the Linux kernel's direct rendering manager subsystem, specifically within the drm_fbdev_generic_helper_fb_dirty function that handles framebuffer device operations. This issue stems from improper bounds checking during memory management operations that can lead to out-of-bounds memory access conditions. The flaw manifests when the fbdev test of the Intel Graphics Test (IGT) framework attempts to write beyond the end of file boundaries, causing kernel hangs and potential system instability. The root cause lies in the drm_fb_helper_memory_range_to_clip() function which computes damage rectangles without ensuring they remain within the screen's active display area, creating a scenario where memory operations can access regions outside allocated buffer boundaries.
The technical implementation of this vulnerability involves several critical components that together create the exploitable condition. The system allocates framebuffer buffers in page-sized increments to support memory mapping operations, but this alignment can result in buffer sizes that exceed the exact memory requirements for the display resolution. When calculating damage rectangles using DIV_ROUND_UP() operations, the computation introduces off-by-one errors that cause the system to attempt memory operations beyond valid buffer boundaries. The specific example demonstrates how a 1920x1080 XRGB framebuffer requiring 8,294,400 bytes gets allocated in 507 pages of 16KB each, totaling 8,306,688 bytes. This discrepancy causes issues when memcpy_toio() operations attempt to copy data to the last line, as the calculated address exceeds the allocated buffer size by approximately 3,072 bytes.
The operational impact of this vulnerability extends beyond simple memory corruption to potentially cause complete system hangs and kernel panics. When the kernel attempts to perform memory operations beyond allocated bounds, it triggers the kernel oops mechanism as demonstrated in the call trace showing memcpy_erms failing with a segmentation fault. The system becomes unresponsive during the damage work queue processing, as indicated by the workqueue execution path through drm_fb_helper_damage_work, which is part of the drm_kms_helper module. This type of vulnerability directly relates to CWE-129, which addresses improper validation of array indices, and can be classified under ATT&CK technique T1068, which covers exploit for privilege escalation through local system exploits. The vulnerability is particularly concerning because it affects the graphics subsystem's core functionality and can be triggered through standard graphics testing procedures.
Mitigation strategies for this vulnerability should focus on implementing strict bounds checking within the drm_fb_helper_memory_range_to_clip() function to ensure damage rectangles remain within valid display boundaries. The fix should limit the y1 coordinate as suggested in the patch, and maintain minimal changes to avoid introducing new issues while ensuring proper memory access validation. Additionally, the system should enforce proper buffer size calculations that account for page alignment requirements without creating overflow conditions. Kernel maintainers should implement comprehensive input validation for framebuffer operations and ensure that all memory access operations are bounded by the actual allocated buffer sizes. The solution must balance the need for memory mapping support with proper bounds enforcement to prevent out-of-bounds access while maintaining system stability and performance characteristics.