From: Greg Kroah-Hartman Date: Fri, 10 Feb 2023 14:19:47 +0000 (+0100) Subject: 5.10-stable patches X-Git-Tag: v6.1.12~46 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=78242c67996b6fd00cad0ff13c62c106e24bd228;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-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.10/btrfs-limit-device-extents-to-the-device-size.patch b/queue-5.10/btrfs-limit-device-extents-to-the-device-size.patch new file mode 100644 index 00000000000..1e325a1aad4 --- /dev/null +++ b/queue-5.10/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 +@@ -1580,7 +1580,7 @@ again: + goto out; + } + +- while (1) { ++ while (search_start < search_end) { + l = path->nodes[0]; + slot = path->slots[0]; + if (slot >= btrfs_header_nritems(l)) { +@@ -1603,6 +1603,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, +@@ -1663,6 +1666,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.10/btrfs-zlib-zero-initialize-zlib-workspace.patch b/queue-5.10/btrfs-zlib-zero-initialize-zlib-workspace.patch new file mode 100644 index 00000000000..5147d1ecfcc --- /dev/null +++ b/queue-5.10/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.10/series b/queue-5.10/series index 19fe783bf50..031fdaed0c9 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -95,3 +95,5 @@ bpf-do-not-reject-when-the-stack-read-size-is-differ.patch iio-adc-twl6030-enable-measurement-of-vac.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