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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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?




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux