* [PATCH v3] vdpa/mlx5: Fix buffer length in create_direct_keys()
From: Christian Borntraeger @ 2026-07-06 14:15 UTC (permalink / raw)
To: Dragos Tatulea
Cc: Michael S . Tsirkin, Jason Wang, virtualization, linux-kernel,
Christian Borntraeger
We have seen in our CI the following KASAN message:
BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core]
Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764
[...]
[<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core]
[<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core]
[<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa]
[<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa]
[...]
The buggy address is located 4128 bytes inside of
allocated 4384-byte region [0000000176794000, 0000000176795120)
So in essence we read 16 bytes beyond 4384-byte allocation.
create_direct_keys calculates the pointer and length for in and out
buffers.
The size calculation for in includes the entire structure
size (out + in + mtt[]) but the pointer passed to cmd_exec points only
to the 'in' field, skipping the 'out' field.
This causes mlx5_copy_to_msg() to read beyond the allocated buffer
by sizeof(out) bytes when copying command data.
Properly calculate the input size to match the pointer and allocation size.
Fixes: 0071b138d44a ("vdpa/mlx5: Create direct MKEYs in parallel")
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
---
v2->v3: use full size - offset to handle padding and alignment
RFC->v2: use flex_array_size
drivers/vdpa/mlx5/core/mr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c
index 6d02ccf9eb91..d422f3faeb48 100644
--- a/drivers/vdpa/mlx5/core/mr.c
+++ b/drivers/vdpa/mlx5/core/mr.c
@@ -233,7 +233,8 @@ static int create_direct_keys(struct mlx5_vdpa_dev *mvdev, struct mlx5_vdpa_mr *
cmds[i].out = cmd_mem->out;
cmds[i].outlen = sizeof(cmd_mem->out);
cmds[i].in = cmd_mem->in;
- cmds[i].inlen = struct_size(cmd_mem, mtt, mttcount);
+ cmds[i].inlen = struct_size(cmd_mem, mtt, mttcount) -
+ offsetof(struct mlx5_create_mkey_mem, in);
fill_create_direct_mr(mvdev, dmr, cmd_mem);
--
2.53.0
^ permalink raw reply related
* Re: [RFC/PATCH] vdpa/mlx5: Fix buffer length in create_direct_keys()
From: Dragos Tatulea @ 2026-07-06 13:59 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Michael S . Tsirkin, Jason Wang, virtualization, linux-kernel
In-Reply-To: <530d7a50-3bd0-496a-bf41-3b99c8fbbad4@linux.ibm.com>
On 06.07.26 14:59, Christian Borntraeger wrote:
>
>
> Am 06.07.26 um 14:24 schrieb Dragos Tatulea:
>>
>>
>> On 06.07.26 12:13, Christian Borntraeger wrote:
>>>
>>>
>>> Am 06.07.26 um 12:01 schrieb Christian Borntraeger:
>>>> We have seen in our CI the following KASAN message:
>>>> BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core]
>>>> Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764
>>>> [...]
>>>> [<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core]
>>>> [<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core]
>>>> [<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa]
>>>> [<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa]
>>>> [...]
>>>> The buggy address is located 4128 bytes inside of
>>>> allocated 4384-byte region [0000000176794000, 0000000176795120)
>>>>
>>>> So in essence we read 16 bytes beyond 4384-byte allocation.
>>>> create_direct_keys calculates the pointer and length for in and out
>>>> buffers.
>>>> The size calculation for in includes the entire structure
>>>> size (out + in + mtt[]) but the pointer passed to cmd_exec points only
>>>> to the 'in' field, skipping the 'out' field.
>>>>
>>>> This causes mlx5_copy_to_msg() to read beyond the allocated buffer
>>>> by sizeof(out) bytes when copying command data.
>>>>
>>>> Calculates the input size as sizeof(in) + mtt_array_size to match the
>>>> pointer and allocation size.
>>>>
>>>> Fixes: 0071b138d44a ("vdpa/mlx5: Create direct MKEYs in parallel")
>>>> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
>>>> ---
>>>> drivers/vdpa/mlx5/core/mr.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c
>>>> index 6d02ccf9eb91..03fe7f5ca412 100644
>>>> --- a/drivers/vdpa/mlx5/core/mr.c
>>>> +++ b/drivers/vdpa/mlx5/core/mr.c
>>>> @@ -233,7 +233,7 @@ static int create_direct_keys(struct mlx5_vdpa_dev *mvdev, struct mlx5_vdpa_mr *
>>>> cmds[i].out = cmd_mem->out;
>>>> cmds[i].outlen = sizeof(cmd_mem->out);
>>>> cmds[i].in = cmd_mem->in;
>>>> - cmds[i].inlen = struct_size(cmd_mem, mtt, mttcount);
>>>> + cmds[i].inlen = sizeof(cmd_mem->in) + (mttcount * sizeof(cmd_mem->mtt[0]));
>> Woops... Thanks for the catch. The fix is good.
>>
>>>
>>> Assuming the fix is the correct fix, question is, if I should use the offset of in instead, e.g.
>>>
>>> cmds[i].inlen = struct_size(cmd_mem, mtt, mttcount) - offsetof(cmd_mem, in);
>>>
>>> to handle potential alignment and padding aspects.
>>>
>> Seems harder to read. Why not:
>> sizeof(cmd_mem->in) + flex_array_size(cmd_mem, mtts, mttcount) ?
>
> Can do that. I assume we do not have any implicit holes in the structure due to alignment? In
> other words, sizeof(cmd_mem->in) can never be something like 20 (and then the flex array would
> start at 24 to align 8 byte elements). If thats the case I will respin with your proposal.
Weeelll, I checked on a x86_64 build and there is a hole there of 16 bytes. So your second
formula is indeed the way to go.
Thanks,
Dragos
^ permalink raw reply
* [PATCH v3] virtio_balloon: prime stats vq after virtio_device_ready()
From: Michael S. Tsirkin @ 2026-07-06 13:56 UTC (permalink / raw)
To: linux-kernel
Cc: David Hildenbrand, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Adam Litke, Rusty Russell, virtualization
The virtio spec requires the driver not to kick the device before
DRIVER_OK is set. init_vqs() primes the stats virtqueue with a buffer
and kicks the device before virtio_device_ready() is called in
virtballoon_probe(), violating this requirement.
Further, if the device responds to the early kick by processing the
buffer before DRIVER_OK, stats_request() fires and queues
update_balloon_stats_work. Should probe then fail and free vb, the work
runs against freed memory.
To fix, move buffer setup to after DRIVER_OK. Be careful to
disable update_balloon_stats_work while this is going on,
to make sure it does not race with the setup.
setup_vqs() warns but does not fail probe or restore if
virtqueue_add_outbuf() fails; the call never actually fails in these
contexts since the queue is freshly initialized and empty.
Testing: tested that stats still work after the change.
Fixes: 9564e138b1f6 ("virtio: Add memory statistics reporting to the balloon driver (V4)")
Reported-by: Sashiko:gemini-3.1-pro-preview
Cc: David Hildenbrand <david@kernel.org>
Assisted-by: Claude:claude-sonnet-4-6
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
v2->v3: add disable_work comment and BUG_ON -> WARN_ON_ONCE (David Hildenbrand)
v1->v2: check that work enable/disable is balanced;
explain how add buf never fails in probe/restore,
add back a warning if it somehow does
drivers/virtio/virtio_balloon.c | 51 +++++++++++++++++++++------------
1 file changed, 33 insertions(+), 18 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 088b3a0e6ce6..83ae1f3cd460 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -611,25 +611,9 @@ static int init_vqs(struct virtio_balloon *vb)
vb->inflate_vq = vqs[VIRTIO_BALLOON_VQ_INFLATE];
vb->deflate_vq = vqs[VIRTIO_BALLOON_VQ_DEFLATE];
if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
- struct scatterlist sg;
- unsigned int num_stats;
vb->stats_vq = vqs[VIRTIO_BALLOON_VQ_STATS];
-
- /*
- * Prime this virtqueue with one buffer so the hypervisor can
- * use it to signal us later (it can't be broken yet!).
- */
- num_stats = update_balloon_stats(vb);
-
- sg_init_one(&sg, vb->stats, sizeof(vb->stats[0]) * num_stats);
- err = virtqueue_add_outbuf(vb->stats_vq, &sg, 1, vb,
- GFP_KERNEL);
- if (err) {
- dev_warn(&vb->vdev->dev, "%s: add stat_vq failed\n",
- __func__);
- return err;
- }
- virtqueue_kick(vb->stats_vq);
+ /* Prevent update_balloon_stats_work from accessing the stats vq. */
+ disable_work(&vb->update_balloon_stats_work);
}
if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT))
@@ -916,6 +900,33 @@ static int virtio_balloon_register_shrinker(struct virtio_balloon *vb)
return 0;
}
+static void setup_vqs(struct virtio_balloon *vb)
+{
+ struct scatterlist sg;
+ unsigned int num_stats;
+ bool ret;
+
+ if (!virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ))
+ return;
+
+ /*
+ * Prime this virtqueue with one buffer so the hypervisor can
+ * use it to signal us later (it can't be broken yet!).
+ */
+ num_stats = update_balloon_stats(vb);
+ sg_init_one(&sg, vb->stats, sizeof(vb->stats[0]) * num_stats);
+ if (virtqueue_add_outbuf(vb->stats_vq, &sg, 1, vb, GFP_KERNEL)) {
+ dev_warn(&vb->vdev->dev, "%s: add stat_vq failed\n", __func__);
+ return;
+ }
+ virtqueue_kick(vb->stats_vq);
+
+ ret = enable_and_queue_work(system_freezable_wq,
+ &vb->update_balloon_stats_work);
+ /* Make sure we balanced enable/disable, or we won't report stats. */
+ WARN_ON_ONCE(!ret);
+}
+
static int virtballoon_probe(struct virtio_device *vdev)
{
struct virtio_balloon *vb;
@@ -1059,6 +1070,8 @@ static int virtballoon_probe(struct virtio_device *vdev)
virtio_device_ready(vdev);
+ setup_vqs(vb);
+
if (towards_target(vb))
virtballoon_changed(vdev);
return 0;
@@ -1148,6 +1161,8 @@ static int virtballoon_restore(struct virtio_device *vdev)
virtio_device_ready(vdev);
+ setup_vqs(vb);
+
if (towards_target(vb))
virtballoon_changed(vdev);
update_balloon_size(vb);
--
MST
^ permalink raw reply related
* Re: [PATCH v2] virtio_balloon: prime stats vq after virtio_device_ready()
From: David Hildenbrand (Arm) @ 2026-07-06 13:42 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Adam Litke, Rusty Russell, virtualization, Andrew Morton,
linux-mm
In-Reply-To: <20260706070936-mutt-send-email-mst@kernel.org>
On 7/6/26 14:59, Michael S. Tsirkin wrote:
> On Mon, Jul 06, 2026 at 10:57:33AM +0200, David Hildenbrand (Arm) wrote:
>> On 7/6/26 10:43, Michael S. Tsirkin wrote:
>>>
>>> Sorry I do not get the question. Virtio API expects
>>> callers to serialize calls for each VQ. So this just prevents the work
>>> from running and accessing the VQ while probe calls add_buf/kick.
>>> I'll add a comment explaining that.
>>> But it has nothing to do with the spec.
>>
>> The device is clearly not properly initialized yet.
>>
>> Yet, we expect that we get a stats_request() callback that would try to
>> queue_work(). And IIUC, the stats_request() will be directly issued by the device.
>
> With an in-spec device, it can happen right after virtio_device_ready.
> We could defer it a bit, but I don't see what this gets us, and
> this also protects against any out of spec ones.
Agreed.
>
>
>> In QEMU, that would mean that balloon_stats_poll_cb() runs, which would do a
>>
>> if (s->stats_vq_elem == NULL) {
>> ...
>> return
>> }
>>
>> virtqueue_push(s->svq, s->stats_vq_elem, 0);
>> virtio_notify(vdev, s->svq);
>>
>>
>> That's why I'm confused :)
>
> First the spec says there could be interrupts for no reasons right after
> DRIVER_OK. Second there are situations in which qemu might
> consume a buffer without a kick and then an interrupt
> races with the kick.
Okay, makes sense, thanks.
--
Cheers,
David
^ permalink raw reply
* [PATCH v2] vdpa/mlx5: Fix buffer length in create_direct_keys()
From: Christian Borntraeger @ 2026-07-06 13:20 UTC (permalink / raw)
To: Dragos Tatulea
Cc: Michael S . Tsirkin, Jason Wang, virtualization, linux-kernel,
Christian Borntraeger
We have seen in our CI the following KASAN message:
BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core]
Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764
[...]
[<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core]
[<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core]
[<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa]
[<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa]
[...]
The buggy address is located 4128 bytes inside of
allocated 4384-byte region [0000000176794000, 0000000176795120)
So in essence we read 16 bytes beyond 4384-byte allocation.
create_direct_keys calculates the pointer and length for in and out
buffers.
The size calculation for in includes the entire structure
size (out + in + mtt[]) but the pointer passed to cmd_exec points only
to the 'in' field, skipping the 'out' field.
This causes mlx5_copy_to_msg() to read beyond the allocated buffer
by sizeof(out) bytes when copying command data.
Calculates the input size as sizeof(in) + size of the flex array to
match the pointer and allocation size.
Fixes: 0071b138d44a ("vdpa/mlx5: Create direct MKEYs in parallel")
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
---
RFC->v2: use flex_array_size
drivers/vdpa/mlx5/core/mr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c
index 6d02ccf9eb91..a3183a0c69c9 100644
--- a/drivers/vdpa/mlx5/core/mr.c
+++ b/drivers/vdpa/mlx5/core/mr.c
@@ -233,7 +233,8 @@ static int create_direct_keys(struct mlx5_vdpa_dev *mvdev, struct mlx5_vdpa_mr *
cmds[i].out = cmd_mem->out;
cmds[i].outlen = sizeof(cmd_mem->out);
cmds[i].in = cmd_mem->in;
- cmds[i].inlen = struct_size(cmd_mem, mtt, mttcount);
+ cmds[i].inlen = sizeof(cmd_mem->in) +
+ flex_array_size(cmd_mem, mtt, mttcount);
fill_create_direct_mr(mvdev, dmr, cmd_mem);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3] mm: page_reporting: allow driver to set batch capacity
From: Sasha Levin @ 2026-07-06 13:01 UTC (permalink / raw)
To: Andrew Morton
Cc: Michael S. Tsirkin, linux-kernel, David Hildenbrand (Arm),
Gregory Price, Zi Yan, Pankaj Gupta, Jason Wang, Xuan Zhuo,
Eugenio Pérez, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Brendan Jackman, Johannes Weiner, Alexander Duyck, virtualization,
linux-mm
In-Reply-To: <20260705110649.bd30f742c78801a76137c53b@linux-foundation.org>
On Sun, Jul 05, 2026 at 11:06:49AM -0700, Andrew Morton wrote:
>On Sun, 5 Jul 2026 05:06:27 -0400 "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
>> > -stable maintainers have been asked not to do that - only backport
>> > patches which have an explicit cc:stable.
>>
>> Out of curiousity, is this specific to -mm?
>
>Not sure. I have vague memories of being told "we added MM to the
>list", but perhaps I made that up.
>
>Sasha, it MM the only subsystem which requires explicit cc:stable
>for patches to be backported?
There are a few more. We maintain the list here:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/ignore_list
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v2] virtio_balloon: prime stats vq after virtio_device_ready()
From: Michael S. Tsirkin @ 2026-07-06 12:59 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: linux-kernel, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Adam Litke, Rusty Russell, virtualization, Andrew Morton,
linux-mm
In-Reply-To: <24336f56-1024-4c9b-8653-b1a4658b627c@kernel.org>
On Mon, Jul 06, 2026 at 10:57:33AM +0200, David Hildenbrand (Arm) wrote:
> On 7/6/26 10:43, Michael S. Tsirkin wrote:
> > On Mon, Jul 06, 2026 at 10:38:18AM +0200, David Hildenbrand (Arm) wrote:
> >>>
> >>> Yes.
> >>>
> >>>
> >>> Why not?
> >>
> >> I was wondering whether the spec would state something about that.
> >
> > Sorry I do not get the question. Virtio API expects
> > callers to serialize calls for each VQ. So this just prevents the work
> > from running and accessing the VQ while probe calls add_buf/kick.
> > I'll add a comment explaining that.
> > But it has nothing to do with the spec.
>
> The device is clearly not properly initialized yet.
>
> Yet, we expect that we get a stats_request() callback that would try to
> queue_work(). And IIUC, the stats_request() will be directly issued by the device.
With an in-spec device, it can happen right after virtio_device_ready.
We could defer it a bit, but I don't see what this gets us, and
this also protects against any out of spec ones.
> In QEMU, that would mean that balloon_stats_poll_cb() runs, which would do a
>
> if (s->stats_vq_elem == NULL) {
> ...
> return
> }
>
> virtqueue_push(s->svq, s->stats_vq_elem, 0);
> virtio_notify(vdev, s->svq);
>
>
> That's why I'm confused :)
First the spec says there could be interrupts for no reasons right after
DRIVER_OK. Second there are situations in which qemu might
consume a buffer without a kick and then an interrupt
races with the kick.
> --
> Cheers,
>
> David
^ permalink raw reply
* Re: [RFC/PATCH] vdpa/mlx5: Fix buffer length in create_direct_keys()
From: Christian Borntraeger @ 2026-07-06 12:59 UTC (permalink / raw)
To: Dragos Tatulea
Cc: Michael S . Tsirkin, Jason Wang, virtualization, linux-kernel
In-Reply-To: <d7272d8d-8146-4ed0-90d6-2a27eae5ab6e@nvidia.com>
Am 06.07.26 um 14:24 schrieb Dragos Tatulea:
>
>
> On 06.07.26 12:13, Christian Borntraeger wrote:
>>
>>
>> Am 06.07.26 um 12:01 schrieb Christian Borntraeger:
>>> We have seen in our CI the following KASAN message:
>>> BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core]
>>> Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764
>>> [...]
>>> [<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core]
>>> [<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core]
>>> [<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa]
>>> [<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa]
>>> [...]
>>> The buggy address is located 4128 bytes inside of
>>> allocated 4384-byte region [0000000176794000, 0000000176795120)
>>>
>>> So in essence we read 16 bytes beyond 4384-byte allocation.
>>> create_direct_keys calculates the pointer and length for in and out
>>> buffers.
>>> The size calculation for in includes the entire structure
>>> size (out + in + mtt[]) but the pointer passed to cmd_exec points only
>>> to the 'in' field, skipping the 'out' field.
>>>
>>> This causes mlx5_copy_to_msg() to read beyond the allocated buffer
>>> by sizeof(out) bytes when copying command data.
>>>
>>> Calculates the input size as sizeof(in) + mtt_array_size to match the
>>> pointer and allocation size.
>>>
>>> Fixes: 0071b138d44a ("vdpa/mlx5: Create direct MKEYs in parallel")
>>> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
>>> ---
>>> drivers/vdpa/mlx5/core/mr.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c
>>> index 6d02ccf9eb91..03fe7f5ca412 100644
>>> --- a/drivers/vdpa/mlx5/core/mr.c
>>> +++ b/drivers/vdpa/mlx5/core/mr.c
>>> @@ -233,7 +233,7 @@ static int create_direct_keys(struct mlx5_vdpa_dev *mvdev, struct mlx5_vdpa_mr *
>>> cmds[i].out = cmd_mem->out;
>>> cmds[i].outlen = sizeof(cmd_mem->out);
>>> cmds[i].in = cmd_mem->in;
>>> - cmds[i].inlen = struct_size(cmd_mem, mtt, mttcount);
>>> + cmds[i].inlen = sizeof(cmd_mem->in) + (mttcount * sizeof(cmd_mem->mtt[0]));
> Woops... Thanks for the catch. The fix is good.
>
>>
>> Assuming the fix is the correct fix, question is, if I should use the offset of in instead, e.g.
>>
>> cmds[i].inlen = struct_size(cmd_mem, mtt, mttcount) - offsetof(cmd_mem, in);
>>
>> to handle potential alignment and padding aspects.
>>
> Seems harder to read. Why not:
> sizeof(cmd_mem->in) + flex_array_size(cmd_mem, mtts, mttcount) ?
Can do that. I assume we do not have any implicit holes in the structure due to alignment? In
other words, sizeof(cmd_mem->in) can never be something like 20 (and then the flex array would
start at 24 to align 8 byte elements). If thats the case I will respin with your proposal.
^ permalink raw reply
* Re: [RFC/PATCH] vdpa/mlx5: Fix buffer length in create_direct_keys()
From: Dragos Tatulea @ 2026-07-06 12:24 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Michael S . Tsirkin, Jason Wang, virtualization, linux-kernel
In-Reply-To: <06b371e3-418c-41d8-8c06-1971cc24d8d4@linux.ibm.com>
On 06.07.26 12:13, Christian Borntraeger wrote:
>
>
> Am 06.07.26 um 12:01 schrieb Christian Borntraeger:
>> We have seen in our CI the following KASAN message:
>> BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core]
>> Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764
>> [...]
>> [<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core]
>> [<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core]
>> [<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa]
>> [<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa]
>> [...]
>> The buggy address is located 4128 bytes inside of
>> allocated 4384-byte region [0000000176794000, 0000000176795120)
>>
>> So in essence we read 16 bytes beyond 4384-byte allocation.
>> create_direct_keys calculates the pointer and length for in and out
>> buffers.
>> The size calculation for in includes the entire structure
>> size (out + in + mtt[]) but the pointer passed to cmd_exec points only
>> to the 'in' field, skipping the 'out' field.
>>
>> This causes mlx5_copy_to_msg() to read beyond the allocated buffer
>> by sizeof(out) bytes when copying command data.
>>
>> Calculates the input size as sizeof(in) + mtt_array_size to match the
>> pointer and allocation size.
>>
>> Fixes: 0071b138d44a ("vdpa/mlx5: Create direct MKEYs in parallel")
>> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
>> ---
>> drivers/vdpa/mlx5/core/mr.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c
>> index 6d02ccf9eb91..03fe7f5ca412 100644
>> --- a/drivers/vdpa/mlx5/core/mr.c
>> +++ b/drivers/vdpa/mlx5/core/mr.c
>> @@ -233,7 +233,7 @@ static int create_direct_keys(struct mlx5_vdpa_dev *mvdev, struct mlx5_vdpa_mr *
>> cmds[i].out = cmd_mem->out;
>> cmds[i].outlen = sizeof(cmd_mem->out);
>> cmds[i].in = cmd_mem->in;
>> - cmds[i].inlen = struct_size(cmd_mem, mtt, mttcount);
>> + cmds[i].inlen = sizeof(cmd_mem->in) + (mttcount * sizeof(cmd_mem->mtt[0]));
Woops... Thanks for the catch. The fix is good.
>
> Assuming the fix is the correct fix, question is, if I should use the offset of in instead, e.g.
>
> cmds[i].inlen = struct_size(cmd_mem, mtt, mttcount) - offsetof(cmd_mem, in);
>
> to handle potential alignment and padding aspects.
>
Seems harder to read. Why not:
sizeof(cmd_mem->in) + flex_array_size(cmd_mem, mtts, mttcount) ?
Thanks,
Dragos
^ permalink raw reply
* Re: [syzbot] Monthly virt report (Jun 2026)
From: Aleksandr Nogikh @ 2026-07-06 11:54 UTC (permalink / raw)
To: mawupeng
Cc: sgarzare, syzbot+listbf7b8eeeb8dda31d6de1, linux-kernel,
syzkaller-bugs, virtualization, mst, jasowang, xuanzhuo, eperezma,
stefanha, davem, edumazet, kuba, pabeni, horms, kvm, netdev
In-Reply-To: <0e51efaa-24b7-4a19-97f4-0669fd92d513@huawei.com>
On Mon, Jul 6, 2026 at 1:32 PM 'mawupeng' via syzkaller-bugs
<syzkaller-bugs@googlegroups.com> wrote:
>
>
>
> On 周一 2026-7-6 17:24, Stefano Garzarella wrote:
> > On Thu, 2 Jul 2026 at 04:55, mawupeng <mawupeng1@huawei.com> wrote:
> >> On 周四 2026-6-25 04:32, syzbot wrote:
> >>> Hello virt maintainers/developers,
> >>>
> >>> This is a 31-day syzbot report for the virt subsystem.
> >>> All related reports/information can be found at:
> >>> https://syzkaller.appspot.com/upstream/s/virt
> >>>
> >>> During the period, 0 new issues were detected and 0 were fixed.
> >>> In total, 5 issues are still open and 61 have already been fixed.
> >>> There are also 2 low-priority issues.
> >>>
> >>> Some of the still happening issues:
> >>>
> >>> Ref Crashes Repro Title
> >>> <1> 24 No WARNING: refcount bug in call_timer_fn (4)
> >>> https://syzkaller.appspot.com/bug?extid=07dcf509f4c013e25dc5
> >>> <2> 3 Yes memory leak in __vsock_create (2)
> >>> https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678
> >>
> >> Hi,
> >>
> >> This is regarding the still-open "memory leak in __vsock_create (2)"
> >> bug (#2 in the monthly virt report, extid 1b2c9c4a0f8708082678):
> >> https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678
> >>
> >> I spent some time analyzing the root cause and the previous fix
> >> attempt; below is a summary and a direction that tested out.
> >
> > [...]
> >
> >>
> >> I'm not subscribed to follow the list at full volume; happy to send a
> >> formal patch (with the af_vsock.h / pending_work changes folded in)
> >> if the direction looks right to the maintainers.
> >
> > Yes, please, a formal patch with a great commit message is much better
> > than a long text to read IMO.
>
> Thanks for replying.
>
> As we conducted more thorough testing and further analysis of our own fix,
> we found that it is not as comprehensive as the existing AI-generated fix
> provided[1].
>
> Could you please let us know if there are any issues with this AI-generated fix?
>
> [1]: https://syzkaller.appspot.com/ai_job?id=cd978d21-2110-4f57-9525-d7d91c4a7e02
I'll chime in from the syzbot side.
If anything is missing, please let us know :)
Otherwise, please note that the bot can incorporate code review notes
and, once the patch is ready, submit it to the LKML:
https://github.com/google/syzkaller/blob/master/docs/syzbot_ai_patches.md
Best Regards,
Aleksandr
>
> >
> > Thanks,
> > Stefano
> >
> >
>
^ permalink raw reply
* Re: [syzbot] Monthly virt report (Jun 2026)
From: mawupeng @ 2026-07-06 11:31 UTC (permalink / raw)
To: sgarzare
Cc: mawupeng1, syzbot+listbf7b8eeeb8dda31d6de1, linux-kernel,
syzkaller-bugs, virtualization, mst, jasowang, xuanzhuo, eperezma,
stefanha, davem, edumazet, kuba, pabeni, horms, kvm, netdev
In-Reply-To: <CAGxU2F582RpWGOUxTU783zZuxWj7e4eZtiDcNdUmWobLSFSq2g@mail.gmail.com>
On 周一 2026-7-6 17:24, Stefano Garzarella wrote:
> On Thu, 2 Jul 2026 at 04:55, mawupeng <mawupeng1@huawei.com> wrote:
>> On 周四 2026-6-25 04:32, syzbot wrote:
>>> Hello virt maintainers/developers,
>>>
>>> This is a 31-day syzbot report for the virt subsystem.
>>> All related reports/information can be found at:
>>> https://syzkaller.appspot.com/upstream/s/virt
>>>
>>> During the period, 0 new issues were detected and 0 were fixed.
>>> In total, 5 issues are still open and 61 have already been fixed.
>>> There are also 2 low-priority issues.
>>>
>>> Some of the still happening issues:
>>>
>>> Ref Crashes Repro Title
>>> <1> 24 No WARNING: refcount bug in call_timer_fn (4)
>>> https://syzkaller.appspot.com/bug?extid=07dcf509f4c013e25dc5
>>> <2> 3 Yes memory leak in __vsock_create (2)
>>> https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678
>>
>> Hi,
>>
>> This is regarding the still-open "memory leak in __vsock_create (2)"
>> bug (#2 in the monthly virt report, extid 1b2c9c4a0f8708082678):
>> https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678
>>
>> I spent some time analyzing the root cause and the previous fix
>> attempt; below is a summary and a direction that tested out.
>
> [...]
>
>>
>> I'm not subscribed to follow the list at full volume; happy to send a
>> formal patch (with the af_vsock.h / pending_work changes folded in)
>> if the direction looks right to the maintainers.
>
> Yes, please, a formal patch with a great commit message is much better
> than a long text to read IMO.
Thanks for replying.
As we conducted more thorough testing and further analysis of our own fix,
we found that it is not as comprehensive as the existing AI-generated fix
provided[1].
Could you please let us know if there are any issues with this AI-generated fix?
[1]: https://syzkaller.appspot.com/ai_job?id=cd978d21-2110-4f57-9525-d7d91c4a7e02
>
> Thanks,
> Stefano
>
>
^ permalink raw reply
* Re: [RFC/PATCH] vdpa/mlx5: Fix buffer length in create_direct_keys()
From: Christian Borntraeger @ 2026-07-06 10:13 UTC (permalink / raw)
To: Dragos Tatulea
Cc: Michael S . Tsirkin, Jason Wang, virtualization, linux-kernel
In-Reply-To: <20260706100129.1541140-1-borntraeger@linux.ibm.com>
Am 06.07.26 um 12:01 schrieb Christian Borntraeger:
> We have seen in our CI the following KASAN message:
> BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core]
> Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764
> [...]
> [<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core]
> [<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core]
> [<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa]
> [<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa]
> [...]
> The buggy address is located 4128 bytes inside of
> allocated 4384-byte region [0000000176794000, 0000000176795120)
>
> So in essence we read 16 bytes beyond 4384-byte allocation.
> create_direct_keys calculates the pointer and length for in and out
> buffers.
> The size calculation for in includes the entire structure
> size (out + in + mtt[]) but the pointer passed to cmd_exec points only
> to the 'in' field, skipping the 'out' field.
>
> This causes mlx5_copy_to_msg() to read beyond the allocated buffer
> by sizeof(out) bytes when copying command data.
>
> Calculates the input size as sizeof(in) + mtt_array_size to match the
> pointer and allocation size.
>
> Fixes: 0071b138d44a ("vdpa/mlx5: Create direct MKEYs in parallel")
> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
> ---
> drivers/vdpa/mlx5/core/mr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c
> index 6d02ccf9eb91..03fe7f5ca412 100644
> --- a/drivers/vdpa/mlx5/core/mr.c
> +++ b/drivers/vdpa/mlx5/core/mr.c
> @@ -233,7 +233,7 @@ static int create_direct_keys(struct mlx5_vdpa_dev *mvdev, struct mlx5_vdpa_mr *
> cmds[i].out = cmd_mem->out;
> cmds[i].outlen = sizeof(cmd_mem->out);
> cmds[i].in = cmd_mem->in;
> - cmds[i].inlen = struct_size(cmd_mem, mtt, mttcount);
> + cmds[i].inlen = sizeof(cmd_mem->in) + (mttcount * sizeof(cmd_mem->mtt[0]));
Assuming the fix is the correct fix, question is, if I should use the offset of in instead, e.g.
cmds[i].inlen = struct_size(cmd_mem, mtt, mttcount) - offsetof(cmd_mem, in);
to handle potential alignment and padding aspects.
^ permalink raw reply
* [RFC/PATCH] vdpa/mlx5: Fix buffer length in create_direct_keys()
From: Christian Borntraeger @ 2026-07-06 10:01 UTC (permalink / raw)
To: Dragos Tatulea
Cc: Michael S . Tsirkin, Jason Wang, virtualization, linux-kernel,
Christian Borntraeger
We have seen in our CI the following KASAN message:
BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core]
Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764
[...]
[<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core]
[<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core]
[<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa]
[<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa]
[...]
The buggy address is located 4128 bytes inside of
allocated 4384-byte region [0000000176794000, 0000000176795120)
So in essence we read 16 bytes beyond 4384-byte allocation.
create_direct_keys calculates the pointer and length for in and out
buffers.
The size calculation for in includes the entire structure
size (out + in + mtt[]) but the pointer passed to cmd_exec points only
to the 'in' field, skipping the 'out' field.
This causes mlx5_copy_to_msg() to read beyond the allocated buffer
by sizeof(out) bytes when copying command data.
Calculates the input size as sizeof(in) + mtt_array_size to match the
pointer and allocation size.
Fixes: 0071b138d44a ("vdpa/mlx5: Create direct MKEYs in parallel")
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
---
drivers/vdpa/mlx5/core/mr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c
index 6d02ccf9eb91..03fe7f5ca412 100644
--- a/drivers/vdpa/mlx5/core/mr.c
+++ b/drivers/vdpa/mlx5/core/mr.c
@@ -233,7 +233,7 @@ static int create_direct_keys(struct mlx5_vdpa_dev *mvdev, struct mlx5_vdpa_mr *
cmds[i].out = cmd_mem->out;
cmds[i].outlen = sizeof(cmd_mem->out);
cmds[i].in = cmd_mem->in;
- cmds[i].inlen = struct_size(cmd_mem, mtt, mttcount);
+ cmds[i].inlen = sizeof(cmd_mem->in) + (mttcount * sizeof(cmd_mem->mtt[0]));
fill_create_direct_mr(mvdev, dmr, cmd_mem);
--
2.53.0
^ permalink raw reply related
* Re: [syzbot] Monthly virt report (Jun 2026)
From: Stefano Garzarella @ 2026-07-06 9:24 UTC (permalink / raw)
To: mawupeng
Cc: syzbot+listbf7b8eeeb8dda31d6de1, linux-kernel, syzkaller-bugs,
virtualization, mst, jasowang, xuanzhuo, eperezma, stefanha,
davem, edumazet, kuba, pabeni, horms, kvm, netdev
In-Reply-To: <d1e9d389-affa-4d12-aaf7-3fcf3218966c@huawei.com>
On Thu, 2 Jul 2026 at 04:55, mawupeng <mawupeng1@huawei.com> wrote:
> On 周四 2026-6-25 04:32, syzbot wrote:
> > Hello virt maintainers/developers,
> >
> > This is a 31-day syzbot report for the virt subsystem.
> > All related reports/information can be found at:
> > https://syzkaller.appspot.com/upstream/s/virt
> >
> > During the period, 0 new issues were detected and 0 were fixed.
> > In total, 5 issues are still open and 61 have already been fixed.
> > There are also 2 low-priority issues.
> >
> > Some of the still happening issues:
> >
> > Ref Crashes Repro Title
> > <1> 24 No WARNING: refcount bug in call_timer_fn (4)
> > https://syzkaller.appspot.com/bug?extid=07dcf509f4c013e25dc5
> > <2> 3 Yes memory leak in __vsock_create (2)
> > https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678
>
> Hi,
>
> This is regarding the still-open "memory leak in __vsock_create (2)"
> bug (#2 in the monthly virt report, extid 1b2c9c4a0f8708082678):
> https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678
>
> I spent some time analyzing the root cause and the previous fix
> attempt; below is a summary and a direction that tested out.
[...]
>
> I'm not subscribed to follow the list at full volume; happy to send a
> formal patch (with the af_vsock.h / pending_work changes folded in)
> if the direction looks right to the maintainers.
Yes, please, a formal patch with a great commit message is much better
than a long text to read IMO.
Thanks,
Stefano
^ permalink raw reply
* Re: [PATCH v2] virtio_balloon: prime stats vq after virtio_device_ready()
From: David Hildenbrand (Arm) @ 2026-07-06 8:57 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Adam Litke, Rusty Russell, virtualization, Andrew Morton,
linux-mm
In-Reply-To: <20260706044122-mutt-send-email-mst@kernel.org>
On 7/6/26 10:43, Michael S. Tsirkin wrote:
> On Mon, Jul 06, 2026 at 10:38:18AM +0200, David Hildenbrand (Arm) wrote:
>>>
>>> Yes.
>>>
>>>
>>> Why not?
>>
>> I was wondering whether the spec would state something about that.
>
> Sorry I do not get the question. Virtio API expects
> callers to serialize calls for each VQ. So this just prevents the work
> from running and accessing the VQ while probe calls add_buf/kick.
> I'll add a comment explaining that.
> But it has nothing to do with the spec.
The device is clearly not properly initialized yet.
Yet, we expect that we get a stats_request() callback that would try to
queue_work(). And IIUC, the stats_request() will be directly issued by the device.
In QEMU, that would mean that balloon_stats_poll_cb() runs, which would do a
if (s->stats_vq_elem == NULL) {
...
return
}
virtqueue_push(s->svq, s->stats_vq_elem, 0);
virtio_notify(vdev, s->svq);
That's why I'm confused :)
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v2] virtio_balloon: prime stats vq after virtio_device_ready()
From: Michael S. Tsirkin @ 2026-07-06 8:43 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: linux-kernel, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Adam Litke, Rusty Russell, virtualization, Andrew Morton,
linux-mm
In-Reply-To: <6b8e4ad3-6909-4d0a-89a4-104a5ad9fe79@kernel.org>
On Mon, Jul 06, 2026 at 10:38:18AM +0200, David Hildenbrand (Arm) wrote:
> >>> - virtqueue_kick(vb->stats_vq);
> >>> + disable_work(&vb->update_balloon_stats_work);
> >>
> >> That's to stop the stats queue triggering stats_request() I assume?
> >
> > Yes.
> >
> >> Is that
> >> valid before we actually added+kicked ourselves?
> >
> > Why not?
>
> I was wondering whether the spec would state something about that.
Sorry I do not get the question. Virtio API expects
callers to serialize calls for each VQ. So this just prevents the work
from running and accessing the VQ while probe calls add_buf/kick.
I'll add a comment explaining that.
But it has nothing to do with the spec.
> >
> >> Also, can't we simply handle that in stats_request(), just ignoring it there?
> >
> > Then we'd need to maintain a special flag and I dislike that.
>
> I was hoping that we could use the device-ready indication, but there would be a
> small race window indeed.
>
> --
> Cheers,
>
> David
^ permalink raw reply
* Re: [PATCH v2] virtio_balloon: disable indirect descriptors
From: David Hildenbrand (Arm) @ 2026-07-06 8:43 UTC (permalink / raw)
To: Michael S. Tsirkin, linux-kernel
Cc: Jason Wang, Xuan Zhuo, Eugenio Pérez, Andrew Morton,
Alexander Duyck, virtualization
In-Reply-To: <73fac8a629fd9aca7bb3265ac243a769c28af25d.1783232420.git.mst@redhat.com>
On 7/5/26 08:24, Michael S. Tsirkin wrote:
> The page reporting callback submits an sg list to the reporting
> virtqueue. With VIRTIO_RING_F_INDIRECT_DESC negotiated and
> total_sg > 1 (which it typically is), virtqueue_add reports it to the
> host by allocating an indirect descriptor via kmalloc(GFP_KERNEL).
>
> This is not pretty: the reporting worker isolates potentially hundreds
> of MB of free pages from the buddy allocator (reported pages are at
> least pageblock_order, and the sg can contain up to
> PAGE_REPORTING_CAPACITY entries of varying orders). As the result,
> very theoretically, the kmalloc might trigger OOM when we have in fact a
> ton of free memory.
>
> Clear VIRTIO_RING_F_INDIRECT_DESC, to avoid using indirect descriptors.
>
> Fixes: b0c504f15471 ("virtio-balloon: add support for providing free page reports to host")
> Assisted-by: Claude:claude-opus-4-6
> Acked-by: David Hildenbrand (Arm) <david@kernel.org>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>
>
> I assume I'm the one merging this?
>
I would think so :)
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH] timekeeping: Document monotonic raw timestamps in snapshots correctly
From: Thomas Weißschuh @ 2026-07-06 8:42 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, David Woodhouse, Miroslav Lichvar, John Stultz,
Stephen Boyd, Anna-Maria Behnsen, Frederic Weisbecker,
Arthur Kiyanovski, Rodolfo Giometti, Vincent Donnefort,
Marc Zyngier, Oliver Upton, kvmarm, Oliver Upton, Richard Cochran,
netdev, Takashi Iwai, Miri Korenblit, Johannes Berg, Jacob Keller,
Tony Nguyen, Saeed Mahameed, Peter Hilber, Michael S. Tsirkin,
virtualization, linux-wireless, linux-sound
In-Reply-To: <87wlv9k3wz.ffs@fw13>
On Sun, Jul 05, 2026 at 02:38:04PM +0200, Thomas Gleixner wrote:
> The comments related to raw monotonic timestamps for the various
> snapshot mechanisms in code and struct documentation are ambiguous. They
> reference them as CLOCK_MONOTONIC_RAW timestamps, but with the arrival
> of AUX clocks that's not longer correct.
>
> The raw monotonic timestamps only represent CLOCK_MONOTONIC_RAW for the
> system time clock IDs, i.e. REALTIME, MONOTONIC, BOOTTIME, TAI.
>
> For AUX clocks they refer to the monotonic raw clock which is related to
> the individual AUX clocks. These monotonic raw timestamps have the same
> conversion factor as CLOCK_MONOTONIC_RAW, but differ from that by an
> offset:
>
> MONORAW(AUX$N) = MONORAW(SYSTEM) + OFFSET(AUX$N)
>
> The offset is established when a AUX clock is enabled and stays constant
> for the lifetime of the AUX clock.
>
> Update the comments so they reflect reality.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Reported-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Thanks!
Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
(...)
^ permalink raw reply
* Re: [PATCH v2] virtio_balloon: prime stats vq after virtio_device_ready()
From: David Hildenbrand (Arm) @ 2026-07-06 8:38 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Adam Litke, Rusty Russell, virtualization, Andrew Morton,
linux-mm
In-Reply-To: <20260706042207-mutt-send-email-mst@kernel.org>
>>> - virtqueue_kick(vb->stats_vq);
>>> + disable_work(&vb->update_balloon_stats_work);
>>
>> That's to stop the stats queue triggering stats_request() I assume?
>
> Yes.
>
>> Is that
>> valid before we actually added+kicked ourselves?
>
> Why not?
I was wondering whether the spec would state something about that.
>
>> Also, can't we simply handle that in stats_request(), just ignoring it there?
>
> Then we'd need to maintain a special flag and I dislike that.
I was hoping that we could use the device-ready indication, but there would be a
small race window indeed.
--
Cheers,
David
^ permalink raw reply
* [PATCH] iommu/virtio: reject short event buffers
From: raoxu @ 2026-07-06 8:31 UTC (permalink / raw)
To: jpb; +Cc: joro, will, robin.murphy, virtualization, iommu, linux-kernel,
raoxu
From: Xu Rao <raoxu@uniontech.com>
The event queue uses fixed-size buffers for struct viommu_event. The
device-reported used length is currently only checked for oversized
buffers, so a short used buffer can still be passed to the fault
handler.
In that case the handler parses fields that were not written by the
device for this event, potentially using stale data from a previous
event and reporting a bogus fault.
Reject any event buffer whose used length is not exactly the expected
event size. Still recycle the buffer back to the event queue so a bad
event does not permanently shrink the queue.
Signed-off-by: Xu Rao <raoxu@uniontech.com>
---
drivers/iommu/virtio-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 587fc13197f1..3ace4a6dd02a 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -635,7 +635,7 @@ static void viommu_event_handler(struct virtqueue *vq)
struct viommu_dev *viommu = vq->vdev->priv;
while ((evt = virtqueue_get_buf(vq, &len)) != NULL) {
- if (len > sizeof(*evt)) {
+ if (len != sizeof(*evt)) {
dev_err(viommu->dev,
"invalid event buffer (len %u != %zu)\n",
len, sizeof(*evt));
--
2.50.1
^ permalink raw reply related
* Re: [PATCH v2] virtio_balloon: prime stats vq after virtio_device_ready()
From: Michael S. Tsirkin @ 2026-07-06 8:23 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: linux-kernel, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Adam Litke, Rusty Russell, virtualization, Andrew Morton,
linux-mm
In-Reply-To: <13794c5e-375a-4fc5-84b4-a637d077f8a0@kernel.org>
On Mon, Jul 06, 2026 at 09:28:50AM +0200, David Hildenbrand (Arm) wrote:
> On 7/5/26 21:12, Michael S. Tsirkin wrote:
> > The virtio spec requires the driver not to kick the device before
> > DRIVER_OK is set. init_vqs() primes the stats virtqueue with a buffer
> > and kicks the device before virtio_device_ready() is called in
> > virtballoon_probe(), violating this requirement.
> >
> > Further, if the device responds to the early kick by processing the
> > buffer before DRIVER_OK, stats_request() fires and queues
> > update_balloon_stats_work. Should probe then fail and free vb, the work
> > runs against freed memory.
> >
> > To fix, move buffer setup to after DRIVER_OK. Be careful to
> > disable update_balloon_stats_work while this is going on,
> > to make sure it does not race with the setup.
> >
> > setup_vqs() warns but does not fail probe or restore if
> > virtqueue_add_outbuf() fails; the call never actually fails in these
> > contexts since the queue is freshly initialized and empty.
> >
> > Testing: tested that stats still work after the change.
> >
> > Fixes: 9564e138b1f6 ("virtio: Add memory statistics reporting to the balloon driver (V4)")
> > Reported-by: Sashiko:gemini-3.1-pro-preview
> > Cc: David Hildenbrand <david@kernel.org>
> > Assisted-by: Claude:claude-sonnet-4-6
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> >
> > changes from v1:
> > check that work enable/disable is balanced
> > explain how add buf never fails in probe/restore
> >
> > drivers/virtio/virtio_balloon.c | 50 +++++++++++++++++++++------------
> > 1 file changed, 32 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> > index 088b3a0e6ce6..bc0a2b19ca7d 100644
> > --- a/drivers/virtio/virtio_balloon.c
> > +++ b/drivers/virtio/virtio_balloon.c
> > @@ -611,25 +611,8 @@ static int init_vqs(struct virtio_balloon *vb)
> > vb->inflate_vq = vqs[VIRTIO_BALLOON_VQ_INFLATE];
> > vb->deflate_vq = vqs[VIRTIO_BALLOON_VQ_DEFLATE];
> > if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
> > - struct scatterlist sg;
> > - unsigned int num_stats;
> > vb->stats_vq = vqs[VIRTIO_BALLOON_VQ_STATS];
> > -
> > - /*
> > - * Prime this virtqueue with one buffer so the hypervisor can
> > - * use it to signal us later (it can't be broken yet!).
> > - */
> > - num_stats = update_balloon_stats(vb);
> > -
> > - sg_init_one(&sg, vb->stats, sizeof(vb->stats[0]) * num_stats);
> > - err = virtqueue_add_outbuf(vb->stats_vq, &sg, 1, vb,
> > - GFP_KERNEL);
> > - if (err) {
> > - dev_warn(&vb->vdev->dev, "%s: add stat_vq failed\n",
> > - __func__);
> > - return err;
> > - }
> > - virtqueue_kick(vb->stats_vq);
> > + disable_work(&vb->update_balloon_stats_work);
>
> That's to stop the stats queue triggering stats_request() I assume?
Yes.
> Is that
> valid before we actually added+kicked ourselves?
Why not?
> Also, can't we simply handle that in stats_request(), just ignoring it there?
Then we'd need to maintain a special flag and I dislike that.
> Then we wouldn't have to go through the siable + enable.
We'd still need to flip the flag on/off.
> > }
> >
> > if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT))
> > @@ -916,6 +899,33 @@ static int virtio_balloon_register_shrinker(struct virtio_balloon *vb)
> > return 0;
> > }
> >
> > +static void setup_vqs(struct virtio_balloon *vb)
> > +{
> > + struct scatterlist sg;
> > + unsigned int num_stats;
> > + bool ret;
> > +
> > + if (!virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ))
> > + return;
> > +
> > + /*
> > + * Prime this virtqueue with one buffer so the hypervisor can
> > + * use it to signal us later (it can't be broken yet!).
> > + */
> > + num_stats = update_balloon_stats(vb);
> > + sg_init_one(&sg, vb->stats, sizeof(vb->stats[0]) * num_stats);
> > + if (virtqueue_add_outbuf(vb->stats_vq, &sg, 1, vb, GFP_KERNEL)) {
> > + dev_warn(&vb->vdev->dev, "%s: add stat_vq failed\n", __func__);
> > + return;
> > + }
> > + virtqueue_kick(vb->stats_vq);
> > +
> > + ret = enable_and_queue_work(system_freezable_wq,
> > + &vb->update_balloon_stats_work);
> > + /* Make sure we balanced enable/disable, or we won't report stats. */
> > + BUG_ON(!ret);
>
> A WARN_ON_ONCE() should be good enough here, no need to crash the kernel (no new
> BUG_ON's).
Will do, thanks!
> --
> Cheers,
>
> David
^ permalink raw reply
* Re: [PATCH v2] virtio_balloon: prime stats vq after virtio_device_ready()
From: David Hildenbrand (Arm) @ 2026-07-06 7:28 UTC (permalink / raw)
To: Michael S. Tsirkin, linux-kernel
Cc: Jason Wang, Xuan Zhuo, Eugenio Pérez, Adam Litke,
Rusty Russell, virtualization, Andrew Morton, linux-mm
In-Reply-To: <2f0d0de033f3005d3b985883be3e5cf37b3f6c42.1783278596.git.mst@redhat.com>
On 7/5/26 21:12, Michael S. Tsirkin wrote:
> The virtio spec requires the driver not to kick the device before
> DRIVER_OK is set. init_vqs() primes the stats virtqueue with a buffer
> and kicks the device before virtio_device_ready() is called in
> virtballoon_probe(), violating this requirement.
>
> Further, if the device responds to the early kick by processing the
> buffer before DRIVER_OK, stats_request() fires and queues
> update_balloon_stats_work. Should probe then fail and free vb, the work
> runs against freed memory.
>
> To fix, move buffer setup to after DRIVER_OK. Be careful to
> disable update_balloon_stats_work while this is going on,
> to make sure it does not race with the setup.
>
> setup_vqs() warns but does not fail probe or restore if
> virtqueue_add_outbuf() fails; the call never actually fails in these
> contexts since the queue is freshly initialized and empty.
>
> Testing: tested that stats still work after the change.
>
> Fixes: 9564e138b1f6 ("virtio: Add memory statistics reporting to the balloon driver (V4)")
> Reported-by: Sashiko:gemini-3.1-pro-preview
> Cc: David Hildenbrand <david@kernel.org>
> Assisted-by: Claude:claude-sonnet-4-6
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>
> changes from v1:
> check that work enable/disable is balanced
> explain how add buf never fails in probe/restore
>
> drivers/virtio/virtio_balloon.c | 50 +++++++++++++++++++++------------
> 1 file changed, 32 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 088b3a0e6ce6..bc0a2b19ca7d 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -611,25 +611,8 @@ static int init_vqs(struct virtio_balloon *vb)
> vb->inflate_vq = vqs[VIRTIO_BALLOON_VQ_INFLATE];
> vb->deflate_vq = vqs[VIRTIO_BALLOON_VQ_DEFLATE];
> if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
> - struct scatterlist sg;
> - unsigned int num_stats;
> vb->stats_vq = vqs[VIRTIO_BALLOON_VQ_STATS];
> -
> - /*
> - * Prime this virtqueue with one buffer so the hypervisor can
> - * use it to signal us later (it can't be broken yet!).
> - */
> - num_stats = update_balloon_stats(vb);
> -
> - sg_init_one(&sg, vb->stats, sizeof(vb->stats[0]) * num_stats);
> - err = virtqueue_add_outbuf(vb->stats_vq, &sg, 1, vb,
> - GFP_KERNEL);
> - if (err) {
> - dev_warn(&vb->vdev->dev, "%s: add stat_vq failed\n",
> - __func__);
> - return err;
> - }
> - virtqueue_kick(vb->stats_vq);
> + disable_work(&vb->update_balloon_stats_work);
That's to stop the stats queue triggering stats_request() I assume? Is that
valid before we actually added+kicked ourselves?
Also, can't we simply handle that in stats_request(), just ignoring it there?
Then we wouldn't have to go through the siable + enable.
> }
>
> if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT))
> @@ -916,6 +899,33 @@ static int virtio_balloon_register_shrinker(struct virtio_balloon *vb)
> return 0;
> }
>
> +static void setup_vqs(struct virtio_balloon *vb)
> +{
> + struct scatterlist sg;
> + unsigned int num_stats;
> + bool ret;
> +
> + if (!virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ))
> + return;
> +
> + /*
> + * Prime this virtqueue with one buffer so the hypervisor can
> + * use it to signal us later (it can't be broken yet!).
> + */
> + num_stats = update_balloon_stats(vb);
> + sg_init_one(&sg, vb->stats, sizeof(vb->stats[0]) * num_stats);
> + if (virtqueue_add_outbuf(vb->stats_vq, &sg, 1, vb, GFP_KERNEL)) {
> + dev_warn(&vb->vdev->dev, "%s: add stat_vq failed\n", __func__);
> + return;
> + }
> + virtqueue_kick(vb->stats_vq);
> +
> + ret = enable_and_queue_work(system_freezable_wq,
> + &vb->update_balloon_stats_work);
> + /* Make sure we balanced enable/disable, or we won't report stats. */
> + BUG_ON(!ret);
A WARN_ON_ONCE() should be good enough here, no need to crash the kernel (no new
BUG_ON's).
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH] vdpa/mlx5: fix wrong MLX5_ADDR_OF struct type in alloc_inout()
From: Dragos Tatulea @ 2026-07-06 7:09 UTC (permalink / raw)
To: lirongqing, Michael S . Tsirkin, Jason Wang, Xuan Zhuo,
Eugenio Pérez, Cindy Lu, Kees Cook, virtualization,
linux-kernel
In-Reply-To: <20260706060902.2341-1-lirongqing@baidu.com>
On 06.07.26 08:09, lirongqing wrote:
> From: Li RongQing <lirongqing@baidu.com>
>
> In alloc_inout(), the qpc field offset was computed using
> MLX5_ADDR_OF(rst2init_qp_in, ...) in both the INIT2RTR_QP and
> RTR2RTS_QP cases. This is a copy-paste error: each case should use
> its own input structure type to get the correct qpc offset.
>
> Fix the INIT2RTR_QP case to use MLX5_ADDR_OF(init2rtr_qp_in, ...)
> and the RTR2RTS_QP case to use MLX5_ADDR_OF(rtr2rts_qp_in, ...).
>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> ---
> drivers/vdpa/mlx5/net/mlx5_vnet.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> index ad0d5fbb..eb431a1 100644
> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> @@ -1080,7 +1080,7 @@ static void alloc_inout(struct mlx5_vdpa_net *ndev, int cmd, void **in, int *inl
> MLX5_SET(init2rtr_qp_in, *in, opcode, cmd);
> MLX5_SET(init2rtr_qp_in, *in, uid, ndev->mvdev.res.uid);
> MLX5_SET(init2rtr_qp_in, *in, qpn, qpn);
> - qpc = MLX5_ADDR_OF(rst2init_qp_in, *in, qpc);
> + qpc = MLX5_ADDR_OF(init2rtr_qp_in, *in, qpc);
> MLX5_SET(qpc, qpc, mtu, MLX5_QPC_MTU_256_BYTES);
> MLX5_SET(qpc, qpc, log_msg_max, 30);
> MLX5_SET(qpc, qpc, remote_qpn, rqpn);
> @@ -1098,7 +1098,7 @@ static void alloc_inout(struct mlx5_vdpa_net *ndev, int cmd, void **in, int *inl
> MLX5_SET(rtr2rts_qp_in, *in, opcode, cmd);
> MLX5_SET(rtr2rts_qp_in, *in, uid, ndev->mvdev.res.uid);
> MLX5_SET(rtr2rts_qp_in, *in, qpn, qpn);
> - qpc = MLX5_ADDR_OF(rst2init_qp_in, *in, qpc);
> + qpc = MLX5_ADDR_OF(rtr2rts_qp_in, *in, qpc);
> pp = MLX5_ADDR_OF(qpc, qpc, primary_address_path);
> MLX5_SET(ads, pp, ack_timeout, 14);
> MLX5_SET(qpc, qpc, retry_count, 7);
Thanks for the catch. Luckily those structs have the same layout.
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Thanks,
Dragos
^ permalink raw reply
* [PATCH] vdpa/mlx5: fix wrong MLX5_ADDR_OF struct type in alloc_inout()
From: lirongqing @ 2026-07-06 6:09 UTC (permalink / raw)
To: Dragos Tatulea, Michael S . Tsirkin, Jason Wang, Xuan Zhuo,
Eugenio Pérez, Cindy Lu, Kees Cook, virtualization,
linux-kernel
Cc: Li RongQing
From: Li RongQing <lirongqing@baidu.com>
In alloc_inout(), the qpc field offset was computed using
MLX5_ADDR_OF(rst2init_qp_in, ...) in both the INIT2RTR_QP and
RTR2RTS_QP cases. This is a copy-paste error: each case should use
its own input structure type to get the correct qpc offset.
Fix the INIT2RTR_QP case to use MLX5_ADDR_OF(init2rtr_qp_in, ...)
and the RTR2RTS_QP case to use MLX5_ADDR_OF(rtr2rts_qp_in, ...).
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index ad0d5fbb..eb431a1 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -1080,7 +1080,7 @@ static void alloc_inout(struct mlx5_vdpa_net *ndev, int cmd, void **in, int *inl
MLX5_SET(init2rtr_qp_in, *in, opcode, cmd);
MLX5_SET(init2rtr_qp_in, *in, uid, ndev->mvdev.res.uid);
MLX5_SET(init2rtr_qp_in, *in, qpn, qpn);
- qpc = MLX5_ADDR_OF(rst2init_qp_in, *in, qpc);
+ qpc = MLX5_ADDR_OF(init2rtr_qp_in, *in, qpc);
MLX5_SET(qpc, qpc, mtu, MLX5_QPC_MTU_256_BYTES);
MLX5_SET(qpc, qpc, log_msg_max, 30);
MLX5_SET(qpc, qpc, remote_qpn, rqpn);
@@ -1098,7 +1098,7 @@ static void alloc_inout(struct mlx5_vdpa_net *ndev, int cmd, void **in, int *inl
MLX5_SET(rtr2rts_qp_in, *in, opcode, cmd);
MLX5_SET(rtr2rts_qp_in, *in, uid, ndev->mvdev.res.uid);
MLX5_SET(rtr2rts_qp_in, *in, qpn, qpn);
- qpc = MLX5_ADDR_OF(rst2init_qp_in, *in, qpc);
+ qpc = MLX5_ADDR_OF(rtr2rts_qp_in, *in, qpc);
pp = MLX5_ADDR_OF(qpc, qpc, primary_address_path);
MLX5_SET(ads, pp, ack_timeout, 14);
MLX5_SET(qpc, qpc, retry_count, 7);
--
2.9.4
^ permalink raw reply related
* Re: [PATCH] i2c: virtio: Reset virtqueue before freeing interrupted requests
From: Viresh Kumar @ 2026-07-06 4:08 UTC (permalink / raw)
To: Guangshuo Li, Gavin Li
Cc: Chen, Jian Jun, Andi Shyti, linux-i2c, virtualization,
linux-kernel
In-Reply-To: <20260705155925.292765-1-lgs201920130244@gmail.com>
On 05-07-26, 23:59, Guangshuo Li wrote:
> virtio_i2c_complete_reqs() waits for each queued request to complete
> before releasing the per-message DMA-safe buffer. The request array is
> then freed by virtio_i2c_xfer().
>
> After wait_for_completion_interruptible() was introduced, the wait can
> return before the current request has completed. In that case, the
> request and the remaining requests may still be owned by the virtqueue
> and may still be completed by the device later.
>
> The error path nevertheless continues to release each message buffer and
> virtio_i2c_xfer() frees the request array. A later device completion can
> then write to freed request memory or call complete() on a freed
> completion object.
>
> Reset the virtqueue when the wait is interrupted so that outstanding
> buffers are recovered before the request array and message buffers are
> freed.
>
> Fixes: a663b3c47ab1 ("i2c: virtio: Avoid hang by using interruptible completion wait")
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---
> drivers/i2c/busses/i2c-virtio.c | 13 ++++++++++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c
> index 5da6fef92bec..6ef09eda3ed0 100644
> --- a/drivers/i2c/busses/i2c-virtio.c
> +++ b/drivers/i2c/busses/i2c-virtio.c
> @@ -117,12 +117,19 @@ static int virtio_i2c_complete_reqs(struct virtqueue *vq,
> struct virtio_i2c_req *req = &reqs[i];
>
> if (!failed) {
> - if (wait_for_completion_interruptible(&req->completion))
> + if (wait_for_completion_interruptible(&req->completion)) {
> + /*
> + * The remaining buffers may still be owned by
> + * the device. Reset the virtqueue before freeing
> + * the request array and message buffers.
> + */
> + virtqueue_reset(vq, NULL, NULL);
> failed = true;
> - else if (req->in_hdr.status != VIRTIO_I2C_MSG_OK)
> + } else if (req->in_hdr.status != VIRTIO_I2C_MSG_OK) {
> failed = true;
> - else
> + } else {
> j++;
> + }
> }
>
> i2c_put_dma_safe_msg_buf(reqs[i].buf, &msgs[i], !failed);
+ Gavin, who was also trying to solve this path recently.
https://lore.kernel.org/all/20260610155834.79207-1-gavin.li@samsara.com/
--
viresh
^ 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