[PATCH] KVM: coalesced_mmio: Fix out-of-bounds write in coalesced_mmio_write()

[PATCH] KVM: coalesced_mmio: Fix out-of-bounds write in coalesced_mmio_write()

[redacherkaoui]

From: redahack12-glitch <redahack12@gmail.com>

The coalesced MMIO ring stores each entry's MMIO payload in an 8-byte
fixed-size buffer (data[8]). However, coalesced_mmio_write() copies
the payload using memcpy(..., len) without verifying that 'len' does not
exceed the buffer size.

A malicious or buggy caller could therefore trigger a write past the end
of the data[] array and corrupt adjacent kernel memory inside the ring
page.

Add a bounds check to reject writes where len > sizeof(data).

Signed-off-by: REDA CHERKAOUI <redacherkaoui67@gmail.com>
---
 virt/kvm/coalesced_mmio.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/virt/kvm/coalesced_mmio.c b/virt/kvm/coalesced_mmio.c
index 375d6285475e..4f302713de9e 100644
--- a/virt/kvm/coalesced_mmio.c
+++ b/virt/kvm/coalesced_mmio.c
@@ -68,6 +68,14 @@ static int coalesced_mmio_write(struct kvm_vcpu *vcpu,
 
 	/* copy data in first free entry of the ring */
 
+	/* Prevent overflow of the fixed 8-byte data[] field */
+	if (len > sizeof(ring->coalesced_mmio[insert].data)) {
+		spin_unlock(&dev->kvm->ring_lock);
+		pr_warn_ratelimited("KVM: coalesced MMIO write too large (%d > %zu)\n",
+				    len, sizeof(ring->coalesced_mmio[insert].data));
+		return -E2BIG;
+	}
+
 	ring->coalesced_mmio[insert].phys_addr = addr;
 	ring->coalesced_mmio[insert].len = len;
 	memcpy(ring->coalesced_mmio[insert].data, val, len);
-- 
2.43.0

Re: [PATCH] KVM: coalesced_mmio: Fix out-of-bounds write in coalesced_mmio_write()

[Sean Christopherson]

On Thu, Nov 27, 2025, redacherkaoui wrote:
> From: redahack12-glitch <redahack12@gmail.com>
> 
> The coalesced MMIO ring stores each entry's MMIO payload in an 8-byte
> fixed-size buffer (data[8]). However, coalesced_mmio_write() copies
> the payload using memcpy(..., len) without verifying that 'len' does not
> exceed the buffer size.
> 
> A malicious

KVM controls all callers.

> or buggy caller could therefore trigger a write past the end of the data[]
> array and corrupt adjacent kernel memory inside the ring page.

True, but if a caller is buggy, KVM likely has bigger problems because KVM relies
on MMIO (and PIO) accesses being no larger than 8 in a number of locations.  If
we want to harden KVM, kvm_iodevice_{read,write}() would be a better place for a
sanity check.