PT-2026-64758 · Linux · Linux

CVE-2026-64527

·

Published

2026-07-25

·

Updated

2026-07-25

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
drm/hyperv: validate VMBus packet size in receive callback
hyperv receive sub() reads msg->vid hdr.type and dispatches into one of four message-type branches without knowing how many bytes the host wrote into hv->recv buf. The completion path then runs memcpy(hv->init buf, msg, VMBUS MAX PACKET SIZE), so the consumer that wakes on wait for completion timeout() can read up to 16 KiB of residue from a prior message as if it were the response payload.
Pass bytes recvd into hyperv receive sub() and reject any packet that does not cover the pipe + synthvid header. A single switch on msg->vid hdr.type then computes the type-specific payload size: the three completion-driving types (SYNTHVID VERSION RESPONSE, SYNTHVID RESOLUTION RESPONSE, SYNTHVID VRAM LOCATION ACK) fall through to a shared exit that requires that size before memcpy/complete, while SYNTHVID FEATURE CHANGE validates its own payload and returns before reading is dirt needed. Unknown types are dropped.
SYNTHVID RESOLUTION RESPONSE is variable length: the host fills resolution count entries, not the full SYNTHVID MAX RESOLUTION COUNT array. Validate the fixed prefix first so resolution count can be read, bound it against the array, then require only the count-sized array, so the shorter responses the host actually sends are accepted.
Only run the sub-handler when vmbus recvpacket() returned success. The memcpy length is bytes recvd, which is bounded by VMBUS MAX PACKET SIZE only on a successful receive; on -ENOBUFS vmbus recvpacket() instead reports the required length, which can exceed hv->recv buf, so copying bytes recvd would read and write past the 16 KiB buffers. Gating on the success return keeps the copy bounded. The nonzero-return path is itself a malformed-message case and is now logged rather than silently skipped; channel recovery is not attempted.
Rejected packets are reported via drm err ratelimited() rather than silently dropped, matching the CoCo-hardened pattern in hv kvp onchannelcallback().
Found an issue in the description? Have something to add? Feel free to write us 👾

Related Identifiers

CVE-2026-64527

Affected Products

Linux