Received-SPF: pass (google.com: domain of linux-kernel+bounces-29666-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <d5979f89-7a84-423a-a1c7-29bdbf7c2bc1@linux.alibaba.com>
Date: Thu, 18 Jan 2024 10:43:26 +0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] fs: improve dump_mapping() robustness
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: akpm@linux-foundation.org, willy@infradead.org, brauner@kernel.org,
 jack@suse.cz, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
 linux-kernel@vger.kernel.org
References: <937ab1f87328516821d39be672b6bc18861d9d3e.1705391420.git.baolin.wang@linux.alibaba.com>
 <20240118013857.GO1674809@ZenIV>
From: Baolin Wang <baolin.wang@linux.alibaba.com>
In-Reply-To: <20240118013857.GO1674809@ZenIV>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 1/18/2024 9:38 AM, Al Viro wrote:
> On Tue, Jan 16, 2024 at 03:53:35PM +0800, Baolin Wang wrote:
> 
>> With checking the 'dentry.parent' and 'dentry.d_name.name' used by
>> dentry_name(), I can see dump_mapping() will output the invalid dentry
>> instead of crashing the system when this issue is reproduced again.
> 
>>   	dentry_ptr = container_of(dentry_first, struct dentry, d_u.d_alias);
>> -	if (get_kernel_nofault(dentry, dentry_ptr)) {
>> +	if (get_kernel_nofault(dentry, dentry_ptr) ||
>> +	    !dentry.d_parent || !dentry.d_name.name) {
>>   		pr_warn("aops:%ps ino:%lx invalid dentry:%px\n",
>>   				a_ops, ino, dentry_ptr);
>>   		return;
> 
> That's nowhere near enough.  Your ->d_name.name can bloody well be pointing
> to an external name that gets freed right under you.  Legitimately so.
> 
> Think what happens if dentry has a long name (longer than would fit into
> the embedded array) and gets renamed name just after you copy it into
> a local variable.  Old name will get freed.  Yes, freeing is RCU-delayed,
> but I don't see anything that would prevent your thread losing CPU
> and not getting it back until after the sucker's been freed.

Yes, that's possible. And this appears to be a use-after-free issue in 
the existing code, which is different from the issue that my patch 
addressed.

So how about adding a rcu_read_lock() before copying the dentry to a 
local variable in case the old name is freed?