Re: [PATCH] drm/vkms: fix vertical stride miscalculation in get_block_step_bytes()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] An integer overflow in `packed_pixels_offset()` causes an out-of-bounds read of kernel memory, which can be leaked to userspace via the writeback connector.
--

--- Patch [1]: [PATCH] drm/vkms: fix vertical stride miscalculation in get_block_step_bytes() ---
commit a61fac2777668983a99bbe0fb747107d5091181a
Author: Ibrahim Hashimov <security@auditcode.ai>

drm/vkms: fix vertical stride miscalculation in get_block_step_bytes()

This commit fixes a vertical stride miscalculation in get_block_step_bytes()
by replacing block width with block height for vertical directions. This
corrects an out-of-bounds read and restores the invariant that the vertical
step is exactly one row of blocks.

> drm/vkms: fix vertical stride miscalculation in get_block_step_bytes()
> 
> get_block_step_bytes() computes the byte distance between two
> vertically adjacent pixel blocks for the READ_TOP_TO_BOTTOM and
> READ_BOTTOM_TO_TOP directions as:
[ ... ]
> This is exactly how packed_pixels_offset() computes
> it a few lines above in the same file:
> 
>         int block_pitch = fb->pitches[plane_index] *
>                            drm_format_info_block_height(format, plane_index);

[Severity: High]
This is a pre-existing issue, but does the calculation in
packed_pixels_offset() suffer from a signed integer overflow?

In drivers/gpu/drm/vkms/vkms_formats.c:packed_pixels_offset(), both
block_y and block_pitch are evaluated as signed 32-bit integers.
While the DRM core restricts height * pitch <= UINT_MAX, it does not
prevent the product from exceeding INT_MAX.

If a valid framebuffer is created with height = 8192 and pitch = 524287,
the y coordinate can go up to 8191. The resulting offset calculation:

    *offset = fb->offsets[plane_index] +
              block_y * block_pitch +
              block_x * format->char_per_block[plane_index];

would cause block_y * block_pitch to exceed 2,147,483,647 and overflow
into a negative value.

Could this resulting negative offset cause the blending logic to read from
out-of-bounds kernel memory, potentially leaking it to userspace via the
writeback connector?

> For 1x1-block formats (block_width == block_height == 1) the two
> expressions happen to coincide, which is why the bug went unnoticed
[ ... ]
> diff --git a/drivers/gpu/drm/vkms/vkms_formats.c b/drivers/gpu/drm/vkms/vkms_formats.c
> index dfb8e13cba87a..1e3a6af9cea52 100644
> --- a/drivers/gpu/drm/vkms/vkms_formats.c
> +++ b/drivers/gpu/drm/vkms/vkms_formats.c
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260708223840.973-1-security@auditcode.ai?part=1