linux-kernel - Re: [PATCH net 2/2] net: hns3: fix null pointer in debugfs issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <a0853cd9-cab5-441d-b181-8ba97f2f58b0@huawei.com>
Date: Tue, 28 Oct 2025 09:55:33 +0800
From: Jijie Shao <shaojijie@...wei.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: <shaojijie@...wei.com>, <davem@...emloft.net>, <edumazet@...gle.com>,
	<pabeni@...hat.com>, <andrew+netdev@...n.ch>, <horms@...nel.org>,
	<shenjian15@...wei.com>, <liuyonglong@...wei.com>, <chenhao418@...wei.com>,
	<lantao5@...wei.com>, <huangdonghua3@...artners.com>,
	<yangshuaisong@...artners.com>, <jonathan.cameron@...wei.com>,
	<salil.mehta@...wei.com>, <netdev@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net 2/2] net: hns3: fix null pointer in debugfs issue

on 2025/10/28 8:54, Jakub Kicinski wrote:
> On Thu, 23 Oct 2025 21:13:38 +0800 Jijie Shao wrote:
>> Currently, when debugfs and reset are executed concurrently,
>> some resources are released during the reset process,
>> which may cause debugfs to read null pointers or other anomalies.
>>
>> Therefore, in this patch, interception protection has been added
>> to debugfs operations that are sensitive to reset.
> You need to explain what prevents the state from changing immediately
> after you did the bit check. With no obvious locking in place I don't
> see how this reliably fixes the issue.

In July, we used seqfile to refactor debugfs.

Before the refactoring, all debugfs operations would check the reset status
(HNS3_NIC_STATE_INITED and HNS3_NIC_STATE_RESETTING) in the entry function.
After the refactoring, the entry function was removed, which led to the loss of protection.

This patch restores the protection behavior that existed before the refactoring.
Now our tests have already detected the null pointer issue.

As for the problem you mentioned, we have been discussing it recently.
There is a small time gap, checking the status before reading from debugfs is fine,
but there could still be issues if the device enters the reset state during the read process:

check state pass
	debugfs read start...
		do reset
			debugfs read end

Currently, we are still assessing the risk and discussing solutions for this issue.
After adding the entry protection, executing debugfs and reset concurrently has not
resulted in null pointers or other exceptions.

Thanks,
Jijie Shao