From 4daff81efb381d1138832648511218a646f8092e Mon Sep 17 00:00:00 2001 From: Peter Xu Date: Tue, 5 Nov 2024 13:27:25 -0500 Subject: [PATCH 1/2] migration: Check current_migration in migration_is_running() Report shows that commit 34a8892dec broke iotest 055: https://lore.kernel.org/r/b8806360-a2b6-4608-83a3-db67e264c733@linaro.org Denis Rastyogin reported more such issue: https://lore.kernel.org/r/20241107114256.106831-1-gerben@altlinux.org In this merge, the migration_is_idle() function was replaced with migrate_is_running(). However, the null pointer check for `s` was removed, leading to a dereference of `s` when using qemu-system-x86_64 -hda *.vdi. When replacing migration_is_idle() with "!migration_is_running()", it was overlooked that the idle helper also checks for current_migration being available first. Sample stack dump: migration_is_running is_busy migrate_add_blocker_modes migrate_add_blocker_normal vmdk_open bdrv_open_driver bdrv_open_common bdrv_open_inherit bdrv_open blk_new_open blockdev_init drive_new drive_init_func qemu_opts_foreach configure_blockdev qemu_create_early_backends qemu_init main The check would be there if the whole series was applied, but since the last patches in the previous series rely on some other patches to land first, we need to recover the behavior of migration_is_idle() first before that whole set will be merged. I left migration_is_active / migration_is_device alone, as I don't think it's possible for them to hit uninitialized current_migration. Also they're prone to removal soon from VFIO side. Cc: Peter Maydell Fixes: 34a8892dec ("migration: Drop migration_is_idle()") Reported-by: Pierrick Bouvier Reported-by: Denis Rastyogin Tested-by: Pierrick Bouvier Tested-by: Thomas Huth Reviewed-by: Pierrick Bouvier Reviewed-by: Fabiano Rosas Link: https://lore.kernel.org/r/20241105182725.2393425-1-peterx@redhat.com [peterx: enhance commit msg] Signed-off-by: Peter Xu --- migration/migration.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/migration/migration.c b/migration/migration.c index aedf7f0751..8c5bd0a75c 100644 --- a/migration/migration.c +++ b/migration/migration.c @@ -1117,6 +1117,10 @@ bool migration_is_running(void) { MigrationState *s = current_migration; + if (!s) { + return false; + } + switch (s->state) { case MIGRATION_STATUS_ACTIVE: case MIGRATION_STATUS_POSTCOPY_ACTIVE: From 0926c002c7c71749a781de13f28b0481e029d323 Mon Sep 17 00:00:00 2001 From: Dmitry Frolov Date: Wed, 13 Nov 2024 17:05:01 +0300 Subject: [PATCH 2/2] migration: fix-possible-int-overflow stat64_add() takes uint64_t as 2nd argument, but both "p->next_packet_size" and "p->packet_len" are uint32_t. Thus, theyr sum may overflow uint32_t. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Frolov Link: https://lore.kernel.org/r/20241113140509.325732-2-frolov@swemel.ru Signed-off-by: Peter Xu --- migration/multifd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/migration/multifd.c b/migration/multifd.c index 4374e14a96..498e71fd10 100644 --- a/migration/multifd.c +++ b/migration/multifd.c @@ -623,7 +623,7 @@ static void *multifd_send_thread(void *opaque) } stat64_add(&mig_stats.multifd_bytes, - p->next_packet_size + p->packet_len); + (uint64_t)p->next_packet_size + p->packet_len); p->next_packet_size = 0; multifd_set_payload_type(p->data, MULTIFD_PAYLOAD_NONE);