diff options
| author | Al Viro <viro@zeniv.linux.org.uk> | 2026-05-12 00:29:37 -0400 |
|---|---|---|
| committer | Al Viro <viro@zeniv.linux.org.uk> | 2026-06-03 03:15:19 -0400 |
| commit | 10da12d352b7b2bb330a8609fdda9a58bf0e9856 (patch) | |
| tree | 308c71e2af1ffa92a0b45aeeb7dd724a27b21dab /rust/kernel/alloc/kvec/errors.rs | |
| parent | e43ffb69e0438cddd72aaa30898b4dc446f664f8 (diff) | |
configfs_lookup(): don't leave ->s_dentry dangling on failure
Normally ->s_dentry is cleared when dentry it's pointing to becomes
negative (on eviction, realistically). However, that only happens
if dentry gets to be positive in the first place; in case of inode
allocation failure dentry never becomes positive, so ->d_iput()
is not called at all.
We do part of what normally would've been done by configfs_d_iput()
(dropping the reference to configfs_dirent) manually, but we do
not clear ->s_dentry there. Sloppy as it is, it does not matter in
case of configfs_create_{dir,link}() - there configfs_dirent does
not survive dropping the sole reference to it.
However, for configfs_lookup() it *does* survive, with a dangling
pointer to soon to be freed dentry sitting it its ->s_dentry.
Subsequent getdents(2) in that directory will end up dereferencing
that pointer in order to pick the inode number. Use after free...
This is the minimal fix; the right approach is to set the linkage
between dentry and configfs_dirent only after we know that we have
an inode, but that takes more surgery and the bug had been there
since 2006, so...
Fixes: 3d0f89bb1694 ("configfs: Add permission and ownership to configfs objects") # 2.6.16-rc3
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'rust/kernel/alloc/kvec/errors.rs')
0 files changed, 0 insertions, 0 deletions
