+60
−26
Loading
stable inclusion from stable-v6.6.75 commit 850e696f362729a163fb6af21a54cde565b71f75 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBLWT7 CVE: CVE-2024-57952 Reference: https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=850e696f362729a163fb6af21a54cde565b71f75 -------------------------------- [ Upstream commit b9b588f22a0c049a14885399e27625635ae6ef91 ] The mtree mechanism has been effective at creating directory offsets that are stable over multiple opendir instances. However, it has not been able to handle the subtleties of renames that are concurrent with readdir. Instead of using the mtree to emit entries in the order of their offset values, use it only to map incoming ctx->pos to a starting entry. Then use the directory's d_children list, which is already maintained properly by the dcache, to find the next child to emit. One of the sneaky things about this is that when the mtree-allocated offset value wraps (which is very rare), looking up ctx->pos++ is not going to find the next entry; it will return NULL. Instead, by following the d_children list, the offset values can appear in any order but all of the entries in the directory will be visited eventually. Note also that the readdir() is guaranteed to reach the tail of this list. Entries are added only at the head of d_children, and readdir walks from its current position in that list towards its tail. Signed-off-by:Chuck Lever <chuck.lever@oracle.com> Link: https://lore.kernel.org/r/20241228175522.1854234-6-cel@kernel.org Signed-off-by:
Christian Brauner <brauner@kernel.org> Conflicts: fs/libfs.c [0e4a862174f2("libfs: Convert simple directory offsets to use a Maple Tree") not applied for stable] Signed-off-by:
Yongjian Sun <sunyongjian1@huawei.com>