All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Slaby <jirislaby@kernel.org>
To: wangzijie <wangzijie1@honor.com>
Cc: adobriyan@gmail.com, akpm@linux-foundation.org, ast@kernel.org,
	gregkh@linuxfoundation.org, polynomial-c@gmx.de,
	regressions@lists.linux.dev, rick.p.edgecombe@intel.com,
	stable@vger.kernel.org, viro@zeniv.linux.org.uk,
	k.shutemov@gmail.com
Subject: Re: [PATCH] proc: fix wrong behavior of FMODE_LSEEK clearing for net related proc file
Date: Mon, 18 Aug 2025 10:11:41 +0200	[thread overview]
Message-ID: <6b4debbf-028d-49e0-858f-dc72b37948c7@kernel.org> (raw)
In-Reply-To: <c3866652-dcba-4cc7-b2b3-8c33a8898ccd@kernel.org>

k.shutemov no longer @ intel -> use gmail.

On 18. 08. 25, 10:08, Jiri Slaby wrote:
> On 18. 08. 25, 10:01, wangzijie wrote:
>>> Hi,
>>>
>>> On 18. 08. 25, 6:05, wangzijie wrote:
>>>> For avoiding pde->proc_ops->... dereference(which may cause UAF in 
>>>> rmmod race scene),
>>>> we call pde_set_flags() to save this kind of information in PDE 
>>>> itself before
>>>> proc_register() and call pde_has_proc_XXX() to replace pde- 
>>>> >proc_ops->... dereference.
>>>> But there has omission of pde_set_flags() in net related proc file 
>>>> create, which cause
>>>> the wroing behavior of FMODE_LSEEK clearing in proc_reg_open() for 
>>>> net related proc file
>>>> after commit ff7ec8dc1b64("proc: use the same treatment to check 
>>>> proc_lseek as ones for
>>>> proc_read_iter et.al"). Lars reported it in this link[1]. So call 
>>>> pde_set_flags() when
>>>> create net related proc file to fix this bug.
>>>
>>> I wonder, why is pde_set_flags() not a part of proc_register()?
>>
>> Not all proc_dir_entry have proc_ops, so you mean this will be a 
>> better modification?
>>
>> diff --git a/fs/proc/generic.c b/fs/proc/generic.c
>> index 76e800e38..d52197c35 100644
>> --- a/fs/proc/generic.c
>> +++ b/fs/proc/generic.c
>> @@ -367,6 +367,20 @@ static const struct inode_operations 
>> proc_dir_inode_operations = {
>>          .setattr        = proc_notify_change,
>>   };
>>
>> +static void pde_set_flags(struct proc_dir_entry *pde)
>> +{
>> +       if (pde->proc_ops->proc_flags & PROC_ENTRY_PERMANENT)
>> +               pde->flags |= PROC_ENTRY_PERMANENT;
>> +       if (pde->proc_ops->proc_read_iter)
>> +               pde->flags |= PROC_ENTRY_proc_read_iter;
>> +#ifdef CONFIG_COMPAT
>> +       if (pde->proc_ops->proc_compat_ioctl)
>> +               pde->flags |= PROC_ENTRY_proc_compat_ioctl;
>> +#endif
>> +       if (pde->proc_ops->proc_lseek)
>> +               pde->flags |= PROC_ENTRY_proc_lseek;
>> +}
>> +
>>   /* returns the registered entry, or frees dp and returns NULL on 
>> failure */
>>   struct proc_dir_entry *proc_register(struct proc_dir_entry *dir,
>>                  struct proc_dir_entry *dp)
>> @@ -374,6 +388,9 @@ struct proc_dir_entry *proc_register(struct 
>> proc_dir_entry *dir,
>>          if (proc_alloc_inum(&dp->low_ino))
>>                  goto out_free_entry;
>>
>> +       if (dp->proc_ops)

And to be honest, I would possibly move the 'if' into pde_set_flags().

>> +               pde_set_flags(dp);

As here, it is not completely clear why you would want to test 
"dp->proc_ops" for something called "pde_set_flags".

-- 
js
suse labs

  reply	other threads:[~2025-08-18  8:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-18  4:05 [PATCH] proc: fix wrong behavior of FMODE_LSEEK clearing for net related proc file wangzijie
2025-08-18  5:01 ` Jiri Slaby
2025-08-18  8:01   ` wangzijie
2025-08-18  8:08     ` Jiri Slaby
2025-08-18  8:11       ` Jiri Slaby [this message]
2025-08-18  8:29         ` wangzijie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6b4debbf-028d-49e0-858f-dc72b37948c7@kernel.org \
    --to=jirislaby@kernel.org \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=ast@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=k.shutemov@gmail.com \
    --cc=polynomial-c@gmx.de \
    --cc=regressions@lists.linux.dev \
    --cc=rick.p.edgecombe@intel.com \
    --cc=stable@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=wangzijie1@honor.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.