Re: [PATCH 0/4] migration: Remove extra type-checking from vmstate macros

[Peter Xu <peterx@redhat.com>]

On Thu, Jul 30, 2026 at 10:09:30AM -0400, Peter Xu wrote:
> On Wed, Jul 29, 2026 at 07:52:23PM -0300, Fabiano Rosas wrote:
> > Hi, this is basically what I ranted about in:
> > https://lore.kernel.org/r/87jyqeomqz.fsf@suse.de
> > 
> > I'm replacing the per-integer-size type checks with a single "int that
> > fits in 32bit" check. This allows several lines of duplicated code to
> > be removed.
> > 
> > I haven't changed the macro names in the device code yet. If this
> > series gets positive feedback then I'll send per-subsystem patches
> > doing that.
> > 
> > CI run: https://gitlab.com/farosas/qemu/-/pipelines/2716814081
> > Also tested:
> > - migration-test --full --thorough
> > - x86_64 compat run forwards and backwards for previous 3 QEMU releases
> > - s390x compat run forwards and backwards for previous 2 QEMU releases
> > - ppc64 compat run forwards and backwards for previous QEMU release
> > - migration-test smoke ASAN/UBSAN run
> > 
> > Fabiano Rosas (4):
> >   migration: Remove VMSTATE_ARRAY_INT32_UNSAFE
> >   migration: Introduce VMStateOffset
> >   migration: Remove redundant flags
> >   migration: Remove duplicate vmstate macros
> 
> Nice work!
> 
> I think I was only looking at VBUFFER side and I thought it was fine
> sticking with 32bit even signed or not, not a huge deal.  But cleaning up
> VARRAY whole thing together looks definitely an improvement.  I definitely
> like your version here.
> 
> I assume with your series I can drop both of my patches here, right?
> 
>   [PATCH v2 1/5] migration: Fix possible overflow in vmstate_handle_alloc()
>   https://lore.kernel.org/r/20260728210417.1925078-2-peterx@redhat.com
>   (I'll still respin with the rest)
> 
>   [PATCH] vhost/migration: Fix incorrect size used in inflight->addr in VMSD
>   https://lore.kernel.org/r/20260728153942.1891677-1-peterx@redhat.com
> 
> The only missing piece would be an multiply overflow check in
> vmstate_handle_alloc(), if you could add that check too while rewritting
> that in patch 1 then I think it'll cover all.
> 
> Vladimir's ask in the separate email makes sense: I wonder if we can also
> do one step further and merge VBUFFER into VARRAY.
> 
> The other trivial thing is, while looking, I found one trivial macro
> VMSTATE_PARTIAL_VBUFFER not used; can drop it altogether.

Now officially declare support for u64 on all these offsets, we also need
to double check on our alignment with security issues.

Similar reports will not be a bug anymore but results will be the same I
assume: it's anything the attacker can feed a u64 directly (instead of an
int32_t negative overflow), result is still failing a malloc() with
enormously large numbers, legally this time.

Do you still plan to work on finding per-user upper limit or whatever of
that kind?  I'd say time spent working on series like this worths more than
that, but I still want to check with you while looking at this solution.

I suppose with this, one option is we can close all tickets reporting
security issues while allocating with all u64 fields.

Thanks,

-- 
Peter Xu