* Re:Re: [PATCH 01/12] vhost-scsi: improve BIDI operation comments
From: xiongwm2026 @ 2026-07-15 9:36 UTC (permalink / raw)
To: Bobby Eshleman; +Cc: virtualization
In-Reply-To: <aldR5cNr3SlVoBX/@devvm29614.prn0.facebook.com>
Hi Bobby,
Thanks for the feedback.
Understood. I will drop this comment-only change and focus on fixes with
a concrete bug scenario or reproducer.
Best,
Weimin
At 2026-07-15 17:24:53, "Bobby Eshleman" <bobbyeshleman@gmail.com> wrote:
>On Wed, Jul 15, 2026 at 04:09:06PM +0800, Weimin Xiong wrote:
>> From: xiongweimin <xiongwm2026@163.com>
>>
>> Replace FIXME comments with clearer Note comments documenting
>> that BIDI (bidirectional) operations are not yet supported.
>>
>> Signed-off-by: Weimin Xiong <xiongwm2026@163.com>
>> Co-authored-by: Cursor <cursoragent@cursor.com>
>> ---
>> drivers/vhost/scsi.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
>> index 9a1253b9d..81e905c4c 100644
>> --- a/drivers/vhost/scsi.c
>> +++ b/drivers/vhost/scsi.c
>> @@ -1047,7 +1047,7 @@ static void vhost_scsi_target_queue_cmd(struct vhost_scsi_nexus *nexus,
>> struct se_cmd *se_cmd = &cmd->tvc_se_cmd;
>> struct scatterlist *sg_ptr, *sg_prot_ptr = NULL;
>>
>> - /* FIXME: BIDI operation */
>> + /* Note: BIDI (bidirectional) operations are not yet supported */
>> if (cmd->tvc_sgl_count) {
>> sg_ptr = cmd->table.sgl;
>>
>> @@ -1168,7 +1168,7 @@ vhost_scsi_get_desc(struct vhost_scsi *vs, struct vhost_virtqueue *vq,
>>
>> /*
>> * Get the size of request and response buffers.
>> - * FIXME: Not correct for BIDI operation
>> + * Note: Size calculation is not correct for BIDI operations.
>> */
>> vc->out_size = iov_length(vq->iov, vc->out);
>> vc->in_size = iov_length(&vq->iov[vc->out], vc->in);
>> --
>> 2.43.0
>>
>
>Hey Weimin,
>
>This series is probably going to be ignored. Comment-only changes are
>almost never merged, and the code changes here don't look like genuine
>bugs.
>
>In the case that there are some real bugs, I'd recommend to setup a
>system and trigger a bug, and provide a reproducer.
>
>Best,
>Bobby
^ permalink raw reply
* Re: [PATCH v2 2/3] drm/virtio: honor blob_alignment requirements
From: Alyssa Ross @ 2026-07-15 10:13 UTC (permalink / raw)
To: Dmitry Osipenko, Sergio Lopez, Yiwei Zhang, Sergi Blanch Torne,
Valentine Burley
Cc: Chia-I Wu, Jason Wang, Michael S. Tsirkin, Eugenio Pérez,
Xuan Zhuo, linux-kernel, Simona Vetter, Thomas Zimmermann,
David Airlie, Gurchetan Singh, Gerd Hoffmann, virtualization,
dri-devel, Maxime Ripard, Maarten Lankhorst
In-Reply-To: <17764937-21dc-4b4a-8def-e738b361bcd1@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 2444 bytes --]
Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
> On 7/13/26 14:19, Alyssa Ross wrote:
>> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
>>
>>> On 7/1/26 14:10, Alyssa Ross wrote:
>>>> On Tue, Apr 28, 2026 at 09:44:49PM +0200, Sergio Lopez wrote:
>>>>> If VIRTIO_GPU_F_BLOB_ALIGNMENT has been negotiated, blob size must be
>>>>> aligned to blob_alignment. Validate this in verify_blob() so that
>>>>> invalid requests are rejected early.
>>>>>
>>>>> Signed-off-by: Sergio Lopez <slp@redhat.com>
>>>>
>>>> FYI: this change breaks crosvm, which is squatting the 5 and 6 values
>>>> of VIRTIO_GPU_F_* with different meanings. I've reported it as a
>>>> crosvm bug, so hopefully it can be taken care of there.
>>>>
>>>> https://issuetracker.google.com/issues/529852979
>>>>
>>>>> ---
>>>>> drivers/gpu/drm/virtio/virtgpu_ioctl.c | 5 +++++
>>>>> 1 file changed, 5 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
>>>>> index c33c057365f8..d0c4edf1eaf4 100644
>>>>> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
>>>>> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
>>>>> @@ -489,6 +489,11 @@ static int verify_blob(struct virtio_gpu_device *vgdev,
>>>>> params->size = rc_blob->size;
>>>>> params->blob = true;
>>>>> params->blob_flags = rc_blob->blob_flags;
>>>>> +
>>>>> + if (vgdev->has_blob_alignment &&
>>>>> + !IS_ALIGNED(params->size, vgdev->blob_alignment))
>>>>> + return -EINVAL;
>>>>> +
>>>>> return 0;
>>>>> }
>>>>>
>>>>> --
>>>>> 2.53.0
>>>>>
>>>
>>> Thanks for the report. Indeed, crosvm will need to fix its experimental
>>> caps. CI will likely run into this problem first once it will update
>>> guest to 7.2+ kernel.
>>
>> I sent
>> https://chromium-review.googlesource.com/c/crosvm/crosvm/+/8064741 last
>> week but still waiting to hear anything. Do you have any insight into
>> whether it's still used / being pursued?
>
> The GUEST_HANDLE should be used by Android [1]. The FENCE_PASSING
> shouldn't be used in production, though don't know for sure.
>
> Crosvm should bump its experimental defines by +10 to prevent clash with
> upstream in future.
>
> [1]
> https://github.com/google/gfxstream/blob/main/host/vulkan/vk_decoder_global_state.cpp#L107
Thanks for the extra info. :) They've agreed to go ahead and remove both
of them, so the problem is solved.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: [PATCH v1 2/2] iommu/virtio: Handle iommu_device_register() failures
From: Will Deacon @ 2026-07-15 11:46 UTC (permalink / raw)
To: weimin xiong
Cc: Jean-Philippe Brucker, Joerg Roedel, Robin Murphy, virtualization,
iommu, linux-kernel, Xiong Weimin
In-Reply-To: <20260714024949.190014-3-15927021679@163.com>
On Tue, Jul 14, 2026 at 10:49:49AM +0800, weimin xiong wrote:
> From: Xiong Weimin <xiongweimin@kylinos.cn>
>
> iommu_device_register() returns an error when the IOMMU core fails to
> register the hardware instance or probe the buses. viommu_probe()
> currently ignores that error and continues as if the device was
> registered successfully.
>
> Propagate the failure and unwind the sysfs entry and virtqueues that
> were set up earlier. Clear the driver data on the error path as well,
> since it is set before registration so bus probing can find the
> virtio-IOMMU instance.
>
> Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
> ---
> drivers/iommu/virtio-iommu.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
> index 342785c76..9118377d7 100644
> --- a/drivers/iommu/virtio-iommu.c
> +++ b/drivers/iommu/virtio-iommu.c
> @@ -1240,7 +1240,9 @@ static int viommu_probe(struct virtio_device *vdev)
>
> vdev->priv = viommu;
>
> - iommu_device_register(&viommu->iommu, &viommu_ops, parent_dev);
> + ret = iommu_device_register(&viommu->iommu, &viommu_ops, parent_dev);
> + if (ret)
> + goto err_remove_sysfs;
Given that the first patch shouldn't be needed (per Robin's comments at
[1]) and this is augmented an error path that we shouldn't be hitting in
practice, I don't think we need to treat this as a fix. You can probably
just lump it in with your virtio-iommu hardening series.
Will
^ permalink raw reply
* [PATCH 0/4] virtio: validate device-reported values across drivers
From: Hari Mishal @ 2026-07-15 14:22 UTC (permalink / raw)
To: Amit Shah, Arnd Bergmann, Greg Kroah-Hartman, Gerd Hoffmann,
Michael S . Tsirkin, Jason Wang, David Hildenbrand,
Henrik Rydberg
Cc: Xuan Zhuo, Eugenio Pérez, virtualization, linux-kernel,
linux-input, Hari Mishal
These four patches harden virtio-mem, virtio_input, and virtio_console
against untrusted values coming from the device/backend side of the virtio
interface. The fourth fixes a use-after-free in virtio_console caused by a
missing refcount.
Hari Mishal (4):
virtio-mem: validate device-reported block size
virtio_input: validate device-reported multitouch slot count
virtio_console: avoid NULL portdev dereference in in_intr()
virtio_console: take a kref in find_port_by_vq() to fix port UAF
drivers/char/virtio_console.c | 18 +++++++++++++++++-
drivers/virtio/virtio_input.c | 4 ++++
drivers/virtio/virtio_mem.c | 7 +++++++
3 files changed, 28 insertions(+), 1 deletion(-)
--
2.43.0
^ permalink raw reply
* [PATCH 1/4] virtio-mem: validate device-reported block size
From: Hari Mishal @ 2026-07-15 14:22 UTC (permalink / raw)
To: Amit Shah, Arnd Bergmann, Greg Kroah-Hartman, Gerd Hoffmann,
Michael S . Tsirkin, Jason Wang, David Hildenbrand,
Henrik Rydberg
Cc: Xuan Zhuo, Eugenio Pérez, virtualization, linux-kernel,
linux-input, Hari Mishal
In-Reply-To: <20260715142337.22811-1-harimishal1@gmail.com>
The device_block_size read from the virtio-mem config space is used
as a divisor and also in ALIGN_DOWN() further down the code path in
the driver without further validation. A zero value leads to a division
by zero, and a non-power-of-two value corrupts the ALIGN_DOWN() bitmask
arithmetic leading to a misreporting of guest usable guest ram, post
crash. Reject both at init time instead of trusting the device.
Assisted-by: gkh_clanker:t1000
Signed-off-by: Hari Mishal <harimishal1@gmail.com>
---
drivers/virtio/virtio_mem.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index 11c441501582..43d12ec7c323 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;
+ }
virtio_cread_le(vm->vdev, struct virtio_mem_config, node_id,
&node_id);
vm->nid = virtio_mem_translate_node_id(vm, node_id);
--
2.43.0
^ permalink raw reply related
* [PATCH 2/4] virtio_input: validate device-reported multitouch slot count
From: Hari Mishal @ 2026-07-15 14:22 UTC (permalink / raw)
To: Amit Shah, Arnd Bergmann, Greg Kroah-Hartman, Gerd Hoffmann,
Michael S . Tsirkin, Jason Wang, David Hildenbrand,
Henrik Rydberg
Cc: Xuan Zhuo, Eugenio Pérez, virtualization, linux-kernel,
linux-input, Hari Mishal
In-Reply-To: <20260715142337.22811-1-harimishal1@gmail.com>
nslots is derived from the ABS_MT_SLOT maximum reported by the
virtio device. A device could report a bogus maximum (e.g. -1)
making nslots = 0, which input_mt_init_slots() does not reject;
it returns success without allocating any slot storage, silently
leaving the device registered as multitouch capable with no
backing state. Reject non-positive slot counts before calling
input_mt_init_slots().
Assisted-by: gkh_clanker:t1000
Signed-off-by: Hari Mishal <harimishal1@gmail.com>
---
drivers/virtio/virtio_input.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/virtio/virtio_input.c b/drivers/virtio/virtio_input.c
index deec24e8e682..2cc19782cdd3 100644
--- a/drivers/virtio/virtio_input.c
+++ b/drivers/virtio/virtio_input.c
@@ -312,6 +312,10 @@ static int virtinput_probe(struct virtio_device *vdev)
if (test_bit(ABS_MT_SLOT, vi->idev->absbit)) {
nslots = input_abs_get_max(vi->idev, ABS_MT_SLOT) + 1;
+ if (nslots <= 0) {
+ err = -EINVAL;
+ goto err_mt_init_slots;
+ }
err = input_mt_init_slots(vi->idev, nslots, 0);
if (err)
goto err_mt_init_slots;
--
2.43.0
^ permalink raw reply related
* [PATCH 3/4] virtio_console: avoid NULL portdev dereference in in_intr()
From: Hari Mishal @ 2026-07-15 14:22 UTC (permalink / raw)
To: Amit Shah, Arnd Bergmann, Greg Kroah-Hartman, Gerd Hoffmann,
Michael S . Tsirkin, Jason Wang, David Hildenbrand,
Henrik Rydberg
Cc: Xuan Zhuo, Eugenio Pérez, virtualization, linux-kernel,
linux-input, Hari Mishal
In-Reply-To: <20260715142337.22811-1-harimishal1@gmail.com>
A port's virtqueue is not torn down immediately if the port itself is
hot-unplugged (unplug_port() only nulls port->portdev; the vq
callback stays registered until the whole device is removed).
If in_intr() fires for a port in that window it dereferences
port->portdev->vdev via is_rproc_serial(), crashing on the NULL
portdev.
Bail out early when portdev has already been cleared.
Assisted-by: gkh_clanker:t1000
Signed-off-by: Hari Mishal <harimishal1@gmail.com>
---
drivers/char/virtio_console.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 198b97314168..faef362dae85 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -1720,6 +1720,11 @@ static void in_intr(struct virtqueue *vq)
}
spin_lock_irqsave(&port->inbuf_lock, flags);
+ if (!port->portdev) {
+ /* Port is being unplugged, ignore further data. */
+ spin_unlock_irqrestore(&port->inbuf_lock, flags);
+ return;
+ }
port->inbuf = get_inbuf(port);
/*
--
2.43.0
^ permalink raw reply related
* [PATCH 4/4] virtio_console: take a kref in find_port_by_vq() to fix port UAF
From: Hari Mishal @ 2026-07-15 14:22 UTC (permalink / raw)
To: Amit Shah, Arnd Bergmann, Greg Kroah-Hartman, Gerd Hoffmann,
Michael S . Tsirkin, Jason Wang, David Hildenbrand,
Henrik Rydberg
Cc: Xuan Zhuo, Eugenio Pérez, virtualization, linux-kernel,
linux-input, Hari Mishal
In-Reply-To: <20260715142337.22811-1-harimishal1@gmail.com>
find_port_by_vq() returns a raw struct port pointer without taking a
reference on it, unlike find_port_by_devt_in_portdev() which does.
find_port_by_vq()'s only two callers, in_intr() and out_intr(), run
as virtqueue interrupt callbacks, entirely independent of and
possibly concurrently with unplug_port(), which itself runs from a
workqueue when the host sends a VIRTIO_CONSOLE_PORT_REMOVE control
message.
unplug_port() removes the port from portdev->ports under ports_lock,
then later drops its last reference with kref_put(), freeing it via
remove_port(). find_port_by_vq() also walks portdev->ports under
ports_lock, so if it finds the port still on the list, the list
removal, and therefore the eventual kref_put(), has not happened yet,
and taking a reference at that point is always safe. Without doing
so, in_intr()/out_intr() can be left holding a pointer to a port that
unplug_port() frees on another core before they are done using it.
Both triggers are host-controlled as the host decides when to send the
PORT_REMOVE control message and when to kick the port's data vq. So a
malicious backend could race the two on purpose, without any guest side
cooperation. The freed object is a generic kmalloc allocation containing
a wait_queue_head_t, which in_intr()/out_intr() pass to
wake_up_interruptible() after touching the stale pointer.
wake_up_interruptible() invokes a function pointer read out of the
wait queue's entries. If the freed slab slot is reclaimed with
attacker influenced content before that call, then this is an arbitrary
function call primitive rather than just undefined behaviour.
Take a reference in find_port_by_vq() while still holding ports_lock,
matching find_port_by_devt_in_portdev(), and release it in in_intr()
and out_intr() once they are done with the port.
Signed-off-by: Hari Mishal <harimishal1@gmail.com>
---
drivers/char/virtio_console.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index faef362dae85..1b7593684ed9 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -304,6 +304,11 @@ static struct port *find_port_by_id(struct ports_device *portdev, u32 id)
return port;
}
+/*
+ * The port object's reference is incremented now and
+ * it is the caller's responsibility to decrement it
+ */
+
static struct port *find_port_by_vq(struct ports_device *portdev,
struct virtqueue *vq)
{
@@ -312,8 +317,10 @@ static struct port *find_port_by_vq(struct ports_device *portdev,
spin_lock_irqsave(&portdev->ports_lock, flags);
list_for_each_entry(port, &portdev->ports, list)
- if (port->in_vq == vq || port->out_vq == vq)
+ if (port->in_vq == vq || port->out_vq == vq) {
+ kref_get(&port->kref);
goto out;
+ }
port = NULL;
out:
spin_unlock_irqrestore(&portdev->ports_lock, flags);
@@ -1706,6 +1713,7 @@ static void out_intr(struct virtqueue *vq)
}
wake_up_interruptible(&port->waitqueue);
+ kref_put(&port->kref, remove_port);
}
static void in_intr(struct virtqueue *vq)
@@ -1723,6 +1731,7 @@ static void in_intr(struct virtqueue *vq)
if (!port->portdev) {
/* Port is being unplugged, ignore further data. */
spin_unlock_irqrestore(&port->inbuf_lock, flags);
+ kref_put(&port->kref, remove_port);
return;
}
port->inbuf = get_inbuf(port);
@@ -1756,6 +1765,8 @@ static void in_intr(struct virtqueue *vq)
if (is_console_port(port) && hvc_poll(port->cons.hvc))
hvc_kick();
+
+ kref_put(&port->kref, remove_port);
}
static void control_intr(struct virtqueue *vq)
--
2.43.0
^ permalink raw reply related
* [PATCH v2 4/4] virtio_console: take a kref in find_port_by_vq() to fix port UAF
From: Hari Mishal @ 2026-07-15 14:42 UTC (permalink / raw)
To: Amit Shah, Arnd Bergmann, Greg Kroah-Hartman
Cc: virtualization, linux-kernel, Hari Mishal
In-Reply-To: <20260715142337.22811-5-harimishal1@gmail.com>
find_port_by_vq() returns a raw struct port pointer without taking a
reference on it, unlike find_port_by_devt_in_portdev() which does.
find_port_by_vq()'s only two callers, in_intr() and out_intr(), run as
virtqueue interrupt callbacks, entirely independent of and possibly
concurrently with unplug_port(), which itself runs from a workqueue when
the host sends a VIRTIO_CONSOLE_PORT_REMOVE control message.
unplug_port() removes the port from portdev->ports under ports_lock,
then later drops its last reference with kref_put(), freeing it via
remove_port(). find_port_by_vq() also walks portdev->ports under
ports_lock, so if it finds the port still on the list, the list removal,
and therefore the eventual kref_put(), has not happened yet, and taking
a reference at that point is always safe. Without doing so,
in_intr()/out_intr() can be left holding a pointer to a port that
unplug_port() frees on another core before they are done using it.
Both triggers are host-controlled as the host decides when to send the
PORT_REMOVE control message and when to kick the port's data vq. So a
malicious backend could race the two on purpose, without any guest side
cooperation. The freed object is a generic kmalloc allocation containing
a wait_queue_head_t, which in_intr()/out_intr() pass to
wake_up_interruptible() after touching the stale pointer.
wake_up_interruptible() invokes a function pointer read out of the wait
queue's entries. If the freed slab slot is reclaimed with attacker
influenced content before that call, then this is an arbitrary function
call primitive rather than just undefined behaviour.
Take a reference in find_port_by_vq() while still holding ports_lock,
matching find_port_by_devt_in_portdev(), and release it in in_intr() and
out_intr() once they are done with the port.
Signed-off-by: Hari Mishal <harimishal1@gmail.com>
---
v2: reworded the comment above find_port_by_vq() for clarity, no
functional change since v1.
drivers/char/virtio_console.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index faef362dae85..1b63afe24e29 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -304,6 +304,12 @@ static struct port *find_port_by_id(struct ports_device *portdev, u32 id)
return port;
}
+/*
+ * Finds a port by the virtqueue and returns a pointer to struct port
+ * with the reference count incremented.
+ *
+ * Callers MUST decrement it when finished.
+ */
static struct port *find_port_by_vq(struct ports_device *portdev,
struct virtqueue *vq)
{
@@ -312,8 +318,10 @@ static struct port *find_port_by_vq(struct ports_device *portdev,
spin_lock_irqsave(&portdev->ports_lock, flags);
list_for_each_entry(port, &portdev->ports, list)
- if (port->in_vq == vq || port->out_vq == vq)
+ if (port->in_vq == vq || port->out_vq == vq) {
+ kref_get(&port->kref);
goto out;
+ }
port = NULL;
out:
spin_unlock_irqrestore(&portdev->ports_lock, flags);
@@ -1706,6 +1714,7 @@ static void out_intr(struct virtqueue *vq)
}
wake_up_interruptible(&port->waitqueue);
+ kref_put(&port->kref, remove_port);
}
static void in_intr(struct virtqueue *vq)
@@ -1723,6 +1732,7 @@ static void in_intr(struct virtqueue *vq)
if (!port->portdev) {
/* Port is being unplugged, ignore further data. */
spin_unlock_irqrestore(&port->inbuf_lock, flags);
+ kref_put(&port->kref, remove_port);
return;
}
port->inbuf = get_inbuf(port);
@@ -1756,6 +1766,8 @@ static void in_intr(struct virtqueue *vq)
if (is_console_port(port) && hvc_poll(port->cons.hvc))
hvc_kick();
+
+ kref_put(&port->kref, remove_port);
}
static void control_intr(struct virtqueue *vq)
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 2/4] virtio_input: validate device-reported multitouch slot count
From: Michael S. Tsirkin @ 2026-07-15 15:50 UTC (permalink / raw)
To: Hari Mishal
Cc: Amit Shah, Arnd Bergmann, Greg Kroah-Hartman, Gerd Hoffmann,
Jason Wang, David Hildenbrand, Henrik Rydberg, Xuan Zhuo,
Eugenio Pérez, virtualization, linux-kernel, linux-input
In-Reply-To: <20260715142337.22811-3-harimishal1@gmail.com>
On Wed, Jul 15, 2026 at 04:22:41PM +0200, Hari Mishal wrote:
> nslots is derived from the ABS_MT_SLOT maximum reported by the
> virtio device. A device could report a bogus maximum (e.g. -1)
> making nslots = 0, which input_mt_init_slots() does not reject;
> it returns success without allocating any slot storage, silently
> leaving the device registered as multitouch capable with no
> backing state.
So let's disable multitouch instead?
> Reject non-positive slot counts before calling
> input_mt_init_slots().
>
> Assisted-by: gkh_clanker:t1000
> Signed-off-by: Hari Mishal <harimishal1@gmail.com>
> ---
> drivers/virtio/virtio_input.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/virtio/virtio_input.c b/drivers/virtio/virtio_input.c
> index deec24e8e682..2cc19782cdd3 100644
> --- a/drivers/virtio/virtio_input.c
> +++ b/drivers/virtio/virtio_input.c
> @@ -312,6 +312,10 @@ static int virtinput_probe(struct virtio_device *vdev)
>
> if (test_bit(ABS_MT_SLOT, vi->idev->absbit)) {
> nslots = input_abs_get_max(vi->idev, ABS_MT_SLOT) + 1;
> + if (nslots <= 0) {
> + err = -EINVAL;
> + goto err_mt_init_slots;
> + }
> err = input_mt_init_slots(vi->idev, nslots, 0);
> if (err)
> goto err_mt_init_slots;
> --
> 2.43.0
^ permalink raw reply
* Re: [PATCH 1/4] virtio-mem: validate device-reported block size
From: Michael S. Tsirkin @ 2026-07-15 15:57 UTC (permalink / raw)
To: Hari Mishal
Cc: Amit Shah, Arnd Bergmann, Greg Kroah-Hartman, Gerd Hoffmann,
Jason Wang, David Hildenbrand, Henrik Rydberg, Xuan Zhuo,
Eugenio Pérez, virtualization, linux-kernel, linux-input
In-Reply-To: <20260715142337.22811-2-harimishal1@gmail.com>
On Wed, Jul 15, 2026 at 04:22:40PM +0200, Hari Mishal wrote:
> The device_block_size read from the virtio-mem config space is used
> as a divisor and also in ALIGN_DOWN() further down the code path in
> the driver without further validation. A zero value leads to a division
> by zero, and a non-power-of-two value corrupts the ALIGN_DOWN() bitmask
> arithmetic leading to a misreporting of guest usable guest ram, post
> crash. Reject both at init time instead of trusting the device.
>
> Assisted-by: gkh_clanker:t1000
> Signed-off-by: Hari Mishal <harimishal1@gmail.com>
> ---
> drivers/virtio/virtio_mem.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
> index 11c441501582..43d12ec7c323 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)) {
0 is not a power of 2, why do we need to check twice?
> + dev_err(&vm->vdev->dev,
> + "invalid device block size: 0x%llx\n",
> + (unsigned long long)vm->device_block_size);
> + return -EINVAL;
> + }
> virtio_cread_le(vm->vdev, struct virtio_mem_config, node_id,
> &node_id);
> vm->nid = virtio_mem_translate_node_id(vm, node_id);
> --
> 2.43.0
^ permalink raw reply
* Re: [PATCH 2/4] virtio_input: validate device-reported multitouch slot count
From: Hari Mishal @ 2026-07-15 16:07 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Amit Shah, Arnd Bergmann, Greg Kroah-Hartman, Gerd Hoffmann,
Jason Wang, David Hildenbrand, Henrik Rydberg, Xuan Zhuo,
Eugenio Pérez, virtualization, linux-kernel, linux-input
In-Reply-To: <20260715115018-mutt-send-email-mst@kernel.org>
On Wed, Jul 15, 2026 at 5:50 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Wed, Jul 15, 2026 at 04:22:41PM +0200, Hari Mishal wrote:
> > nslots is derived from the ABS_MT_SLOT maximum reported by the
> > virtio device. A device could report a bogus maximum (e.g. -1)
> > making nslots = 0, which input_mt_init_slots() does not reject;
> > it returns success without allocating any slot storage, silently
> > leaving the device registered as multitouch capable with no
> > backing state.
>
> So let's disable multitouch instead?
>
So rather than failing the whole probe, just warn and clear
ABS_MT_SLOT from absbit in that case, so the rest of the device
still registers? I took my lead from input_mt_init_slots(), which
has its own internal cap and returns -EINVAL when the device
reports more than 1024 slots.
Shall I modify that case to get the same "warn and disable
multitouch" for consistency, or is a hard failure better there since
it's a different type of bad device data?
Happy to fix it either way! Just want to confirm before sending V2.
Cheers,
Hari
^ permalink raw reply
* Re: [PATCH 2/4] virtio_input: validate device-reported multitouch slot count
From: Michael S. Tsirkin @ 2026-07-15 16:11 UTC (permalink / raw)
To: Hari Mishal
Cc: Amit Shah, Arnd Bergmann, Greg Kroah-Hartman, Gerd Hoffmann,
Jason Wang, David Hildenbrand, Henrik Rydberg, Xuan Zhuo,
Eugenio Pérez, virtualization, linux-kernel, linux-input
In-Reply-To: <CAMmC+=AnE-p7B=DbBPYeNzJdcdiBf7q=5bfcuV0VQrPRK+pmug@mail.gmail.com>
On Wed, Jul 15, 2026 at 06:07:56PM +0200, Hari Mishal wrote:
> On Wed, Jul 15, 2026 at 5:50 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Wed, Jul 15, 2026 at 04:22:41PM +0200, Hari Mishal wrote:
> > > nslots is derived from the ABS_MT_SLOT maximum reported by the
> > > virtio device. A device could report a bogus maximum (e.g. -1)
> > > making nslots = 0, which input_mt_init_slots() does not reject;
> > > it returns success without allocating any slot storage, silently
> > > leaving the device registered as multitouch capable with no
> > > backing state.
> >
> > So let's disable multitouch instead?
> >
>
> So rather than failing the whole probe, just warn and clear
> ABS_MT_SLOT from absbit in that case, so the rest of the device
> still registers? I took my lead from input_mt_init_slots(), which
> has its own internal cap and returns -EINVAL when the device
> reports more than 1024 slots.
> Shall I modify that case to get the same "warn and disable
> multitouch" for consistency, or is a hard failure better there since
> it's a different type of bad device data?
I don't really know enough for sure but generally if the device can
kinda work it's better than not working, and adding
a capability to a device that driver can't use should
generally just ignore the capability, not fail probe.
> Happy to fix it either way! Just want to confirm before sending V2.
>
> Cheers,
> Hari
^ permalink raw reply
* [PATCH v2 1/4] virtio-mem: validate device-reported block size
From: Hari Mishal @ 2026-07-15 16:41 UTC (permalink / raw)
To: David Hildenbrand, Michael S . Tsirkin, Jason Wang
Cc: Greg Kroah-Hartman, Xuan Zhuo, Eugenio Pérez, virtualization,
linux-kernel, Hari Mishal
In-Reply-To: <20260715142337.22811-2-harimishal1@gmail.com>
The device_block_size read from the virtio-mem config space is used as a
divisor and also in ALIGN_DOWN() further down the code path in the
driver without further validation. A zero value leads to a division by
zero, and a non-power-of-two value corrupts the ALIGN_DOWN() bitmask
arithmetic leading to a misreporting of guest-usable ram, post crash.
Reject both at init time instead of trusting the device.
Signed-off-by: Hari Mishal <harimishal1@gmail.com>
---
v2: dropped the redundant explicit zero check, since
is_power_of_2(0) already returns false.
drivers/virtio/virtio_mem.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index 11c441501582..0e04fec458af 100644
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@ -2847,6 +2847,12 @@ 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 (!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;
+ }
virtio_cread_le(vm->vdev, struct virtio_mem_config, node_id,
&node_id);
vm->nid = virtio_mem_translate_node_id(vm, node_id);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/4] virtio_input: validate device-reported multitouch slot count
From: Hari Mishal @ 2026-07-15 16:41 UTC (permalink / raw)
To: Gerd Hoffmann, Michael S . Tsirkin, Jason Wang
Cc: Greg Kroah-Hartman, Xuan Zhuo, Eugenio Pérez, Henrik Rydberg,
virtualization, linux-kernel, linux-input, Hari Mishal
In-Reply-To: <20260715142337.22811-3-harimishal1@gmail.com>
nslots is derived from the ABS_MT_SLOT maximum reported by the virtio
device. A device could report a bogus maximum (e.g. -1) making nslots <=
0, and input_mt_init_slots() can independently fail too (e.g. it rejects
slot counts over 1024). Neither case was handled here, and
input_mt_init_slots() failing took down the whole probe, losing the rest
of the input device over a problem isolated to multitouch.
Instead of failing the probe, warn and disable the ABS_MT_SLOT
capability in either case, and let the rest of the device register
normally. This recovery assumes input_mt_init_slots() is called with
flags == 0: with nonzero flags it can fail after already mutating the
input_dev (e.g. via input_set_abs_params()), which this recovery does
not account for.
Signed-off-by: Hari Mishal <harimishal1@gmail.com>
---
v2: per review, disable multitouch instead of failing the whole
probe when the reported slot count is invalid or
input_mt_init_slots() otherwise fails.
drivers/virtio/virtio_input.c | 23 +++++++++++++++++++----
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/virtio/virtio_input.c b/drivers/virtio/virtio_input.c
index deec24e8e682..786f5150724f 100644
--- a/drivers/virtio/virtio_input.c
+++ b/drivers/virtio/virtio_input.c
@@ -312,9 +312,25 @@ static int virtinput_probe(struct virtio_device *vdev)
if (test_bit(ABS_MT_SLOT, vi->idev->absbit)) {
nslots = input_abs_get_max(vi->idev, ABS_MT_SLOT) + 1;
- err = input_mt_init_slots(vi->idev, nslots, 0);
- if (err)
- goto err_mt_init_slots;
+ if (nslots <= 0) {
+ dev_warn(&vdev->dev,
+ "invalid multitouch slot count %d, disabling multitouch\n",
+ nslots);
+ __clear_bit(ABS_MT_SLOT, vi->idev->absbit);
+ } else {
+ /*
+ * flags is 0: input_mt_init_slots() can only fail
+ * before touching *idev, so the recovery below is
+ * a full rollback.
+ */
+ err = input_mt_init_slots(vi->idev, nslots, 0);
+ if (err) {
+ dev_warn(&vdev->dev,
+ "failed to init %d multitouch slots (%d), disabling multitouch\n",
+ nslots, err);
+ __clear_bit(ABS_MT_SLOT, vi->idev->absbit);
+ }
+ }
}
}
@@ -331,7 +347,6 @@ static int virtinput_probe(struct virtio_device *vdev)
spin_lock_irqsave(&vi->lock, flags);
vi->ready = false;
spin_unlock_irqrestore(&vi->lock, flags);
-err_mt_init_slots:
input_free_device(vi->idev);
err_input_alloc:
vdev->config->del_vqs(vdev);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 00/21] gpio: Improvements around device-id arrays
From: Uwe Kleine-König (The Capable Hub) @ 2026-07-15 16:55 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski
Cc: linux-gpio, linux-kernel, Lixu Zhang, Sakari Ailus, Hans de Goede,
Andy Shevchenko, Ray Jui, Broadcom internal kernel review list,
Florian Fainelli, Scott Branden, Eugeniy Paltsev, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Imre Kaloz,
Conor Dooley, Daire McNamara, Daniel Palmer, Romain Perier,
Robert Jarzmik, imx, linux-arm-kernel, linux-riscv, Hoan Tran,
Alan Borzeszkowski, Mika Westerberg,
Enrico Weigelt, metux IT consult, Viresh Kumar, virtualization,
Yinbo Zhu, Thierry Reding, Jonathan Hunter, linux-tegra,
Geert Uytterhoeven, Joel Stanley, Andrew Jeffery, Alban Bedel,
James Cowgill, Matt Redfearn, Neil Jones, Nikolaos Pasaloukos,
Doug Berger, Keerthy, Vladimir Zapolskiy, Piotr Wojtaszczyk,
Sven Peter, Janne Grunau, Neal Gompa, Mathieu Dubois-Briand,
André Draszik, Bamvor Jian Zhang, Marek Behún,
Matthias Brugger, AngeloGioacchino Del Regno, Avi Fishman,
Tomer Maimon, Tali Perry, Patrick Venture, Nancy Yuen,
Benjamin Fair, Santosh Shilimkar, Kevin Hilman, Orson Zhai,
Baolin Wang, Chunyan Zhang, Magnus Damm, Manivannan Sadhasivam,
Heiko Stuebner, Ludovic Desroches, Paul Walmsley, Samuel Holland,
Michael Walle, Maxime Coquelin, Alexandre Torgue,
Nobuhiro Iwamatsu, Shubhrajyoti Datta, Srinivas Neeli,
Michal Simek, linux-aspeed, asahi, linux-mediatek, openbmc,
linux-omap, linux-renesas-soc, linux-unisoc, linux-rockchip,
linux-stm32, Michael Buesch, William Breathitt Gray,
Robert Richter, Andy Shevchenko, linux-acpi
Hello,
as with v1 the original motivation for this series are the patches that
convert the arrays to use named initializers, see
https://lore.kernel.org/all/cover.1780048925.git.u.kleine-koenig@baylibre.com/
for the idea behind it. Then by not closing the eyes for small issues
spotted while working on that, this series grew a bit.
Changes since v1 (available at
https://lore.kernel.org/linux-kernel/cover.1784013063.git.u.kleine-koenig@baylibre.com):
- Trivially rebase to today's next/master
- The first two patches are new. My script didn't match on device-id
arrays that are marked with __maybe_unused, so the drivers touched in
these two patches are adapted further down, too.
- Fixed capitalisation of PCI (Andy), did the same for ACPI
- Sort the ACPI device-id arrays by .id in the "unify" patch (only one
instance in gpio-dwapb.c was unsorted), suggested by Andy.
- Found a few other inconsistent device_id arrays that my script didn't
match (due to .driver_data not being a single expression or a comment
in the terminator or more than one array in a single file)
- Fixed cast expressions in drivers/gpio/gpio-mvebu.c to please
checkpatch
- Dropped the dmi MODULE_DEVICE_TABLE patch
- Added review tags from v1
Checkpatch only reports two undocumented device-tree compatibles. I felt
free to ignore these as this is a pre-existing issue and out-of-context
for this series.
Best regards
Uwe
Uwe Kleine-König (The Capable Hub) (21):
gpio: Remove __maybe_unused annotations from acpi_device_id arrays
gpio: fxl6408: Remove __maybe_unused annotations from of_device_id
array
gpio: Drop unused assignment of acpi_device_id driver data
gpio: max7301: Drop unused assignment of spi_device_id driver data
gpio: mmio: Drop unused assignment of platform_device_id driver data
gpio: ljca: Drop unused assignment of auxiliary_device_id driver data
gpio: Add missing ACPI module annotations
gpio: sodaville: Add missing PCI module annotations
gpio: Add missing OF module annotations
gpio: pxa: Add missing platform module annotations
gpio: pl061: Use empty initializer for amba_id terminator
gpio: Use named initializers for acpi_device_id array
gpio: Use named initializers for spi_device_id array
gpio: virtio: Use a named initializer for virtio_device_id array
gpio: pcf857x: Use named initializers for of_device_id array
gpio: Unify style of acpi_device_id arrays
gpio: Unify style of of_device_id arrays
gpio: max77620: Unify style of platform_device_id arrays
gpio: Unify style of spi_device_id arrays
gpio: Unify style of pci_device_id arrays
gpio: Unify style of various *_device_id arrays
drivers/gpio/gpio-74x164.c | 4 ++--
drivers/gpio/gpio-adnp.c | 4 ++--
drivers/gpio/gpio-aggregator.c | 2 +-
drivers/gpio/gpio-altera-a10sr.c | 2 +-
drivers/gpio/gpio-altera.c | 4 ++--
drivers/gpio/gpio-amd8111.c | 2 +-
drivers/gpio/gpio-amdpt.c | 8 ++++----
drivers/gpio/gpio-aspeed-sgpio.c | 10 +++++-----
drivers/gpio/gpio-aspeed.c | 10 +++++-----
drivers/gpio/gpio-ath79.c | 2 +-
drivers/gpio/gpio-bcm-kona.c | 1 +
drivers/gpio/gpio-blzp1600.c | 4 ++--
drivers/gpio/gpio-brcmstb.c | 2 +-
drivers/gpio/gpio-bt8xx.c | 2 +-
drivers/gpio/gpio-cadence.c | 6 +++---
drivers/gpio/gpio-creg-snps.c | 5 +++--
drivers/gpio/gpio-davinci.c | 8 ++++----
drivers/gpio/gpio-dwapb.c | 14 +++++++-------
drivers/gpio/gpio-em.c | 4 ++--
drivers/gpio/gpio-ep93xx.c | 1 +
drivers/gpio/gpio-ftgpio010.c | 3 ++-
drivers/gpio/gpio-fxl6408.c | 2 +-
drivers/gpio/gpio-graniterapids.c | 4 ++--
drivers/gpio/gpio-grgpio.c | 2 +-
drivers/gpio/gpio-gw-pld.c | 4 ++--
drivers/gpio/gpio-hisi.c | 6 +++---
drivers/gpio/gpio-hlwd.c | 4 ++--
drivers/gpio/gpio-imx-scu.c | 1 +
drivers/gpio/gpio-ixp4xx.c | 4 ++--
drivers/gpio/gpio-ljca.c | 4 ++--
drivers/gpio/gpio-loongson-64bit.c | 4 ++--
drivers/gpio/gpio-lp3943.c | 2 +-
drivers/gpio/gpio-lpc32xx.c | 4 ++--
drivers/gpio/gpio-macsmc.c | 4 ++--
drivers/gpio/gpio-max3191x.c | 12 ++++++------
drivers/gpio/gpio-max7301.c | 2 +-
drivers/gpio/gpio-max7360.c | 8 ++++----
drivers/gpio/gpio-max77620.c | 4 ++--
drivers/gpio/gpio-max77759.c | 2 +-
drivers/gpio/gpio-mb86s7x.c | 2 +-
drivers/gpio/gpio-ml-ioh.c | 2 +-
drivers/gpio/gpio-mlxbf.c | 6 +++---
drivers/gpio/gpio-mlxbf2.c | 6 +++---
drivers/gpio/gpio-mlxbf3.c | 4 ++--
drivers/gpio/gpio-mm-lantiq.c | 2 +-
drivers/gpio/gpio-mmio.c | 3 +--
drivers/gpio/gpio-mockup.c | 4 ++--
drivers/gpio/gpio-moxtet.c | 4 ++--
drivers/gpio/gpio-mpc5200.c | 9 +++++----
drivers/gpio/gpio-mpc8xxx.c | 25 +++++++++++++------------
drivers/gpio/gpio-mpfs.c | 1 +
drivers/gpio/gpio-mpsse.c | 3 +--
drivers/gpio/gpio-msc313.c | 1 +
drivers/gpio/gpio-mt7621.c | 2 +-
drivers/gpio/gpio-mvebu.c | 13 +++++++------
drivers/gpio/gpio-mxc.c | 2 +-
drivers/gpio/gpio-mxs.c | 4 ++--
drivers/gpio/gpio-nomadik.c | 7 ++++---
drivers/gpio/gpio-novalake-events.c | 4 ++--
drivers/gpio/gpio-npcm-sgpio.c | 6 +++---
drivers/gpio/gpio-octeon.c | 2 +-
drivers/gpio/gpio-omap.c | 2 +-
drivers/gpio/gpio-palmas.c | 10 +++++-----
drivers/gpio/gpio-pca953x.c | 4 ++--
drivers/gpio/gpio-pca9570.c | 2 +-
drivers/gpio/gpio-pcf857x.c | 26 +++++++++++++-------------
drivers/gpio/gpio-pci-idio-16.c | 3 ++-
drivers/gpio/gpio-pcie-idio-24.c | 8 +++++---
drivers/gpio/gpio-pisosr.c | 4 ++--
drivers/gpio/gpio-pl061.c | 2 +-
drivers/gpio/gpio-pmic-eic-sprd.c | 2 +-
drivers/gpio/gpio-pxa.c | 20 +++++++++++---------
drivers/gpio/gpio-qixis-fpga.c | 3 +--
drivers/gpio/gpio-rcar.c | 2 +-
drivers/gpio/gpio-rda.c | 2 +-
drivers/gpio/gpio-realtek-otto.c | 2 +-
drivers/gpio/gpio-rockchip.c | 4 ++--
drivers/gpio/gpio-sama5d2-piobu.c | 2 +-
drivers/gpio/gpio-sifive.c | 2 +-
drivers/gpio/gpio-sl28cpld.c | 2 +-
drivers/gpio/gpio-sodaville.c | 3 ++-
drivers/gpio/gpio-spear-spics.c | 3 ++-
drivers/gpio/gpio-sprd.c | 2 +-
drivers/gpio/gpio-stmpe.c | 2 +-
drivers/gpio/gpio-stp-xway.c | 2 +-
drivers/gpio/gpio-tegra.c | 6 +++---
drivers/gpio/gpio-tegra186.c | 26 +++++++++++++-------------
drivers/gpio/gpio-thunderx.c | 3 +--
drivers/gpio/gpio-tps65218.c | 2 +-
drivers/gpio/gpio-ts4800.c | 4 ++--
drivers/gpio/gpio-ts4900.c | 2 +-
drivers/gpio/gpio-twl4030.c | 4 ++--
drivers/gpio/gpio-usbio.c | 13 +++++++------
drivers/gpio/gpio-vf610.c | 4 ++--
drivers/gpio/gpio-virtio.c | 4 ++--
drivers/gpio/gpio-visconti.c | 2 +-
drivers/gpio/gpio-waveshare-dsi.c | 2 +-
drivers/gpio/gpio-xgene-sb.c | 6 +++---
drivers/gpio/gpio-xgene.c | 10 ++++++----
drivers/gpio/gpio-xgs-iproc.c | 2 +-
drivers/gpio/gpio-xilinx.c | 4 ++--
drivers/gpio/gpio-xlp.c | 6 +++---
drivers/gpio/gpio-xra1403.c | 6 +++---
drivers/gpio/gpio-zevio.c | 5 +++--
drivers/gpio/gpio-zynqmp-modepin.c | 2 +-
drivers/gpio/gpiolib-acpi-quirks.c | 2 +-
106 files changed, 265 insertions(+), 247 deletions(-)
base-commit: b8809969e1d7a591e0f49dd464a5d04b3cf02ab1
--
2.55.0.11.g153666a7d9bb
^ permalink raw reply
* [PATCH v2 14/21] gpio: virtio: Use a named initializer for virtio_device_id array
From: Uwe Kleine-König (The Capable Hub) @ 2026-07-15 16:55 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski
Cc: Enrico Weigelt, metux IT consult, Viresh Kumar, linux-gpio,
virtualization, linux-kernel, Viresh Kumar
In-Reply-To: <cover.1784133987.git.u.kleine-koenig@baylibre.com>
While being less compact, using named initializers allows to more easily
see which members of the structs are assigned which value without having
to lookup the declaration of the struct. And it's also more robust
against changes to the struct definition.
This patch doesn't modify the compiled array, only its representation in
source form benefits.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
drivers/gpio/gpio-virtio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-virtio.c b/drivers/gpio/gpio-virtio.c
index ed6e0e90fa8a..42871db05ec1 100644
--- a/drivers/gpio/gpio-virtio.c
+++ b/drivers/gpio/gpio-virtio.c
@@ -646,7 +646,7 @@ static void virtio_gpio_remove(struct virtio_device *vdev)
}
static const struct virtio_device_id id_table[] = {
- { VIRTIO_ID_GPIO, VIRTIO_DEV_ANY_ID },
+ { .device = VIRTIO_ID_GPIO, .vendor = VIRTIO_DEV_ANY_ID },
{},
};
MODULE_DEVICE_TABLE(virtio, id_table);
--
2.55.0.11.g153666a7d9bb
^ permalink raw reply related
* [PATCH v2 21/21] gpio: Unify style of various *_device_id arrays
From: Uwe Kleine-König (The Capable Hub) @ 2026-07-15 16:55 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski
Cc: Lixu Zhang, Sakari Ailus, Enrico Weigelt, metux IT consult,
Viresh Kumar, Mika Westerberg, Andy Shevchenko, linux-gpio,
linux-kernel, virtualization, linux-acpi, Viresh Kumar
In-Reply-To: <cover.1784133987.git.u.kleine-koenig@baylibre.com>
Update the various *_device_id arrays to conform to the most used and
generally recommended coding style. That is:
- no comma after the list terminator;
- a comma after an initializer if (and only if) the closing } is not
directly following;
- no explicit zeros in the list terminator;
- a space after an opening { and before a closing }, a single space in
the list terminator;
Adapt the few offenders accordingly.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
drivers/gpio/gpio-ljca.c | 2 +-
drivers/gpio/gpio-mpsse.c | 3 +--
drivers/gpio/gpio-pca953x.c | 2 +-
drivers/gpio/gpio-virtio.c | 2 +-
drivers/gpio/gpiolib-acpi-quirks.c | 2 +-
5 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpio/gpio-ljca.c b/drivers/gpio/gpio-ljca.c
index ad5dc9a3a119..d9d7394d8b95 100644
--- a/drivers/gpio/gpio-ljca.c
+++ b/drivers/gpio/gpio-ljca.c
@@ -473,7 +473,7 @@ static void ljca_gpio_remove(struct auxiliary_device *auxdev)
static const struct auxiliary_device_id ljca_gpio_id_table[] = {
{ "usb_ljca.ljca-gpio" },
- { /* sentinel */ },
+ { /* sentinel */ }
};
MODULE_DEVICE_TABLE(auxiliary, ljca_gpio_id_table);
diff --git a/drivers/gpio/gpio-mpsse.c b/drivers/gpio/gpio-mpsse.c
index a859deab2bca..7ca06bdb2c4b 100644
--- a/drivers/gpio/gpio-mpsse.c
+++ b/drivers/gpio/gpio-mpsse.c
@@ -77,10 +77,9 @@ static struct mpsse_quirk bryx_brik_quirk = {
static const struct usb_device_id gpio_mpsse_table[] = {
{ USB_DEVICE(0x0c52, 0xa064) }, /* SeaLevel Systems, Inc. */
{ USB_DEVICE(0x0403, 0x6988), /* FTDI, assigned to Bryx */
- .driver_info = (kernel_ulong_t)&bryx_brik_quirk},
+ .driver_info = (kernel_ulong_t)&bryx_brik_quirk },
{ } /* Terminating entry */
};
-
MODULE_DEVICE_TABLE(usb, gpio_mpsse_table);
static DEFINE_IDA(gpio_mpsse_ida);
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 918cadc2db07..7db33477faf1 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -175,7 +175,7 @@ static const struct dmi_system_id pca953x_dmi_acpi_irq_info[] = {
DMI_EXACT_MATCH(DMI_BOARD_NAME, "GalileoGen2"),
},
},
- {}
+ { }
};
#endif
diff --git a/drivers/gpio/gpio-virtio.c b/drivers/gpio/gpio-virtio.c
index 42871db05ec1..062c70fe4671 100644
--- a/drivers/gpio/gpio-virtio.c
+++ b/drivers/gpio/gpio-virtio.c
@@ -647,7 +647,7 @@ static void virtio_gpio_remove(struct virtio_device *vdev)
static const struct virtio_device_id id_table[] = {
{ .device = VIRTIO_ID_GPIO, .vendor = VIRTIO_DEV_ANY_ID },
- {},
+ { }
};
MODULE_DEVICE_TABLE(virtio, id_table);
diff --git a/drivers/gpio/gpiolib-acpi-quirks.c b/drivers/gpio/gpiolib-acpi-quirks.c
index a0116f004975..7c5817a3157e 100644
--- a/drivers/gpio/gpiolib-acpi-quirks.c
+++ b/drivers/gpio/gpiolib-acpi-quirks.c
@@ -392,7 +392,7 @@ static const struct dmi_system_id gpiolib_acpi_quirks[] __initconst = {
.ignore_wake = "VEN_0488:00@355",
},
},
- {} /* Terminating entry */
+ { } /* Terminating entry */
};
static int __init acpi_gpio_setup_params(void)
--
2.55.0.11.g153666a7d9bb
^ permalink raw reply related
* Re: [PATCH 2/4] virtio_input: validate device-reported multitouch slot count
From: Dmitry Torokhov @ 2026-07-15 18:25 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Hari Mishal, Amit Shah, Arnd Bergmann, Greg Kroah-Hartman,
Gerd Hoffmann, Jason Wang, David Hildenbrand, Henrik Rydberg,
Xuan Zhuo, Eugenio Pérez, virtualization, linux-kernel,
linux-input
In-Reply-To: <20260715120911-mutt-send-email-mst@kernel.org>
On Wed, Jul 15, 2026 at 12:11:12PM -0400, Michael S. Tsirkin wrote:
> On Wed, Jul 15, 2026 at 06:07:56PM +0200, Hari Mishal wrote:
> > On Wed, Jul 15, 2026 at 5:50 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > >
> > > On Wed, Jul 15, 2026 at 04:22:41PM +0200, Hari Mishal wrote:
> > > > nslots is derived from the ABS_MT_SLOT maximum reported by the
> > > > virtio device. A device could report a bogus maximum (e.g. -1)
> > > > making nslots = 0, which input_mt_init_slots() does not reject;
> > > > it returns success without allocating any slot storage, silently
> > > > leaving the device registered as multitouch capable with no
> > > > backing state.
> > >
> > > So let's disable multitouch instead?
> > >
> >
> > So rather than failing the whole probe, just warn and clear
> > ABS_MT_SLOT from absbit in that case, so the rest of the device
> > still registers? I took my lead from input_mt_init_slots(), which
> > has its own internal cap and returns -EINVAL when the device
> > reports more than 1024 slots.
> > Shall I modify that case to get the same "warn and disable
> > multitouch" for consistency, or is a hard failure better there since
> > it's a different type of bad device data?
>
> I don't really know enough for sure but generally if the device can
> kinda work it's better than not working, and adding
> a capability to a device that driver can't use should
> generally just ignore the capability, not fail probe.
What is the failure mode if we keep the ABS_MT_SLOT capability? Does the
kernel crash? And if this can cause crash then we should fix
input_mt_init_slots() to reject requests for 0 slots with -EINVAL.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] virtio-pmem: allocate flush bio from a driver-private bio_set
From: Joseph Qi @ 2026-07-15 23:47 UTC (permalink / raw)
To: Pankaj Gupta; +Cc: Christoph Hellwig, Baokun Li, virtualization, linux-kernel
In-Reply-To: <20260709124455.1547912-1-joseph.qi@linux.alibaba.com>
Gentle ping...
On 7/9/26 8:44 PM, Joseph Qi wrote:
> async_pmem_flush() allocates a child bio for the flush with GFP_ATOMIC.
> This runs from pmem_submit_bio(), a ->submit_bio callback that executes
> in a sleepable context, so there is no atomicity requirement here.
>
> bio_alloc() only guarantees success when __GFP_DIRECT_RECLAIM is set,
> because that is what lets it fall back to the mempool reserve. With
> GFP_ATOMIC the reclaim bit is absent, so the allocation can fail and
> return -ENOMEM whenever the fast paths (percpu cache and slab) are
> exhausted, which is common right after boot. A flush is issued from
> filesystem writeback and must not fail on a transient allocation
> shortage, otherwise the device can appear unmountable:
>
> Buffer I/O error on dev pmem0, logical block 0, lost sync page write
>
> Switch to GFP_NOIO so __GFP_DIRECT_RECLAIM is set and the allocation can
> make forward progress. However, bio_alloc() draws from the shared
> fs_bio_set, and the incoming bio being flushed may itself have come from
> fs_bio_set; allocating a second bio from the same set while submitting
> underneath ->submit_bio can deadlock the mempool. Add a driver-private
> bio_set for the flush and allocate from it via bio_alloc_bioset(), so
> the flush bio has an independent reserve.
>
> With a dedicated mempool-backed bio_set and GFP_NOIO the allocation
> cannot fail, so drop the now-redundant NULL check.
>
> Fixes: 6e84200c0a29 ("virtio-pmem: Add virtio pmem driver")
> Suggested-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com>
> ---
> drivers/nvdimm/nd_virtio.c | 11 ++++++-----
> drivers/nvdimm/virtio_pmem.c | 11 ++++++++++-
> drivers/nvdimm/virtio_pmem.h | 4 ++++
> 3 files changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/nvdimm/nd_virtio.c b/drivers/nvdimm/nd_virtio.c
> index 4176046627beb..b4bd21edf5c1c 100644
> --- a/drivers/nvdimm/nd_virtio.c
> +++ b/drivers/nvdimm/nd_virtio.c
> @@ -110,17 +110,18 @@ static int virtio_pmem_flush(struct nd_region *nd_region)
> /* The asynchronous flush callback function */
> int async_pmem_flush(struct nd_region *nd_region, struct bio *bio)
> {
> + struct virtio_device *vdev = nd_region->provider_data;
> + struct virtio_pmem *vpmem = vdev->priv;
> +
> /*
> * Create child bio for asynchronous flush and chain with
> * parent bio. Otherwise directly call nd_region flush.
> */
> if (bio && bio->bi_iter.bi_sector != -1) {
> - struct bio *child = bio_alloc(bio->bi_bdev, 0,
> - REQ_OP_WRITE | REQ_PREFLUSH,
> - GFP_ATOMIC);
> + struct bio *child = bio_alloc_bioset(bio->bi_bdev, 0,
> + REQ_OP_WRITE | REQ_PREFLUSH, GFP_NOIO,
> + &vpmem->flush_bio_set);
>
> - if (!child)
> - return -ENOMEM;
> bio_clone_blkg_association(child, bio);
> child->bi_iter.bi_sector = -1;
> bio_chain(child, bio);
> diff --git a/drivers/nvdimm/virtio_pmem.c b/drivers/nvdimm/virtio_pmem.c
> index 77b1966619059..136179506b478 100644
> --- a/drivers/nvdimm/virtio_pmem.c
> +++ b/drivers/nvdimm/virtio_pmem.c
> @@ -65,12 +65,17 @@ static int virtio_pmem_probe(struct virtio_device *vdev)
> }
>
> mutex_init(&vpmem->flush_lock);
> + err = bioset_init(&vpmem->flush_bio_set, BIO_POOL_SIZE, 0, 0);
> + if (err) {
> + dev_err(&vdev->dev, "failed to initialize flush bio_set\n");
> + goto out_err;
> + }
> vpmem->vdev = vdev;
> vdev->priv = vpmem;
> err = init_vq(vpmem);
> if (err) {
> dev_err(&vdev->dev, "failed to initialize virtio pmem vq's\n");
> - goto out_err;
> + goto out_bioset;
> }
>
> if (virtio_has_feature(vdev, VIRTIO_PMEM_F_SHMEM_REGION)) {
> @@ -131,6 +136,8 @@ static int virtio_pmem_probe(struct virtio_device *vdev)
> nvdimm_bus_unregister(vpmem->nvdimm_bus);
> out_vq:
> vdev->config->del_vqs(vdev);
> +out_bioset:
> + bioset_exit(&vpmem->flush_bio_set);
> out_err:
> return err;
> }
> @@ -138,10 +145,12 @@ static int virtio_pmem_probe(struct virtio_device *vdev)
> static void virtio_pmem_remove(struct virtio_device *vdev)
> {
> struct nvdimm_bus *nvdimm_bus = dev_get_drvdata(&vdev->dev);
> + struct virtio_pmem *vpmem = vdev->priv;
>
> nvdimm_bus_unregister(nvdimm_bus);
> vdev->config->del_vqs(vdev);
> virtio_reset_device(vdev);
> + bioset_exit(&vpmem->flush_bio_set);
> }
>
> static int virtio_pmem_freeze(struct virtio_device *vdev)
> diff --git a/drivers/nvdimm/virtio_pmem.h b/drivers/nvdimm/virtio_pmem.h
> index f72cf17f9518f..4ff2076f75047 100644
> --- a/drivers/nvdimm/virtio_pmem.h
> +++ b/drivers/nvdimm/virtio_pmem.h
> @@ -15,6 +15,7 @@
> #include <linux/libnvdimm.h>
> #include <linux/mutex.h>
> #include <linux/spinlock.h>
> +#include <linux/bio.h>
>
> struct virtio_pmem_request {
> struct virtio_pmem_req req;
> @@ -39,6 +40,9 @@ struct virtio_pmem {
> /* Serialize flush requests to the device. */
> struct mutex flush_lock;
>
> + /* bio_set for allocating flush child bios */
> + struct bio_set flush_bio_set;
> +
> /* nvdimm bus registers virtio pmem device */
> struct nvdimm_bus *nvdimm_bus;
> struct nvdimm_bus_descriptor nd_desc;
^ permalink raw reply
* [PATCH] virtio_net: fix spelling of aggressively in comments
From: Weimin Xiong @ 2026-07-16 1:12 UTC (permalink / raw)
To: virtualization
Cc: netdev, mst, jasowangio, xuanzhuo, eperezma, andrew+netdev, davem,
edumazet, kuba, pabeni, linux-kernel
From: xiongweimin <xiongweimin@kylinos.cn>
Two receive-path comments misspell "aggressively" as "agressively".
Signed-off-by: xiongweimin <xiongweimin@kylinos.cn>
---
drivers/net/virtio_net.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 3e2a5876c..f3c7b28ce 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -3190,7 +3190,7 @@ static int virtnet_open(struct net_device *dev)
for (i = 0; i < vi->max_queue_pairs; i++) {
if (i < vi->curr_queue_pairs)
- /* Pre-fill rq agressively, to make sure we are ready to
+ /* Pre-fill rq aggressively, to make sure we are ready to
* get packets immediately.
*/
try_fill_recv(vi, &vi->rq[i], GFP_KERNEL);
@@ -3419,7 +3419,7 @@ static void virtnet_rx_resume(struct virtnet_info *vi,
bool refill)
{
if (netif_running(vi->dev)) {
- /* Pre-fill rq agressively, to make sure we are ready to get
+ /* Pre-fill rq aggressively, to make sure we are ready to get
* packets immediately.
*/
if (refill)
--
2.43.0
^ permalink raw reply related
* [PATCH] iommu/virtio: Set driver data before enabling virtqueues
From: Weimin Xiong @ 2026-07-16 1:21 UTC (permalink / raw)
To: virtualization; +Cc: iommu, jpb, joro, will, robin.murphy, linux-kernel
From: Xiong Weimin <xiongweimin@kylinos.cn>
The event virtqueue callback retrieves the driver state through
vq->vdev->priv. viommu_probe() currently initializes that pointer only
after virtio_device_ready() and after the event queue is populated.
Store the driver data before creating the virtqueues so callbacks always
see initialized driver state once the device is made ready. Clear the
pointer again on probe failure.
Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
---
drivers/iommu/virtio-iommu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 9118377d7..4c91a82d2 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -1173,11 +1173,12 @@ static int viommu_probe(struct virtio_device *vdev)
ida_init(&viommu->domain_ids);
viommu->dev = dev;
viommu->vdev = vdev;
+ vdev->priv = viommu;
INIT_LIST_HEAD(&viommu->requests);
ret = viommu_init_vqs(viommu);
if (ret)
- return ret;
+ goto err_clear_priv;
virtio_cread_le(vdev, struct virtio_iommu_config, page_size_mask,
&viommu->pgsize_bitmap);
@@ -1238,8 +1239,6 @@ static int viommu_probe(struct virtio_device *vdev)
if (ret)
goto err_free_vqs;
- vdev->priv = viommu;
-
ret = iommu_device_register(&viommu->iommu, &viommu_ops, parent_dev);
if (ret)
goto err_remove_sysfs;
@@ -1254,6 +1253,7 @@ static int viommu_probe(struct virtio_device *vdev)
iommu_device_sysfs_remove(&viommu->iommu);
err_free_vqs:
vdev->config->del_vqs(vdev);
+err_clear_priv:
vdev->priv = NULL;
return ret;
--
2.43.0
^ permalink raw reply related
* [PATCH] iommu/virtio: Handle iommu_device_register() failures
From: Weimin Xiong @ 2026-07-16 1:21 UTC (permalink / raw)
To: virtualization; +Cc: iommu, jpb, joro, will, robin.murphy, linux-kernel
In-Reply-To: <20260716012157.88769-1-xiongwm2026@163.com>
From: Xiong Weimin <xiongweimin@kylinos.cn>
iommu_device_register() returns an error when the IOMMU core fails to
register the hardware instance or probe the buses. viommu_probe()
currently ignores that error and continues as if the device was
registered successfully.
Propagate the failure and unwind the sysfs entry and virtqueues that
were set up earlier. Clear the driver data on the error path as well,
since it is set before registration so bus probing can find the
virtio-IOMMU instance.
Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
---
drivers/iommu/virtio-iommu.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 342785c76..9118377d7 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -1240,7 +1240,9 @@ static int viommu_probe(struct virtio_device *vdev)
vdev->priv = viommu;
- iommu_device_register(&viommu->iommu, &viommu_ops, parent_dev);
+ ret = iommu_device_register(&viommu->iommu, &viommu_ops, parent_dev);
+ if (ret)
+ goto err_remove_sysfs;
dev_info(dev, "input address: %u bits\n",
order_base_2(viommu->geometry.aperture_end));
@@ -1248,8 +1250,11 @@ static int viommu_probe(struct virtio_device *vdev)
return 0;
+err_remove_sysfs:
+ iommu_device_sysfs_remove(&viommu->iommu);
err_free_vqs:
vdev->config->del_vqs(vdev);
+ vdev->priv = NULL;
return ret;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 1/2] iommu/virtio: Set driver data before enabling virtqueues
From: Weimin Xiong @ 2026-07-16 1:25 UTC (permalink / raw)
To: virtualization; +Cc: iommu, jpb, joro, will, robin.murphy
Sorry for the noise. The two patches are duplicates of what I already
sent earlier. Please ignore this series.
^ permalink raw reply
* [PATCH] vhost: reject zero-size IOTLB INVALIDATE
From: Weimin Xiong @ 2026-07-16 3:00 UTC (permalink / raw)
To: virtualization; +Cc: mst, jasowangio, eperezma, netdev, xiongweimin
From: xiongweimin <xiongweimin@kylinos.cn>
Reject VHOST_IOTLB_INVALIDATE messages with size == 0 to prevent
iova + size - 1 from underflowing to U64_MAX, which would
incorrectly delete the entire IOTLB.
Signed-off-by: xiongweimin <xiongweimin@kylinos.cn>
---
drivers/vhost/vhost.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 3c080c454e374cabd7321416ed92c5f7d3135254..xxxxxxxxxx 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1656,6 +1656,10 @@ static int vhost_process_iotlb_msg(struct vhost_dev *dev, u32 asid,
if (!dev->iotlb) {
ret = -EFAULT;
break;
+ }
+ if (!msg->size) {
+ ret = -EINVAL;
+ break;
}
vhost_vq_meta_reset(dev);
vhost_iotlb_del_range(dev->iotlb, msg->iova,
--
2.39.3
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox