Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Critical] The fix for delayed VSP responses is incomplete, leaving a critical data race on the shared `hv->init_buf` that allows type confusion and out-of-bounds memory reads. --
commit 3d049f39a946f7898e25e92a422ae95b066e9989 Author: Berkant Koc <[email protected]> drm/hyperv: validate resolution_count and harden VSP request paths This commit adds bounds checking for resolution_count when parsing SYNTHVID_RESOLUTION_RESPONSE. It degrades gracefully to default resolutions on failure, and adds reinit_completion() before VSP requests to prevent consuming stale completions. > diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_proto.c > b/drivers/gpu/drm/hyperv/hyperv_drm_proto.c > --- a/drivers/gpu/drm/hyperv/hyperv_drm_proto.c > +++ b/drivers/gpu/drm/hyperv/hyperv_drm_proto.c [ ... ] > @@ -383,6 +385,7 @@ static int hyperv_get_supported_resolution(struct > hv_device *hdev) > sizeof(struct synthvid_supported_resolution_req); > msg->resolution_req.maximum_resolution_count = > SYNTHVID_MAX_RESOLUTION_COUNT; > + reinit_completion(&hv->wait); > hyperv_sendpacket(hdev, msg); Does this reinit_completion() prevent a data race on the shared hv->init_buf? If a timed-out request's delayed response arrives while a new request is being constructed, could hyperv_receive_sub() concurrently overwrite hv->init_buf without holding any locks? Since the buffer is used for both sending and receiving, if a delayed response arrives exactly between the memset(msg, 0) and hyperv_sendpacket(hdev, msg), could msg->vid_hdr.size be overwritten by the host's response? If a host provides a crafted size, could this cause an integer overflow in totalbytes_towrite within hv_ringbuffer_write(), bypassing ring buffer free-space checks and causing an out-of-bounds read of guest memory into the VMBus ring buffer? Additionally, if the delayed response triggers complete(&hv->wait), is there a chance the driver parses a mismatched response because it does not validate that msg->vid_hdr.type matches the expected response? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
