All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Fabiano Rosas <farosas@suse.de>
Cc: qemu-devel@nongnu.org, Peter Maydell <peter.maydell@linaro.org>,
	"Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
Subject: Re: [PATCH v1] migration: Use QAPI_CLONE_MEMBERS in migrate_params_test_apply
Date: Fri, 24 Apr 2026 10:03:16 -0400	[thread overview]
Message-ID: <aet4JNhPwnbQA9DI@x1.local> (raw)
In-Reply-To: <20260414223718.23965-1-farosas@suse.de>

On Tue, Apr 14, 2026 at 07:37:18PM -0300, Fabiano Rosas wrote:
> Use QAPI_CLONE_MEMBERS instead of making an assignment. The QAPI
> method makes the handling of the TLS strings more intuitive because it
> clones them as well.
> 
> This also fixes a segfault when a NULL TLS option is accessed as part
> of a validation check for another option (e.g. in the zero-copy +
> multifd compression case). Details follow:
> 
> Currently, after copying s->parameters to the temporary
> MigrationParameters object before migrate_params_check(), the
> references in temporary object to the TLS options are dropped, either
> because:
> 
> a) the user set a new option, in which case that's fine as
>    s->parameters still holds the reference to the old memory or,
> 
> b) the user did not set a new option, in which case keeping the
>    references in the temporary object would later cause them to be
>    freed along with it, leading to double-free when s->parameters is
>    also freed later on.
> 
> In this second case, it was overlooked that the TLS options can be
> accessed already during migrate_params_check() as part of validation
> of another option. Those pointers should not have been cleared.
> 
> Using QAPI_CLONE_MEMBERS fixes the issue because the temporary object
> is not stealing a reference from s->parameters anymore.
> 
> Fixes: aed97f0563 ("migration: Normalize tls arguments")
> Reported-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
> Link: https://lore.kernel.org/r/a65a1049-9f19-460a-8e27-a62bb30d2727@maciej.szmigiero.name
> Reviewed-by: Peter Xu <peterx@redhat.com>
> Signed-off-by: Fabiano Rosas <farosas@suse.de>

Queued and added cc:stable.

-- 
Peter Xu



      parent reply	other threads:[~2026-04-24 14:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-14 22:37 [PATCH v1] migration: Use QAPI_CLONE_MEMBERS in migrate_params_test_apply Fabiano Rosas
2026-04-15 13:35 ` Maciej S. Szmigiero
2026-04-15 14:39 ` Fabiano Rosas
2026-04-16  9:23   ` Peter Maydell
2026-04-16 12:19     ` Fabiano Rosas
2026-04-16 12:21       ` Maciej S. Szmigiero
2026-04-16 13:05       ` Peter Xu
2026-04-24 14:03 ` Peter Xu [this message]

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=aet4JNhPwnbQA9DI@x1.local \
    --to=peterx@redhat.com \
    --cc=farosas@suse.de \
    --cc=mail@maciej.szmigiero.name \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

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

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