[PATCH RFC] ubifs: Fix use-after-free in ubifs_tnc_end_commit
Zhihao Cheng
chengzhihao1 at huawei.com
Tue Oct 29 04:19:07 PDT 2024
在 2024/10/29 17:56, Ryder Wang 写道:
>> Thanks for reporting that :-). I noticed it a period time ago too, and I
>> found 'c->znext', 'c->cnext' and 'znode->cnext' won't be accessed (in
>> write mode) by other tasks, because there is only one function
>> do_commit() modifying them and do_commit() can be executed by at most
>> one task in any time.
>
> It looks the race condition can really happen in this case from the issue reporter.
> 1. do_commit (ubifs_bg_thread): it can finally touch unprotected znode while calling the function write_index().
> 2. ubifs_evict_inode (other kernel thread than ubifs_bg_thread): it can finally touch the znode in the function tnc_delete(). Even there is mutex protection for tnc_delete(), but it has no meaning because of do_commit (at the point 1) doesn't have such mutex protection while calling write_index().
> .
>
Emm.., this has been discussed in previous sessions.
All dirty znodes are gathered by function get_znodes_to_commit() which
is protected by c->tnc_mutex, and the 'cparent' member in all dirty
znodes is assigned with non-NULL. Then I think the znode memory freeing
path 'tnc_delete->kfree(znode)' cannot happen, because:
1) If a znode is dirtied, all its' ancestor znodes(a path from znode to
root znode) must be dirtied, which is guaranteed by UBIFS. See
dirty_cow_bottom_up/lookup_level0_dirty.
2) A dirty znode waiting for commit cannot be freed before write_index()
finished, which is guaranteed by tnc_delete:
if (znode->cnext) {
__set_bit(OBSOLETE_ZNODE, &znode->flags);
...
} else {
kfree(znode);
}
More information about the linux-mtd
mailing list