Re: deadlock from exec_update_lock and reading procfs

[Jann Horn]

On Tue, Sep 1, 2026 at 4:50 PM Benjamin Peterson <benjamin@xxxxxxxxxxx> 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@xxxxxxxxxxxxxx/