Re: [PATCH] fs: improve dump_mapping() robustness

Baolin Wang
2024-01-18T02:43:05Z

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?