Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
Date:   Mon, 18 Sep 2023 12:59:47 +0300
From:   Alexey Dobriyan <adobriyan@gmail.com>
To:     =?utf-8?B?5byg5a2Q5YuLKFpoYW5nIFppeHVuKQ==?= <zhangzixun1@oppo.com>
Cc:     "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: DoS in lseek inodes with proc_ops
Message-ID: <fe27461f-69ef-41aa-bc8c-6e3fbb7f67ee@p183>
References: <SEZPR02MB70394C03FD07798864962C7C8EFBA@SEZPR02MB7039.apcprd02.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <SEZPR02MB70394C03FD07798864962C7C8EFBA@SEZPR02MB7039.apcprd02.prod.outlook.com>
Precedence: bulk

On Mon, Sep 18, 2023 at 07:39:51AM +0000, 张子勋(Zhang Zixun) wrote:
> Hi,
> There is a null pointer dereference DoS issue when I use lseek syscall to inode with proc_ops.
> I find the root cause is https://lore.kernel.org/all/YFYX0Bzwxlc7aBa%2F@localhost.localdomain/ .
> In this patch, the lseek syscall is set to mandatory. So, if proc_lseek is not set in proc_ops, pde->proc_ops->proc_lseek will get a null pointer.
> I want to know why all inode in proc need to set its own lseek, and why set default_llseek in pde_lseek isn’t a good idea?
> By the way, although every inode need set a lseek to use lseek syscall, lseek to a inode without lseek should get a fail return and the kernel should’t panic.

It removes 1 branch and make code smaller too.
You can switch to nonseekable_open() if you don't need lseeks.