>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...
Thank you very much for your suggestion! I will follow that and submit patch later.
