All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Hari Mishal" <harimishal1@gmail.com>
Cc: dmitry.torokhov@gmail.com, linux-input@vger.kernel.org
Subject: Re: [PATCH 1/4] virtio-mem: validate device-reported block size
Date: Wed, 15 Jul 2026 14:43:23 +0000	[thread overview]
Message-ID: <20260715144324.579151F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260715142337.22811-2-harimishal1@gmail.com>

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

Pre-existing issues:
- [High] Missing minimum threshold check for `device_block_size` leads to silent truncation of `nb_vm_blocks` to 16 bits, causing guest memory corruption.
--

--- Patch [1]: [PATCH 1/4] virtio-mem: validate device-reported block size ---
commit 1886b5144897e316d9afb5456f7874735bcb4c19
Author: Hari Mishal <harimishal1@gmail.com>

virtio-mem: validate device-reported block size

This commit adds validation to ensure the device-reported block size is
non-zero and a power of two, preventing division by zero and miscalculated
alignments.

> diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
> index 11c4415015829..43d12ec7c3230 100644
> --- a/drivers/virtio/virtio_mem.c
> +++ b/drivers/virtio/virtio_mem.c
> @@ -2847,6 +2847,13 @@ static int virtio_mem_init(struct virtio_mem *vm)
>  			&vm->plugged_size);
>  	virtio_cread_le(vm->vdev, struct virtio_mem_config, block_size,
>  			&vm->device_block_size);
> +	if (!vm->device_block_size ||
> +	    !is_power_of_2(vm->device_block_size)) {
> +		dev_err(&vm->vdev->dev,
> +			"invalid device block size: 0x%llx\n",
> +			(unsigned long long)vm->device_block_size);
> +		return -EINVAL;
> +	}

[Severity: High]
This is a pre-existing issue, but does this validation also need to enforce
a minimum threshold for device_block_size?

If a small power-of-two value like 16 or 32 is provided by the device, the
calculated block count can easily exceed 65535.

For example, a minimum sub-block size of 2MB divided by 16 yields 131,072
blocks. When this is passed to virtio_mem_send_plug_request(), the value is
silently truncated to 16 bits:

drivers/virtio/virtio_mem.c:virtio_mem_send_plug_request() {
    ...
    .u.plug.nb_blocks = cpu_to_virtio16(vm->vdev, nb_vm_blocks),
    ...
}

This truncation also happens in virtio_mem_send_unplug_request() and
virtio_mem_send_state_request() via the .u.unplug.nb_blocks and
.u.state.nb_blocks assignments.

Could this lead to the host processing a truncated request (e.g., plugging 0
blocks) while the guest kernel proceeds to add the full memory region,
causing a crash when the unbacked memory is accessed?

>  	virtio_cread_le(vm->vdev, struct virtio_mem_config, node_id,
>  			&node_id);
>  	vm->nid = virtio_mem_translate_node_id(vm, node_id);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260715142337.22811-1-harimishal1@gmail.com?part=1

  reply	other threads:[~2026-07-15 14:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-15 14:22 [PATCH 0/4] virtio: validate device-reported values across drivers Hari Mishal
2026-07-15 14:22 ` [PATCH 1/4] virtio-mem: validate device-reported block size Hari Mishal
2026-07-15 14:43   ` sashiko-bot [this message]
2026-07-15 15:57   ` Michael S. Tsirkin
2026-07-15 16:41   ` [PATCH v2 " Hari Mishal
2026-07-15 14:22 ` [PATCH 2/4] virtio_input: validate device-reported multitouch slot count Hari Mishal
2026-07-15 14:35   ` sashiko-bot
2026-07-15 15:50   ` Michael S. Tsirkin
2026-07-15 16:07     ` Hari Mishal
2026-07-15 16:11       ` Michael S. Tsirkin
2026-07-15 16:41   ` [PATCH v2 " Hari Mishal
2026-07-15 14:22 ` [PATCH 3/4] virtio_console: avoid NULL portdev dereference in in_intr() Hari Mishal
2026-07-15 14:37   ` sashiko-bot
2026-07-15 14:22 ` [PATCH 4/4] virtio_console: take a kref in find_port_by_vq() to fix port UAF Hari Mishal
2026-07-15 14:38   ` sashiko-bot
2026-07-15 14:42   ` [PATCH v2 " Hari Mishal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260715144324.579151F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=harimishal1@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.