From: Greg Kroah-Hartman Date: Fri, 10 Feb 2023 14:19:58 +0000 (+0100) Subject: 5.15-stable patches X-Git-Tag: v6.1.12~45 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=d395865fd2b7d4c271830cd955e1ac85c26a1570;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: btrfs-limit-device-extents-to-the-device-size.patch btrfs-zlib-zero-initialize-zlib-workspace.patch --- diff --git a/queue-5.15/btrfs-limit-device-extents-to-the-device-size.patch b/queue-5.15/btrfs-limit-device-extents-to-the-device-size.patch new file mode 100644 index 00000000000..ea27bf95f98 --- /dev/null +++ b/queue-5.15/btrfs-limit-device-extents-to-the-device-size.patch @@ -0,0 +1,66 @@ +From 3c538de0f2a74d50aff7278c092f88ae59cee688 Mon Sep 17 00:00:00 2001 +From: Josef Bacik +Date: Wed, 18 Jan 2023 16:35:13 -0500 +Subject: btrfs: limit device extents to the device size + +From: Josef Bacik + +commit 3c538de0f2a74d50aff7278c092f88ae59cee688 upstream. + +There was a recent regression in btrfs/177 that started happening with +the size class patches ("btrfs: introduce size class to block group +allocator"). This however isn't a regression introduced by those +patches, but rather the bug was uncovered by a change in behavior in +these patches. The patches triggered more chunk allocations in the +^free-space-tree case, which uncovered a race with device shrink. + +The problem is we will set the device total size to the new size, and +use this to find a hole for a device extent. However during shrink we +may have device extents allocated past this range, so we could +potentially find a hole in a range past our new shrink size. We don't +actually limit our found extent to the device size anywhere, we assume +that we will not find a hole past our device size. This isn't true with +shrink as we're relocating block groups and thus creating holes past the +device size. + +Fix this by making sure we do not search past the new device size, and +if we wander into any device extents that start after our device size +simply break from the loop and use whatever hole we've already found. + +CC: stable@vger.kernel.org # 4.14+ +Signed-off-by: Josef Bacik +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/volumes.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/fs/btrfs/volumes.c ++++ b/fs/btrfs/volumes.c +@@ -1646,7 +1646,7 @@ again: + if (ret < 0) + goto out; + +- while (1) { ++ while (search_start < search_end) { + l = path->nodes[0]; + slot = path->slots[0]; + if (slot >= btrfs_header_nritems(l)) { +@@ -1669,6 +1669,9 @@ again: + if (key.type != BTRFS_DEV_EXTENT_KEY) + goto next; + ++ if (key.offset > search_end) ++ break; ++ + if (key.offset > search_start) { + hole_size = key.offset - search_start; + dev_extent_hole_check(device, &search_start, &hole_size, +@@ -1729,6 +1732,7 @@ next: + else + ret = 0; + ++ ASSERT(max_hole_start + max_hole_size <= search_end); + out: + btrfs_free_path(path); + *start = max_hole_start; diff --git a/queue-5.15/btrfs-zlib-zero-initialize-zlib-workspace.patch b/queue-5.15/btrfs-zlib-zero-initialize-zlib-workspace.patch new file mode 100644 index 00000000000..5147d1ecfcc --- /dev/null +++ b/queue-5.15/btrfs-zlib-zero-initialize-zlib-workspace.patch @@ -0,0 +1,36 @@ +From eadd7deca0ad8a83edb2b894d8326c78e78635d6 Mon Sep 17 00:00:00 2001 +From: Alexander Potapenko +Date: Tue, 24 Jan 2023 12:32:34 +0100 +Subject: btrfs: zlib: zero-initialize zlib workspace + +From: Alexander Potapenko + +commit eadd7deca0ad8a83edb2b894d8326c78e78635d6 upstream. + +KMSAN reports uses of uninitialized memory in zlib's longest_match() +called on memory originating from zlib_alloc_workspace(). +This issue is known by zlib maintainers and is claimed to be harmless, +but to be on the safe side we'd better initialize the memory. + +Link: https://zlib.net/zlib_faq.html#faq36 +Reported-by: syzbot+14d9e7602ebdf7ec0a60@syzkaller.appspotmail.com +CC: stable@vger.kernel.org # 5.4+ +Signed-off-by: Alexander Potapenko +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/zlib.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/btrfs/zlib.c ++++ b/fs/btrfs/zlib.c +@@ -63,7 +63,7 @@ struct list_head *zlib_alloc_workspace(u + + workspacesize = max(zlib_deflate_workspacesize(MAX_WBITS, MAX_MEM_LEVEL), + zlib_inflate_workspacesize()); +- workspace->strm.workspace = kvmalloc(workspacesize, GFP_KERNEL); ++ workspace->strm.workspace = kvzalloc(workspacesize, GFP_KERNEL); + workspace->level = level; + workspace->buf = NULL; + /* diff --git a/queue-5.15/series b/queue-5.15/series index cebf2a2de4c..483b3c27926 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -3,3 +3,5 @@ nvmem-core-fix-cleanup-after-dev_set_name.patch nvmem-core-fix-registration-vs-use-race.patch mm-migration-return-errno-when-isolate_huge_page-fai.patch migrate-hugetlb-check-for-hugetlb-shared-pmd-in-node.patch +btrfs-limit-device-extents-to-the-device-size.patch +btrfs-zlib-zero-initialize-zlib-workspace.patch