* [Devel] [PATCH hci-8.1 1/2] ms/vfio: prevent infinite loop in vfio_mig_get_next_state() on blocked arc
2026-10-14 17:16 [Devel] [PATCH hci-8.1 0/2] vfio, exec: two mainline fixes that Oracle carries Konstantin Khorenko
@ 2026-10-14 17:16 ` Konstantin Khorenko
2026-10-14 17:34 ` no-reply
2026-10-14 17:16 ` [Devel] [PATCH hci-8.1 2/2] ms/exec: do_close_on_exec() before taking exec_update_lock Konstantin Khorenko
2026-11-04 19:22 ` [Devel] [PATCH hci-8.1 0/2] vfio, exec: two mainline fixes that Oracle carries Konstantin Khorenko
2 siblings, 1 reply; 6+ messages in thread
From: Konstantin Khorenko @ 2026-10-14 17:16 UTC (permalink / raw)
To: Vasileios Almpanis, Andrey Drobyshev, Pavel Tikhomirov; +Cc: devel
From: Junrui Luo <moonafterrain@outlook.com>
vfio_mig_get_next_state() walks vfio_from_fsm_table[] one step at a time,
looping to skip optional states the device does not support until
*next_fsm is supported. A blocked transition is encoded as
VFIO_DEVICE_STATE_ERROR, which the trailing return reports as -EINVAL.
The skip loop does not account for the ERROR sentinel.
state_flags_table[ERROR] is ~0U and vfio_from_fsm_table[ERROR][*] is
ERROR, so once *next_fsm becomes ERROR the loop condition stays true and
*next_fsm never changes. The blocked arcs STOP_COPY -> PRE_COPY and
STOP_COPY -> PRE_COPY_P2P map to ERROR yet pass the support check on a
precopy-capable device, causing the loop to spin forever while holding
the driver state mutex. This can result in a soft lockup, and a panic
with softlockup_panic set.
Terminate the skip loop on the ERROR sentinel so a blocked transition
falls through to the existing return and reports -EINVAL.
Fixes: 4db52602a607 ("vfio: Extend the device migration protocol with PRE_COPY")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/SYBPR01MB7881290BBDE79B61AE6A017FAF122@SYBPR01MB7881.ausprd01.prod.outlook.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
(cherry picked from commit a26b499b757cfc8bbff1088bb1b844639e250893)
https://virtuozzo.atlassian.net/browse/VSTOR-150235
Feature: fix ms/vfio
Assisted-by: LLM
Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
---
drivers/vfio/vfio_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index f7df90c423b48..bf01fc64ee646 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -848,7 +848,8 @@ int vfio_mig_get_next_state(struct vfio_device *device,
* logical state, as per the above comment.
*/
*next_fsm = vfio_from_fsm_table[cur_fsm][new_fsm];
- while ((state_flags_table[*next_fsm] & device->migration_flags) !=
+ while (*next_fsm != VFIO_DEVICE_STATE_ERROR &&
+ (state_flags_table[*next_fsm] & device->migration_flags) !=
state_flags_table[*next_fsm])
*next_fsm = vfio_from_fsm_table[*next_fsm][new_fsm];
--
2.43.0
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
^ permalink raw reply [flat|nested] 6+ messages in thread* [Devel] [PATCH hci-8.1 2/2] ms/exec: do_close_on_exec() before taking exec_update_lock
2026-10-14 17:16 [Devel] [PATCH hci-8.1 0/2] vfio, exec: two mainline fixes that Oracle carries Konstantin Khorenko
2026-10-14 17:16 ` [Devel] [PATCH hci-8.1 1/2] ms/vfio: prevent infinite loop in vfio_mig_get_next_state() on blocked arc Konstantin Khorenko
@ 2026-10-14 17:16 ` Konstantin Khorenko
2026-10-14 17:35 ` no-reply
2026-11-04 19:22 ` [Devel] [PATCH hci-8.1 0/2] vfio, exec: two mainline fixes that Oracle carries Konstantin Khorenko
2 siblings, 1 reply; 6+ messages in thread
From: Konstantin Khorenko @ 2026-10-14 17:16 UTC (permalink / raw)
To: Vasileios Almpanis, Andrey Drobyshev, Pavel Tikhomirov; +Cc: devel
From: Jann Horn <jannh@google.com>
do_close_on_exec() currently happens while holding the exec_update_lock,
which is used in a lot of places that access process state to
synchronize access checks.
I recently added another such use of exec_update_lock, causing a
regression.
do_close_on_exec() can block waiting for a reply from a filesystem.
That means a hung filesystem can block codepaths that use
exec_update_lock; and it also means that a FUSE filesystem which
attempts to inspect the calling process can deadlock.
To avoid such problems, move do_close_on_exec() before the
exec_update_lock is taken, but after the FD table has been copied if
necessary.
I have looked through all the calls between the old and new position of
the do_close_on_exec() call; there seems to be no file descriptor table
access in between.
Reported-by: Benjamin Peterson <benjamin@locrian.net>
Closes: https://lore.kernel.org/r/f5e8166a-88be-46c5-8939-1e5227ffe4c2@app.fastmail.com
Fixes: 6650527444da ("proc: protect ptrace_may_access() with exec_update_lock (part 1)")
Cc: stable@vger.kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
Link: https://patch.msgid.link/20260907-cloexec-before-exec-update-lock-v1-1-8018c201a7df@google.com
Tested-by: Benjamin Peterson <benjamin@locrian.net>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
(cherry picked from commit e780259b54e618ceb4763fbc21314acf3565e813)
Backport note: the Fixes: target 6650527444da is not in this tree, but
exec_update_lock already has readers here that a hung or self-inspecting
FUSE flush blocks: mm_access() (/proc/PID/maps, mem, environ and the
like, process_vm_readv()), lock_trace(), /proc/PID/io, pidfd_getfd(),
kcmp(), get_robust_list() and perf_event_open(). vz fuse_flush() sends
FLUSH only for files open for writing.
https://virtuozzo.atlassian.net/browse/VSTOR-150235
Feature: fix ms/exec
Assisted-by: LLM
Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
---
fs/exec.c | 22 ++++++++++++++--------
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index e861a54b491f8..3b3412bcd7276 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1305,6 +1305,20 @@ int begin_new_exec(struct linux_binprm * bprm)
if (retval)
goto out;
+ /*
+ * We have to apply CLOEXEC before we change whether the process is
+ * dumpable (in setup_new_exec) to avoid a race with a process in userspace
+ * trying to access the should-be-closed file descriptors of a process
+ * undergoing exec(2).
+ *
+ * This can block on filesystem ->flush() handlers, including waiting
+ * for FUSE daemons, so do it before exec_mmap takes the
+ * exec_update_lock.
+ * This must happen after the point of no return, and after unsharing
+ * the FD table.
+ */
+ do_close_on_exec(me->files);
+
/*
* Must be called _before_ exec_mmap() as bprm->mm is
* not visible until then. Doing it here also ensures
@@ -1355,14 +1369,6 @@ int begin_new_exec(struct linux_binprm * bprm)
clear_syscall_work_syscall_user_dispatch(me);
- /*
- * We have to apply CLOEXEC before we change whether the process is
- * dumpable (in setup_new_exec) to avoid a race with a process in userspace
- * trying to access the should-be-closed file descriptors of a process
- * undergoing exec(2).
- */
- do_close_on_exec(me->files);
-
if (bprm->secureexec) {
/* Make sure parent cannot signal privileged process. */
me->pdeath_signal = 0;
--
2.43.0
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Devel] [PATCH hci-8.1 0/2] vfio, exec: two mainline fixes that Oracle carries
2026-10-14 17:16 [Devel] [PATCH hci-8.1 0/2] vfio, exec: two mainline fixes that Oracle carries Konstantin Khorenko
2026-10-14 17:16 ` [Devel] [PATCH hci-8.1 1/2] ms/vfio: prevent infinite loop in vfio_mig_get_next_state() on blocked arc Konstantin Khorenko
2026-10-14 17:16 ` [Devel] [PATCH hci-8.1 2/2] ms/exec: do_close_on_exec() before taking exec_update_lock Konstantin Khorenko
@ 2026-11-04 19:22 ` Konstantin Khorenko
2 siblings, 0 replies; 6+ messages in thread
From: Konstantin Khorenko @ 2026-11-04 19:22 UTC (permalink / raw)
To: Vasileios Almpanis, Andrey Drobyshev, Pavel Tikhomirov,
Konstantin Khorenko
Cc: devel
On Wed, 14 Oct 2026 19:16:25 +0200, Konstantin Khorenko wrote:
> vfio, exec: two mainline fixes that Oracle carries
>
> Two mainline fixes, independent of the MADV_DOEXEC series, found while
> comparing our tree with UEK8. Both are in linux-6.12.y as well and
> apply to the 211.52.1.22.x branch directly.
>
> - 1: vfio_mig_get_next_state() spins forever under the driver's state
> mutex when userspace asks for the blocked arc STOP_COPY -> PRE_COPY.
> Reproduced with the mtty sample driver: a soft lockup before, EINVAL
> after.
> - 2: do_close_on_exec() ran under exec_update_lock, so a FUSE daemon
> that inspects the exec'ing process (for example /proc/PID/maps) from
> its FLUSH handler deadlocked exec. Reproduced with a small FUSE
> filesystem: a deadlock before, a normal exec after.
>
> [...]
Applied to branch-rh10-6.12.0-211.52.1.22.x.vz10-ovz, will be released in rh10-6.12.0-211.52.1.22.18.vz10, thanks!
[1/2] ms/vfio: prevent infinite loop in vfio_mig_get_next_state() on blocked arc
https://bitbucket.org/virtuozzocore/vzkernel.vzs/commits/8f215ebf4783
[2/2] ms/exec: do_close_on_exec() before taking exec_update_lock
https://bitbucket.org/virtuozzocore/vzkernel.vzs/commits/0a91ee4f869b
--
Konstantin Khorenko,
Virtuozzo Linux Kernel Team
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
^ permalink raw reply [flat|nested] 6+ messages in thread