Description

In the Linux kernel, the following vulnerability has been resolved: fbdev: core: Fix pointer desynchronization in fb_io_read() In fb_io_read(), if copy_to_user() performs a partial copy (e.g., due to a faulty user buffer), the loop adjusts the chunk size 'c' and updates the remaining 'count'. However, the hardware 'src' pointer has already been eagerly advanced by the original chunk size. If the loop is allowed to continue, the read will resume from an incorrect, over-advanced offset. Since the remaining 'count' was only decremented by the successful bytes, this desynchronization causes the next iterations to execute more hardware reads than originally bounded, eventually leading to out-of-bounds I/O reads. Fix this by breaking out of the loop immediately upon a partial copy_to_user(). A partial copy indicates a faulty user buffer, making subsequent read attempts futile. Breaking out ensures we return the number of successfully read bytes without risking out-of-bounds hardware accesses in subsequent mismatched iterations.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.3",
  "pubDate": "2026-08-26T15:17:13.880Z",
  "pubdate": "2026-08-26T15:17:13.880Z",
  "executiveSummary": "The Linux kernel framebuffer device (fbdev) subsystem contains a critical pointer desynchronization vulnerability within the fb_io_read() function. This flaw arises from improper handling of partial copy_to_user() operations during memory copy loops. When a user-provided buffer is faulty or restricted, the kernel fails to account for the hardware source pointer being prematurely incremented, leading to a state where the remaining data length is misaligned with the hardware source offset.\nThis vulnerability is classified as an out-of-bounds read, potentially leading to kernel memory information disclosure or system instability. It affects systems utilizing the fbdev framework for graphical output. The impact is significant, as an attacker with local access can trigger this condition by providing a maliciously crafted, faulty buffer to a framebuffer device node. Successful exploitation allows for out-of-bounds I/O reads, which could be leveraged to leak sensitive kernel memory contents. No specific network exposure is required, as the vector is local to the device file interface.",
  "technicalDetails": "The vulnerability resides within the core fb_io_read() function in the Linux kernel fbdev subsystem. The function is designed to facilitate reading data from framebuffer device memory into a user-space buffer. During this operation, the function iterates through data chunks, copying them from the hardware source (src) to the destination user buffer using the copy_to_user() function.\nThe root cause is a logic error in handling partial copy_to_user() failures. In the event of a partial copy—often triggered by a user-supplied buffer that is partially unmapped or invalid—the kernel logic incorrectly adjusts the chunk size and the remaining 'count' variable. However, the hardware source pointer ('src') has already been updated based on the original intended chunk size. This creates a state of pointer desynchronization: the hardware pointer is advanced further than the data successfully copied into the user buffer.\nBecause the 'count' variable (representing remaining bytes to be read) is decremented only by the number of bytes successfully copied, the loop condition persists. In subsequent iterations, the function attempts to read additional data using the over-advanced 'src' pointer. Because the pointers no longer align with the intended data structure, the function performs reads starting from an incorrect offset. This results in the function accessing and potentially returning memory regions beyond the intended hardware buffer bounds, leading to out-of-bounds I/O reads.\nThe attack flow proceeds as follows: 1) An attacker opens a framebuffer device node (e.g., /dev/fb0). 2) The attacker invokes the read() syscall with a malicious, partially valid user buffer designed to induce a partial failure in copy_to_user(). 3) Upon partial failure, the kernel adjusts internal counters but maintains the corrupted pointer state. 4) The loop continues, performing subsequent iterations that read data from the wrong memory address. 5) The result is that the attacker receives a mix of valid framebuffer data and unintended kernel memory content.\nThis vulnerability does not require special privileges beyond the ability to open the framebuffer device node, though access to such nodes is typically restricted to local users. The primary post-exploitation impact is the unauthorized disclosure of kernel-space memory, which can facilitate further exploitation by bypassing KASLR or leaking sensitive structures."
}