From: Jiri Slaby <jirislaby@kernel.org>
To: wangzijie <wangzijie1@honor.com>, jirislaby@kernel.org
Cc: adobriyan@gmail.com, akpm@linux-foundation.org, ast@kernel.org,
gregkh@linuxfoundation.org, kirill.shutemov@linux.intel.com,
polynomial-c@gmx.de, regressions@lists.linux.dev,
rick.p.edgecombe@intel.com, stable@vger.kernel.org,
viro@zeniv.linux.org.uk
Subject: Re: [PATCH] proc: fix wrong behavior of FMODE_LSEEK clearing for net related proc file
Date: Mon, 18 Aug 2025 10:08:38 +0200 [thread overview]
Message-ID: <c3866652-dcba-4cc7-b2b3-8c33a8898ccd@kernel.org> (raw)
In-Reply-To: <20250818080125.843285-1-wangzijie1@honor.com>
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)
> + pde_set_flags(dp);
This occurs much saner and better to me. But I am no FS fellow. It's up
to them to tell if it is the right thing to do.
(The above hunks are missing removal of pde_set_flags() from the
original location and removal of now unnecessary calls of
pde_set_flags(). But I assume you would do that in a real/submitted patch.)
thanks,
--
js
suse labs
next prev parent reply other threads:[~2025-08-18 8:08 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 [this message]
2025-08-18 8:11 ` Jiri Slaby
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=c3866652-dcba-4cc7-b2b3-8c33a8898ccd@kernel.org \
--to=jirislaby@kernel.org \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=ast@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=kirill.shutemov@linux.intel.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.