[Devel] [PATCH hci-8.1 0/2] vfio, exec: two mainline fixes that Oracle carries

[Devel] [PATCH hci-8.1 0/2] vfio, exec: two mainline fixes that Oracle carries

[Konstantin Khorenko]

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.

Tested on a debug kernel: both reproducers, selftests/exec, a Container
start/exec/stop.

https://virtuozzo.atlassian.net/browse/VSTOR-150235

---
Jann Horn (1):
      ms/exec: do_close_on_exec() before taking exec_update_lock

Junrui Luo (1):
      ms/vfio: prevent infinite loop in vfio_mig_get_next_state() on blocked arc

 drivers/vfio/vfio_main.c |  3 ++-
 fs/exec.c                | 22 ++++++++++++++--------
 2 files changed, 16 insertions(+), 9 deletions(-)
---
base-commit: defa968cbe8c38f1ff0231042dee07f00d27b2c9
change-id: 20261014-b4-prep-khorenko-vstor-149847-6-vfio-exec-ms-backports-0564f1b9331f

Best regards,
--  
Konstantin Khorenko <khorenko@virtuozzo.com>

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

[Devel] [PATCH hci-8.1 1/2] ms/vfio: prevent infinite loop in vfio_mig_get_next_state() on blocked arc

[Konstantin Khorenko]

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

Re: [Devel] [PATCH hci-8.1 1/2] ms/vfio: prevent infinite loop in vfio_mig_get_next_state() on blocked arc

[no-reply]

> 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.
> [ ... ]
> https://virtuozzo.atlassian.net/browse/VSTOR-150235
> Feature: fix ms/vfio
> 
> Assisted-by: LLM
> Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.vzint.dev/#/patchset/20261014-b4-prep-khorenko-vstor-149847-6-vfio-exec-ms-backports-v1-0-07b4e541d4ec@virtuozzo.com?part=1


_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

[Devel] [PATCH hci-8.1 2/2] ms/exec: do_close_on_exec() before taking exec_update_lock

[Konstantin Khorenko]

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

Re: [Devel] [PATCH hci-8.1 2/2] ms/exec: do_close_on_exec() before taking exec_update_lock

[no-reply]

> 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
> [ ... ]
> https://virtuozzo.atlassian.net/browse/VSTOR-150235
> Feature: fix ms/exec
> 
> Assisted-by: LLM
> Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.vzint.dev/#/patchset/20261014-b4-prep-khorenko-vstor-149847-6-vfio-exec-ms-backports-v1-0-07b4e541d4ec@virtuozzo.com?part=2


_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel