Wind River Support Network

Description

In the Linux kernel, the following vulnerability has been resolved:[EOL][EOL]vfs: Don't leak disconnected dentries on umount[EOL][EOL]When user calls open_by_handle_at() on some inode that is not cached, we[EOL]will create disconnected dentry for it. If such dentry is a directory,[EOL]exportfs_decode_fh_raw() will then try to connect this dentry to the[EOL]dentry tree through reconnect_path(). It may happen for various reasons[EOL](such as corrupted fs or race with rename) that the call to[EOL]lookup_one_unlocked() in reconnect_one() will fail to find the dentry we[EOL]are trying to reconnect and instead create a new dentry under the[EOL]parent. Now this dentry will not be marked as disconnected although the[EOL]parent still may well be disconnected (at least in case this[EOL]inconsistency happened because the fs is corrupted and .. doesn't point[EOL]to the real parent directory). This creates inconsistency in[EOL]disconnected flags but AFAICS it was mostly harmless. At least until[EOL]commit f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon")[EOL]which removed adding of most disconnected dentries to sb->s_anon list.[EOL]Thus after this commit cleanup of disconnected dentries implicitely[EOL]relies on the fact that dput() will immediately reclaim such dentries.[EOL]However when some leaf dentry isn't marked as disconnected, as in the[EOL]scenario described above, the reclaim doesn't happen and the dentries[EOL]are "leaked". Memory reclaim can eventually reclaim them but otherwise[EOL]they stay in memory and if umount comes first, we hit infamous "Busy[EOL]inodes after unmount" bug. Make sure all dentries created under a[EOL]disconnected parent are marked as disconnected as well.