>On Thu, Jun 05, 2025 at 02:44:15PM -0700, Andrew Morton wrote:
>> On Thu, 5 Jun 2025 14:52:52 +0800 wangzijie <wangzijie1@xxxxxxxxx> wrote:
>>
>> > Clearing FMODE_LSEEK flag should not rely on whether proc_open ops exists,
>>
>> Why is this?
>>
>> > fix it.
>>
>> What are the consequences of the fix? Is there presently some kernel
>> misbehavior?
>
>At a guess, that would be an oops due to this:
> if (pde_is_permanent(pde)) {
> return pde->proc_ops->proc_lseek(file, offset, whence);
> } else if (use_pde(pde)) {
> rv = pde->proc_ops->proc_lseek(file, offset, whence);
> unuse_pde(pde);
> }
>in proc_reg_llseek(). No FMODE_LSEEK == "no seeks for that file, just
>return -ESPIPE". It is set by do_dentry_open() if you have NULL
>->llseek() in ->f_op; the reason why procfs needs to adjust that is
>the it has uniform ->llseek, calling the underlying method for that
>proc_dir_entry. So if it's NULL, we need ->open() (also uniform,
>proc_reg_open() for all of those) to clear FMODE_LSEEK from ->f_mode.
>
>The thing I don't understand is where the hell had proc_reg_open()
>changed in that way - commit refered in the patch doesn't exist in
>mainline, doesn't seem to be in -next or -stable either.
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.
