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 (file)
index 0000000..d3524b4
--- /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 <asmadeus@codewreck.org>
+Date: Tue, 21 May 2024 21:13:36 +0900
+Subject: 9p: add missing locking around taking dentry fid list
+
+From: Dominique Martinet <asmadeus@codewreck.org>
+
+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 <linux_oss@crudebyte.com>
+Message-ID: <20240521122947.1080227-1-asmadeus@codewreck.org>
+Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
+Signed-off-by: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 (file)
index 0000000..d9ee51c
--- /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 <zhanchengbin1@huawei.com>
+Date: Tue, 3 Jan 2023 10:28:12 +0800
+Subject: ext4: fix inode tree inconsistency caused by ENOMEM
+
+From: zhanchengbin <zhanchengbin1@huawei.com>
+
+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 <zhanchengbin1@huawei.com>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Link: https://lore.kernel.org/r/20230103022812.130603-1-zhanchengbin1@huawei.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Cc: Baokun Li <libaokun1@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 8a435e11618413a5b380d6b27915ac1861dc3255..eb612208b8a431dfbf5c0640ab70998279a5b551 100644 (file)
--- 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