Re: [PATCH] proc: clear FMODE_LSEEK flag correctly for permanent pde

[Al Viro <viro@zeniv.linux.org.uk>]

On Fri, Jun 06, 2025 at 10:37:35AM +0800, wangzijie wrote:

> My bad for making this misbehavior, thank you for helping explain it.
> commit 654b33ada4ab("proc: fix UAF in proc_get_inode()") is in -stable, 
> I refered v1 just for showing race in rmmod scenario, it's my bad.

I still don't understand what's going on.  654b33ada4ab is both in
mainline and in stable, but proc_reg_open() is nowhere near the
shape your patch would imply.

The best reconstruction I can come up with is that an earlier patch
in whatever tree you are talking about has moved

        if (!pde->proc_ops->proc_lseek)
		file->f_mode &= ~FMODE_LSEEK;

down, separately into permanent and non-permanent cases, after use_pde()
in the latter case.  And the author of that earlier patch has moved
the check under if (open) in permanent case, which would warrant that
kind of fixup.

However,
	* why is that earlier patch sitting someplace that is *NOT*
in -next?
	* why bother with those games at all?  Just nick another bit
from pde->flags (let's call it PROC_ENTRY_proc_lseek for consistency
sake), set it in same pde_set_flags() where other flags are dealt with
and just turn that thing into
        if (!pde_has_proc_lseek(pde))
		file->f_mode &= ~FMODE_LSEEK;
leaving it where it is.  Less intrusive and easier to follow...

	Call it something like

check proc_lseek needs the same treatment as ones for proc_read_iter et.al.

and describe it as a gap in "proc: fix UAF in proc_get_inode()",
fixed in exact same manner...