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...
