deadlock from exec_update_lock and reading procfs

deadlock from exec_update_lock and reading procfs

[Benjamin Peterson]

After receiving a kernel with 6650527444da ("proc: protect ptrace_may_access() with exec_update_lock (part 1)"), we encountered a new deadlock in a FUSE server. The FUSE server reads /proc/PID/stat in the file flush callback, where PID is the pid of flushing process. This can deadlock in exec_update_lock acquisition when the flushing process is closing O_CLOEXEC files.

Specifically, a process running execve is blocked with this stack:

__schedule+0x505/0xc00
schedule+0x27/0xc0
request_wait_answer+0x158/0x2a0
__fuse_simple_request+0xd7/0x290
fuse_flush+0x1a4/0x1e0
filp_flush+0x30/0x60
filp_close+0x13/0x30
do_close_on_exec+0x114/0x160
begin_new_exec+0x553/0xb50
load_elf_binary+0x2da/0x1770
? load_misc_binary+0x275/0x390 [binfmt_misc]
bprm_execve+0x241/0x5f0
do_execveat_common.isra.0+0x182/0x1c0
__x64_sys_execve+0x36/0x40
do_syscall_64+0x87/0x180

while the FUSE server is blocked here:

__schedule+0x505/0xc00
schedule+0x27/0xc0
schedule_preempt_disabled+0x15/0x30
rwsem_down_read_slowpath+0x25c/0x480
down_read_killable+0x48/0xc0
do_task_stat+0x7f/0xec0
proc_single_show+0x51/0xc0
seq_read_iter+0x11f/0x460
seq_read+0x12d/0x160
vfs_read+0xe8/0x360
ksys_read+0x6d/0xf0
do_syscall_64+0x87/0x180


This problems seems to have been acknowledged as a theoretical possibility in the original patch review thread [1]. Now that it's a practical problem, is it feasible to move do_close_on_exec outside the scope of exec_update_lock?

Best regards, Benjamin

[1] https://lore.kernel.org/all/CAG48ez2pmuoTCZh_AVKDDLeQEYmm=gLMgThnqFhRMFfZvABpdw@mail.gmail.com/

Re: deadlock from exec_update_lock and reading procfs

[Jann Horn]

On Tue, Sep 1, 2026 at 4:50 PM Benjamin Peterson <benjamin@locrian.net> wrote:
> After receiving a kernel with 6650527444da ("proc: protect ptrace_may_access() with exec_update_lock (part 1)"), we encountered a new deadlock in a FUSE server. The FUSE server reads /proc/PID/stat in the file flush callback, where PID is the pid of flushing process. This can deadlock in exec_update_lock acquisition when the flushing process is closing O_CLOEXEC files.

Ugh, sorry about that.

#regzbot ^introduced:  6650527444da

> Specifically, a process running execve is blocked with this stack:
>
> __schedule+0x505/0xc00
> schedule+0x27/0xc0
> request_wait_answer+0x158/0x2a0
> __fuse_simple_request+0xd7/0x290
> fuse_flush+0x1a4/0x1e0
> filp_flush+0x30/0x60
> filp_close+0x13/0x30
> do_close_on_exec+0x114/0x160
> begin_new_exec+0x553/0xb50
> load_elf_binary+0x2da/0x1770
> ? load_misc_binary+0x275/0x390 [binfmt_misc]
> bprm_execve+0x241/0x5f0
> do_execveat_common.isra.0+0x182/0x1c0
> __x64_sys_execve+0x36/0x40
> do_syscall_64+0x87/0x180
>
> while the FUSE server is blocked here:
>
> __schedule+0x505/0xc00
> schedule+0x27/0xc0
> schedule_preempt_disabled+0x15/0x30
> rwsem_down_read_slowpath+0x25c/0x480
> down_read_killable+0x48/0xc0
> do_task_stat+0x7f/0xec0
> proc_single_show+0x51/0xc0
> seq_read_iter+0x11f/0x460
> seq_read+0x12d/0x160
> vfs_read+0xe8/0x360
> ksys_read+0x6d/0xf0
> do_syscall_64+0x87/0x180
>
>
> This problems seems to have been acknowledged as a theoretical possibility in the original patch review thread [1]. Now that it's a practical problem, is it feasible to move do_close_on_exec outside the scope of exec_update_lock?

I will take a look at this soon.

> Best regards, Benjamin
>
> [1] https://lore.kernel.org/all/CAG48ez2pmuoTCZh_AVKDDLeQEYmm=gLMgThnqFhRMFfZvABpdw@mail.gmail.com/

Re: deadlock from exec_update_lock and reading procfs

[Jann Horn]

On Wed, Sep 2, 2026 at 8:04 PM Jann Horn <jannh@google.com> wrote:
> On Tue, Sep 1, 2026 at 4:50 PM Benjamin Peterson <benjamin@locrian.net> wrote:
> > After receiving a kernel with 6650527444da ("proc: protect ptrace_may_access() with exec_update_lock (part 1)"), we encountered a new deadlock in a FUSE server. The FUSE server reads /proc/PID/stat in the file flush callback, where PID is the pid of flushing process. This can deadlock in exec_update_lock acquisition when the flushing process is closing O_CLOEXEC files.
>
> Ugh, sorry about that.
>
> #regzbot ^introduced:  6650527444da

This should resolve the issue:
https://lore.kernel.org/r/20260907-cloexec-before-exec-update-lock-v1-1-8018c201a7df@google.com

If you can easily test the fix on an affected system, it would be nice
if you could give feedback about whether the fix works for you on that
thread.