From: Greg Kroah-Hartman Date: Tue, 8 Oct 2024 10:37:58 +0000 (+0200) Subject: 5.15-stable patches X-Git-Tag: v6.6.55~27 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=ca49df9a47151465dfebd60557a6314a3ede8fea;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: 9p-add-missing-locking-around-taking-dentry-fid-list.patch ext4-fix-inode-tree-inconsistency-caused-by-enomem.patch --- diff --git a/queue-5.15/9p-add-missing-locking-around-taking-dentry-fid-list.patch b/queue-5.15/9p-add-missing-locking-around-taking-dentry-fid-list.patch new file mode 100644 index 00000000000..d3524b4acda --- /dev/null +++ b/queue-5.15/9p-add-missing-locking-around-taking-dentry-fid-list.patch @@ -0,0 +1,77 @@ +From c898afdc15645efb555acb6d85b484eb40a45409 Mon Sep 17 00:00:00 2001 +From: Dominique Martinet +Date: Tue, 21 May 2024 21:13:36 +0900 +Subject: 9p: add missing locking around taking dentry fid list + +From: Dominique Martinet + +commit c898afdc15645efb555acb6d85b484eb40a45409 upstream. + +Fix a use-after-free on dentry's d_fsdata fid list when a thread +looks up a fid through dentry while another thread unlinks it: + +UAF thread: +refcount_t: addition on 0; use-after-free. + p9_fid_get linux/./include/net/9p/client.h:262 + v9fs_fid_find+0x236/0x280 linux/fs/9p/fid.c:129 + v9fs_fid_lookup_with_uid linux/fs/9p/fid.c:181 + v9fs_fid_lookup+0xbf/0xc20 linux/fs/9p/fid.c:314 + v9fs_vfs_getattr_dotl+0xf9/0x360 linux/fs/9p/vfs_inode_dotl.c:400 + vfs_statx+0xdd/0x4d0 linux/fs/stat.c:248 + +Freed by: + p9_fid_destroy (inlined) + p9_client_clunk+0xb0/0xe0 linux/net/9p/client.c:1456 + p9_fid_put linux/./include/net/9p/client.h:278 + v9fs_dentry_release+0xb5/0x140 linux/fs/9p/vfs_dentry.c:55 + v9fs_remove+0x38f/0x620 linux/fs/9p/vfs_inode.c:518 + vfs_unlink+0x29a/0x810 linux/fs/namei.c:4335 + +The problem is that d_fsdata was not accessed under d_lock, because +d_release() normally is only called once the dentry is otherwise no +longer accessible but since we also call it explicitly in v9fs_remove +that lock is required: +move the hlist out of the dentry under lock then unref its fids once +they are no longer accessible. + +Fixes: 154372e67d40 ("fs/9p: fix create-unlink-getattr idiom") +Cc: stable@vger.kernel.org +Reported-by: Meysam Firouzi +Reported-by: Amirmohammad Eftekhar +Reviewed-by: Christian Schoenebeck +Message-ID: <20240521122947.1080227-1-asmadeus@codewreck.org> +Signed-off-by: Dominique Martinet +Signed-off-by: Samasth Norway Ananda +Signed-off-by: Greg Kroah-Hartman +--- + fs/9p/vfs_dentry.c | 9 +++++++-- + 1 file changed, 7 insertions(+), 2 deletions(-) + +diff --git a/fs/9p/vfs_dentry.c b/fs/9p/vfs_dentry.c +index c2736af97884f..afcf4711ac2a8 100644 +--- a/fs/9p/vfs_dentry.c ++++ b/fs/9p/vfs_dentry.c +@@ -52,12 +52,17 @@ static int v9fs_cached_dentry_delete(const struct dentry *dentry) + static void v9fs_dentry_release(struct dentry *dentry) + { + struct hlist_node *p, *n; ++ struct hlist_head head; + + p9_debug(P9_DEBUG_VFS, " dentry: %pd (%p)\n", + dentry, dentry); +- hlist_for_each_safe(p, n, (struct hlist_head *)&dentry->d_fsdata) ++ ++ spin_lock(&dentry->d_lock); ++ hlist_move_list((struct hlist_head *)&dentry->d_fsdata, &head); ++ spin_unlock(&dentry->d_lock); ++ ++ hlist_for_each_safe(p, n, &head) + p9_client_clunk(hlist_entry(p, struct p9_fid, dlist)); +- dentry->d_fsdata = NULL; + } + + static int v9fs_lookup_revalidate(struct dentry *dentry, unsigned int flags) +-- +2.46.0 + + diff --git a/queue-5.15/ext4-fix-inode-tree-inconsistency-caused-by-enomem.patch b/queue-5.15/ext4-fix-inode-tree-inconsistency-caused-by-enomem.patch new file mode 100644 index 00000000000..d9ee51c124e --- /dev/null +++ b/queue-5.15/ext4-fix-inode-tree-inconsistency-caused-by-enomem.patch @@ -0,0 +1,45 @@ +From 3f5424790d4377839093b68c12b130077a4e4510 Mon Sep 17 00:00:00 2001 +From: zhanchengbin +Date: Tue, 3 Jan 2023 10:28:12 +0800 +Subject: ext4: fix inode tree inconsistency caused by ENOMEM + +From: zhanchengbin + +commit 3f5424790d4377839093b68c12b130077a4e4510 upstream. + +If ENOMEM fails when the extent is splitting, we need to restore the length +of the split extent. +In the ext4_split_extent_at function, only in ext4_ext_create_new_leaf will +it alloc memory and change the shape of the extent tree,even if an ENOMEM +is returned at this time, the extent tree is still self-consistent, Just +restore the split extent lens in the function ext4_split_extent_at. + +ext4_split_extent_at + ext4_ext_insert_extent + ext4_ext_create_new_leaf + 1)ext4_ext_split + ext4_find_extent + 2)ext4_ext_grow_indepth + ext4_find_extent + +Signed-off-by: zhanchengbin +Reviewed-by: Jan Kara +Link: https://lore.kernel.org/r/20230103022812.130603-1-zhanchengbin1@huawei.com +Signed-off-by: Theodore Ts'o +Cc: Baokun Li +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/extents.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/ext4/extents.c ++++ b/fs/ext4/extents.c +@@ -3232,7 +3232,7 @@ static int ext4_split_extent_at(handle_t + ext4_ext_mark_unwritten(ex2); + + err = ext4_ext_insert_extent(handle, inode, ppath, &newex, flags); +- if (err != -ENOSPC && err != -EDQUOT) ++ if (err != -ENOSPC && err != -EDQUOT && err != -ENOMEM) + goto out; + + /* diff --git a/queue-5.15/series b/queue-5.15/series index 8a435e11618..eb612208b8a 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -584,3 +584,5 @@ clk-qcom-gcc-sc8180x-add-gpll9-support.patch acpi-battery-simplify-battery-hook-locking.patch acpi-battery-fix-possible-crash-when-unregistering-a.patch revert-arm64-dts-qcom-sm8250-switch-ufs-qmp-phy-to-new-style-of-bindings.patch +ext4-fix-inode-tree-inconsistency-caused-by-enomem.patch +9p-add-missing-locking-around-taking-dentry-fid-list.patch