| Message ID | 20221123020419.1867-1-thunder.leizhen@huawei.com |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org>
Delivered-To: ouuuleilei@gmail.com
Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp2547624wrr;
Tue, 22 Nov 2022 18:16:09 -0800 (PST)
X-Google-Smtp-Source:
AA0mqf6WDCkknJN0kvDQxDW2fzpJewlZePYe9b59RTfVe9sbgHov78YggjQxkrEvcAVUodiJZXxf
X-Received: by 2002:a17:906:d78e:b0:7ae:c0b:a25e with SMTP id
pj14-20020a170906d78e00b007ae0c0ba25emr5779093ejb.603.1669169768847;
Tue, 22 Nov 2022 18:16:08 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1669169768; cv=none;
d=google.com; s=arc-20160816;
b=nUiZFPS45UvRg+PDkPFNu4ipqKn9sPHoCTfe7cVNCW6ZQJsliP3wMqonPYdJ137t9s
yRBpx8jb8dhP7sbUhP+v/yeJta/xEwt+8ondyGDj5YAVV+7ESLkZgoRj2oNpc5ZwrHbA
igVaLyO16vGrCGxI843kB6YSx9b1MemqW4VDD126qHJ/KynjqvlXPorsu8IPwYZQ3Dsj
cp1CMfY/OmdasFlnz20gHSfcKG5DwHaJWLT75KRgnSiJDFUQvNLD8MoKoKXWufOqq5qM
kZDKf7TQhJlLo9H1htpUsuEA827HGkjc0j8+OvW+5grCCtfWvp91siMxBs7Ckn5uwie9
7cdA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
s=arc-20160816;
h=list-id:precedence:content-transfer-encoding:mime-version
:message-id:date:subject:cc:to:from;
bh=fzc19XYyWHhW9cGryLObnUT77okpWDKf95uD74pgo9Q=;
b=AbiOhuKvXm+migLYCD2VbVlQLWCdvBIFqRmXYUgEo0PB0eBr1smosDo62Y3WdHCGnx
cOHkerFKhtDpLzyAEWdyHPdQ3UGM5b+/s1EFnjg/1UQ1oKx9BBSswOsgSOOKfj2LlKHW
rcGDLX48uGo6F4JrW/SzHRnxpbT+S69NvyCbJTEEKPLyPpG01bHN71ph1UVmIK0irxuH
9Rf9nuAqnGYZYANVZtRAyxV8hDdIpZD5jxcJ9DyqzkmPiYpShBHPFxuD0rAyf3hfS/fk
AIrWdouSdlXjOcdUe7b2vB4CHmbHHiHZzU0AqAS23n/8qBU5Kv22USq+mRaBGouPdrbh
mQmA==
ARC-Authentication-Results: i=1; mx.google.com;
spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com
Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20])
by mx.google.com with ESMTP id
oz36-20020a1709077da400b007b961545a0dsi1404951ejc.500.2022.11.22.18.15.45;
Tue, 22 Nov 2022 18:16:08 -0800 (PST)
Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
client-ip=2620:137:e000::1:20;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S235351AbiKWCF7 (ORCPT <rfc822;cjcooper78@gmail.com> + 99 others);
Tue, 22 Nov 2022 21:05:59 -0500
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57054 "EHLO
lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S235320AbiKWCF6 (ORCPT
<rfc822;linux-kernel@vger.kernel.org>);
Tue, 22 Nov 2022 21:05:58 -0500
Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188])
by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BC0358DA70
for <linux-kernel@vger.kernel.org>;
Tue, 22 Nov 2022 18:05:56 -0800 (PST)
Received: from dggpemm500021.china.huawei.com (unknown [172.30.72.54])
by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4NH4G76CWyzRpSv;
Wed, 23 Nov 2022 10:05:19 +0800 (CST)
Received: from dggpemm500006.china.huawei.com (7.185.36.236) by
dggpemm500021.china.huawei.com (7.185.36.109) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2375.31; Wed, 23 Nov 2022 10:05:49 +0800
Received: from thunder-town.china.huawei.com (10.174.178.55) by
dggpemm500006.china.huawei.com (7.185.36.236) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2375.31; Wed, 23 Nov 2022 10:05:48 +0800
From: Zhen Lei <thunder.leizhen@huawei.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Tejun Heo <tj@kernel.org>, <linux-kernel@vger.kernel.org>
CC: Zhen Lei <thunder.leizhen@huawei.com>
Subject: [PATCH] kernfs: fix potential null-ptr-deref in
kernfs_path_from_node_locked()
Date: Wed, 23 Nov 2022 10:04:19 +0800
Message-ID: <20221123020419.1867-1-thunder.leizhen@huawei.com>
X-Mailer: git-send-email 2.37.3.windows.1
MIME-Version: 1.0
Content-Transfer-Encoding: 7BIT
Content-Type: text/plain; charset=US-ASCII
X-Originating-IP: [10.174.178.55]
X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To
dggpemm500006.china.huawei.com (7.185.36.236)
X-CFilter-Loop: Reflected
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?=
X-GMAIL-THRID: =?utf-8?q?1750251359193543029?=
X-GMAIL-MSGID: =?utf-8?q?1750251359193543029?=
|
| Series |
kernfs: fix potential null-ptr-deref in kernfs_path_from_node_locked()
|
|
Commit Message
Zhen Lei
Nov. 23, 2022, 2:04 a.m. UTC
Ensure that the 'buf' is not empty before strlcpy() uses it.
Commit bbe70e4e4211 ("fs: kernfs: Fix possible null-pointer dereferences
in kernfs_path_from_node_locked()") first noticed this, but it didn't
fix it completely.
Fixes: 9f6df573a404 ("kernfs: Add API to generate relative kernfs path")
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
fs/kernfs/dir.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Comments
On Wed, Nov 23, 2022 at 10:04:19AM +0800, Zhen Lei wrote: > Ensure that the 'buf' is not empty before strlcpy() uses it. > > Commit bbe70e4e4211 ("fs: kernfs: Fix possible null-pointer dereferences > in kernfs_path_from_node_locked()") first noticed this, but it didn't > fix it completely. > > Fixes: 9f6df573a404 ("kernfs: Add API to generate relative kernfs path") > Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> I think the right thing to do is removing that if. It makes no sense to call that function with NULL buf and the fact that nobody reported crashes on NULL buf indicates that we in fact never do. Thanks.
On 2022/11/24 0:55, Tejun Heo wrote: > On Wed, Nov 23, 2022 at 10:04:19AM +0800, Zhen Lei wrote: >> Ensure that the 'buf' is not empty before strlcpy() uses it. >> >> Commit bbe70e4e4211 ("fs: kernfs: Fix possible null-pointer dereferences >> in kernfs_path_from_node_locked()") first noticed this, but it didn't >> fix it completely. >> >> Fixes: 9f6df573a404 ("kernfs: Add API to generate relative kernfs path") >> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> > > I think the right thing to do is removing that if. It makes no sense to call > that function with NULL buf and the fact that nobody reported crashes on > NULL buf indicates that we in fact never do. OK. How about I remove "buf[0] = '\0';" too? It seems to be a useless operation. When 'kn_from' and 'kn_to' have a common ancestor, there must be a path from 'kn_from' to 'kn_to', and strlcpy() always fills in the terminator correctly, even if the buf is too small to save the first path node. static void test(void) { char buf[4]; int i, n, buflen; buflen = 1; n = strlcpy(buf, "string", buflen); for (i = 0; i < buflen; i++) printk("%d: %02x\n", i, buf[i]); printk("n=%d\n\n", n); buflen = sizeof(buf); n = strlcpy(buf, "string", buflen); for (i = 0; i < buflen; i++) printk("%d: %02x\n", i, buf[i]); printk("n=%d\n", n); } Output: [ 33.691497] 0: 00 [ 33.691569] n=6 [ 33.691595] 0: 73 [ 33.691622] 1: 74 [ 33.691630] 2: 72 [ 33.691637] 3: 00 [ 33.691650] n=6 > > Thanks. >
On 2022/11/24 10:24, Leizhen (ThunderTown) wrote: > > > On 2022/11/24 0:55, Tejun Heo wrote: >> On Wed, Nov 23, 2022 at 10:04:19AM +0800, Zhen Lei wrote: >>> Ensure that the 'buf' is not empty before strlcpy() uses it. >>> >>> Commit bbe70e4e4211 ("fs: kernfs: Fix possible null-pointer dereferences >>> in kernfs_path_from_node_locked()") first noticed this, but it didn't >>> fix it completely. >>> >>> Fixes: 9f6df573a404 ("kernfs: Add API to generate relative kernfs path") >>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> >> >> I think the right thing to do is removing that if. It makes no sense to call >> that function with NULL buf and the fact that nobody reported crashes on >> NULL buf indicates that we in fact never do. > > OK. > > How about I remove "buf[0] = '\0';" too? It seems to be a useless operation. > When 'kn_from' and 'kn_to' have a common ancestor, there must be a path from > 'kn_from' to 'kn_to', and strlcpy() always fills in the terminator correctly, > even if the buf is too small to save the first path node. Sorry, I misanalyzed. The length used by "len < buflen ? buflen - len : 0" may be zero. > > static void test(void) > { > char buf[4]; > int i, n, buflen; > > buflen = 1; > n = strlcpy(buf, "string", buflen); > for (i = 0; i < buflen; i++) > printk("%d: %02x\n", i, buf[i]); > printk("n=%d\n\n", n); > > buflen = sizeof(buf); > n = strlcpy(buf, "string", buflen); > for (i = 0; i < buflen; i++) > printk("%d: %02x\n", i, buf[i]); > printk("n=%d\n", n); > } > > Output: > [ 33.691497] 0: 00 > [ 33.691569] n=6 > > [ 33.691595] 0: 73 > [ 33.691622] 1: 74 > [ 33.691630] 2: 72 > [ 33.691637] 3: 00 > [ 33.691650] n=6 > >> >> Thanks. >> >
On 2022/11/24 10:28, Leizhen (ThunderTown) wrote: > > > On 2022/11/24 10:24, Leizhen (ThunderTown) wrote: >> >> >> On 2022/11/24 0:55, Tejun Heo wrote: >>> On Wed, Nov 23, 2022 at 10:04:19AM +0800, Zhen Lei wrote: >>>> Ensure that the 'buf' is not empty before strlcpy() uses it. >>>> >>>> Commit bbe70e4e4211 ("fs: kernfs: Fix possible null-pointer dereferences >>>> in kernfs_path_from_node_locked()") first noticed this, but it didn't >>>> fix it completely. >>>> >>>> Fixes: 9f6df573a404 ("kernfs: Add API to generate relative kernfs path") >>>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> >>> >>> I think the right thing to do is removing that if. It makes no sense to call >>> that function with NULL buf and the fact that nobody reported crashes on >>> NULL buf indicates that we in fact never do. >> >> OK. >> >> How about I remove "buf[0] = '\0';" too? It seems to be a useless operation. >> When 'kn_from' and 'kn_to' have a common ancestor, there must be a path from >> 'kn_from' to 'kn_to', and strlcpy() always fills in the terminator correctly, >> even if the buf is too small to save the first path node. > > Sorry, I misanalyzed. The length used by "len < buflen ? buflen - len : 0" may > be zero. Ah, my brain is unstable today. The initial value of len is 0. So "buf[0] = '\0';" can still be safely removed. > >> >> static void test(void) >> { >> char buf[4]; >> int i, n, buflen; >> >> buflen = 1; >> n = strlcpy(buf, "string", buflen); >> for (i = 0; i < buflen; i++) >> printk("%d: %02x\n", i, buf[i]); >> printk("n=%d\n\n", n); >> >> buflen = sizeof(buf); >> n = strlcpy(buf, "string", buflen); >> for (i = 0; i < buflen; i++) >> printk("%d: %02x\n", i, buf[i]); >> printk("n=%d\n", n); >> } >> >> Output: >> [ 33.691497] 0: 00 >> [ 33.691569] n=6 >> >> [ 33.691595] 0: 73 >> [ 33.691622] 1: 74 >> [ 33.691630] 2: 72 >> [ 33.691637] 3: 00 >> [ 33.691650] n=6 >> >>> >>> Thanks. >>> >> >
On 2022/11/24 10:52, Leizhen (ThunderTown) wrote: > > > On 2022/11/24 10:28, Leizhen (ThunderTown) wrote: >> >> >> On 2022/11/24 10:24, Leizhen (ThunderTown) wrote: >>> >>> >>> On 2022/11/24 0:55, Tejun Heo wrote: >>>> On Wed, Nov 23, 2022 at 10:04:19AM +0800, Zhen Lei wrote: >>>>> Ensure that the 'buf' is not empty before strlcpy() uses it. >>>>> >>>>> Commit bbe70e4e4211 ("fs: kernfs: Fix possible null-pointer dereferences >>>>> in kernfs_path_from_node_locked()") first noticed this, but it didn't >>>>> fix it completely. >>>>> >>>>> Fixes: 9f6df573a404 ("kernfs: Add API to generate relative kernfs path") >>>>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> >>>> >>>> I think the right thing to do is removing that if. It makes no sense to call >>>> that function with NULL buf and the fact that nobody reported crashes on >>>> NULL buf indicates that we in fact never do. kernfs_path_from_node -->kernfs_path_from_node_locked EXPORT_SYMBOL_GPL(kernfs_path_from_node) I've rethought it. The export APIs need to do null pointer check, right? >>> >>> OK. >>> >>> How about I remove "buf[0] = '\0';" too? It seems to be a useless operation. >>> When 'kn_from' and 'kn_to' have a common ancestor, there must be a path from >>> 'kn_from' to 'kn_to', and strlcpy() always fills in the terminator correctly, >>> even if the buf is too small to save the first path node. >> >> Sorry, I misanalyzed. The length used by "len < buflen ? buflen - len : 0" may >> be zero. > > Ah, my brain is unstable today. The initial value of len is 0. So "buf[0] = '\0';" > can still be safely removed. > >> >>> >>> static void test(void) >>> { >>> char buf[4]; >>> int i, n, buflen; >>> >>> buflen = 1; >>> n = strlcpy(buf, "string", buflen); >>> for (i = 0; i < buflen; i++) >>> printk("%d: %02x\n", i, buf[i]); >>> printk("n=%d\n\n", n); >>> >>> buflen = sizeof(buf); >>> n = strlcpy(buf, "string", buflen); >>> for (i = 0; i < buflen; i++) >>> printk("%d: %02x\n", i, buf[i]); >>> printk("n=%d\n", n); >>> } >>> >>> Output: >>> [ 33.691497] 0: 00 >>> [ 33.691569] n=6 >>> >>> [ 33.691595] 0: 73 >>> [ 33.691622] 1: 74 >>> [ 33.691630] 2: 72 >>> [ 33.691637] 3: 00 >>> [ 33.691650] n=6 >>> >>>> >>>> Thanks. >>>> >>> >> >
On Sat, Nov 26, 2022 at 05:49:50PM +0800, Leizhen (ThunderTown) wrote: > > > On 2022/11/24 10:52, Leizhen (ThunderTown) wrote: > > > > > > On 2022/11/24 10:28, Leizhen (ThunderTown) wrote: > >> > >> > >> On 2022/11/24 10:24, Leizhen (ThunderTown) wrote: > >>> > >>> > >>> On 2022/11/24 0:55, Tejun Heo wrote: > >>>> On Wed, Nov 23, 2022 at 10:04:19AM +0800, Zhen Lei wrote: > >>>>> Ensure that the 'buf' is not empty before strlcpy() uses it. > >>>>> > >>>>> Commit bbe70e4e4211 ("fs: kernfs: Fix possible null-pointer dereferences > >>>>> in kernfs_path_from_node_locked()") first noticed this, but it didn't > >>>>> fix it completely. > >>>>> > >>>>> Fixes: 9f6df573a404 ("kernfs: Add API to generate relative kernfs path") > >>>>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> > >>>> > >>>> I think the right thing to do is removing that if. It makes no sense to call > >>>> that function with NULL buf and the fact that nobody reported crashes on > >>>> NULL buf indicates that we in fact never do. > > kernfs_path_from_node > -->kernfs_path_from_node_locked > > EXPORT_SYMBOL_GPL(kernfs_path_from_node) > > I've rethought it. The export APIs need to do null pointer check, right? No, callers should get this right. Are there any in-tree ones that do not? thanks, greg k-h
On 2022/11/26 17:49, Leizhen (ThunderTown) wrote: > > > On 2022/11/24 10:52, Leizhen (ThunderTown) wrote: >> >> >> On 2022/11/24 10:28, Leizhen (ThunderTown) wrote: >>> >>> >>> On 2022/11/24 10:24, Leizhen (ThunderTown) wrote: >>>> >>>> >>>> On 2022/11/24 0:55, Tejun Heo wrote: >>>>> On Wed, Nov 23, 2022 at 10:04:19AM +0800, Zhen Lei wrote: >>>>>> Ensure that the 'buf' is not empty before strlcpy() uses it. >>>>>> >>>>>> Commit bbe70e4e4211 ("fs: kernfs: Fix possible null-pointer dereferences >>>>>> in kernfs_path_from_node_locked()") first noticed this, but it didn't >>>>>> fix it completely. >>>>>> >>>>>> Fixes: 9f6df573a404 ("kernfs: Add API to generate relative kernfs path") >>>>>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> >>>>> >>>>> I think the right thing to do is removing that if. It makes no sense to call >>>>> that function with NULL buf and the fact that nobody reported crashes on >>>>> NULL buf indicates that we in fact never do. > > kernfs_path_from_node > -->kernfs_path_from_node_locked > > EXPORT_SYMBOL_GPL(kernfs_path_from_node) > > I've rethought it. The export APIs need to do null pointer check, right? Sorry，I looked at some of the other functions and they didn't check either. > >>>> >>>> OK. >>>> >>>> How about I remove "buf[0] = '\0';" too? It seems to be a useless operation. >>>> When 'kn_from' and 'kn_to' have a common ancestor, there must be a path from >>>> 'kn_from' to 'kn_to', and strlcpy() always fills in the terminator correctly, >>>> even if the buf is too small to save the first path node. >>> >>> Sorry, I misanalyzed. The length used by "len < buflen ? buflen - len : 0" may >>> be zero. >> >> Ah, my brain is unstable today. The initial value of len is 0. So "buf[0] = '\0';" >> can still be safely removed. >> >>> >>>> >>>> static void test(void) >>>> { >>>> char buf[4]; >>>> int i, n, buflen; >>>> >>>> buflen = 1; >>>> n = strlcpy(buf, "string", buflen); >>>> for (i = 0; i < buflen; i++) >>>> printk("%d: %02x\n", i, buf[i]); >>>> printk("n=%d\n\n", n); >>>> >>>> buflen = sizeof(buf); >>>> n = strlcpy(buf, "string", buflen); >>>> for (i = 0; i < buflen; i++) >>>> printk("%d: %02x\n", i, buf[i]); >>>> printk("n=%d\n", n); >>>> } >>>> >>>> Output: >>>> [ 33.691497] 0: 00 >>>> [ 33.691569] n=6 >>>> >>>> [ 33.691595] 0: 73 >>>> [ 33.691622] 1: 74 >>>> [ 33.691630] 2: 72 >>>> [ 33.691637] 3: 00 >>>> [ 33.691650] n=6 >>>> >>>>> >>>>> Thanks. >>>>> >>>> >>> >> >
On 2022/11/26 18:25, Greg Kroah-Hartman wrote: > On Sat, Nov 26, 2022 at 05:49:50PM +0800, Leizhen (ThunderTown) wrote: >> >> >> On 2022/11/24 10:52, Leizhen (ThunderTown) wrote: >>> >>> >>> On 2022/11/24 10:28, Leizhen (ThunderTown) wrote: >>>> >>>> >>>> On 2022/11/24 10:24, Leizhen (ThunderTown) wrote: >>>>> >>>>> >>>>> On 2022/11/24 0:55, Tejun Heo wrote: >>>>>> On Wed, Nov 23, 2022 at 10:04:19AM +0800, Zhen Lei wrote: >>>>>>> Ensure that the 'buf' is not empty before strlcpy() uses it. >>>>>>> >>>>>>> Commit bbe70e4e4211 ("fs: kernfs: Fix possible null-pointer dereferences >>>>>>> in kernfs_path_from_node_locked()") first noticed this, but it didn't >>>>>>> fix it completely. >>>>>>> >>>>>>> Fixes: 9f6df573a404 ("kernfs: Add API to generate relative kernfs path") >>>>>>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> >>>>>> >>>>>> I think the right thing to do is removing that if. It makes no sense to call >>>>>> that function with NULL buf and the fact that nobody reported crashes on >>>>>> NULL buf indicates that we in fact never do. >> >> kernfs_path_from_node >> -->kernfs_path_from_node_locked >> >> EXPORT_SYMBOL_GPL(kernfs_path_from_node) >> >> I've rethought it. The export APIs need to do null pointer check, right? > > No, callers should get this right. Are there any in-tree ones that do > not? Thanks. I got it. > > thanks, > > greg k-h > . >
diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c index f33b3baad07cb36..b2422265c86edf2 100644 --- a/fs/kernfs/dir.c +++ b/fs/kernfs/dir.c @@ -140,6 +140,9 @@ static int kernfs_path_from_node_locked(struct kernfs_node *kn_to, size_t depth_from, depth_to, len = 0; int i, j; + if (!buf) + return -EINVAL; + if (!kn_to) return strlcpy(buf, "(null)", buflen); @@ -149,9 +152,6 @@ static int kernfs_path_from_node_locked(struct kernfs_node *kn_to, if (kn_from == kn_to) return strlcpy(buf, "/", buflen); - if (!buf) - return -EINVAL; - common = kernfs_common_ancestor(kn_from, kn_to); if (WARN_ON(!common)) return -EINVAL;