Description

In the Linux kernel, the following vulnerability has been resolved: vdpa_sim_blk: reject out-of-range sector starts vdpasim_blk_check_range() logs an invalid start sector but continues validating the request. The subsequent unsigned capacity subtraction can underflow and let an out-of-range buffer offset reach the data path. The invalid offset is used by three request paths. VIRTIO_BLK_T_OUT copies guest data to blk->buffer + offset through vringh_iov_pull_iotlb(), causing an out-of-bounds write in _copy_from_iter() or memcpy(). VIRTIO_BLK_T_IN copies from blk->buffer + offset to the guest through vringh_iov_push_iotlb(), causing an out-of-bounds read in _copy_to_iter(). VIRTIO_BLK_T_WRITE_ZEROES passes blk->buffer + offset to memset(), causing an out-of-bounds write. Reject starts at or beyond the capacity before the subtraction. Treat the capacity boundary as invalid because the IN and OUT paths round byte counts down to sectors for validation but later copy the original byte counts. A sub-sector request at the capacity boundary would otherwise still access past the end of the buffer. I found this bug myself, though the patch was written with AI assistance.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-09-25T11:17:27.220Z",
  "pubdate": "2026-09-25T11:17:27.220Z",
  "executiveSummary": "The vdpa_sim_blk driver in the Linux kernel is susceptible to an out-of-bounds memory access vulnerability due to improper input validation of sector offsets.\nThe vulnerability arises when the vdpasim_blk_check_range() function fails to terminate request processing after identifying an invalid start sector. This leads to an integer underflow during capacity-related arithmetic, allowing an out-of-range buffer offset to reach the kernel's data path.\nAn attacker capable of crafting malicious virtio-blk requests can trigger out-of-bounds memory reads or writes within the kernel context. This can lead to memory corruption, potential kernel panic, or unauthorized data disclosure depending on the specific request type (read/write/write-zeroes).\nThe issue affects the vDPA simulator block driver. Successful exploitation requires an attacker to have access to the virtio block device interface, typically implying a degree of control over the virtualized environment. The risk is significant as it allows for arbitrary memory access via standard block I/O operations.",
  "technicalDetails": "The vulnerability resides in the vdpasim_blk_check_range() function within the vdpa_sim_blk driver. The root cause is an insufficient validation logic flow: when an invalid start sector is detected, the function logs the error but continues execution instead of returning an error code.\nThe critical flaw occurs during the subsequent capacity check, where the code performs an unsigned subtraction: (capacity - start_sector). If the provided start_sector is larger than the defined capacity, the unsigned subtraction results in an integer underflow. This underflow produces a large, wrapped value that bypasses subsequent range checks, allowing the offset to be interpreted as a valid, albeit out-of-bounds, memory location.\nThe attack flow follows three distinct paths depending on the VIRTIO_BLK request type: 1) VIRTIO_BLK_T_OUT: The driver calls vringh_iov_pull_iotlb(), which uses the tainted offset to copy guest data into the blk->buffer. This triggers an out-of-bounds write via _copy_from_iter() or memcpy(). 2) VIRTIO_BLK_T_IN: The driver calls vringh_iov_push_iotlb(), which reads from blk->buffer + offset. This results in an out-of-bounds read via _copy_to_iter(), potentially leaking kernel memory to the guest. 3) VIRTIO_BLK_T_WRITE_ZEROES: The driver passes the malicious offset to memset(), resulting in an out-of-bounds write, which corrupts adjacent memory buffers.\nFurthermore, the logic fails to account for sub-sector requests at the boundary of the capacity. Even if the start sector appears valid, the driver's rounding behavior for byte counts allows operations to cross the capacity boundary, resulting in access past the end of the allocated buffer. This combination of integer underflow and boundary condition neglect makes the kernel memory heap susceptible to corruption.\nBecause the operation occurs in the kernel's data path, a successful exploit facilitates unauthorized access to kernel memory space. An attacker does not necessarily require highly elevated privileges initially, but they must be able to issue IOCTLs or interact with the virtualized block device via the virtio-blk interface, which is a standard vector in cloud or virtualized environments."
}