From: Greg Kroah-Hartman Date: Fri, 10 Feb 2023 14:19:38 +0000 (+0100) Subject: 5.4-stable patches X-Git-Tag: v6.1.12~47 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=f4e4386ac983a8075cf86b3403092726ffbe05be;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-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.4/btrfs-limit-device-extents-to-the-device-size.patch b/queue-5.4/btrfs-limit-device-extents-to-the-device-size.patch new file mode 100644 index 00000000000..a0464397cdd --- /dev/null +++ b/queue-5.4/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 +@@ -1701,7 +1701,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)) { +@@ -1724,6 +1724,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; + +@@ -1794,6 +1797,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.4/btrfs-zlib-zero-initialize-zlib-workspace.patch b/queue-5.4/btrfs-zlib-zero-initialize-zlib-workspace.patch new file mode 100644 index 00000000000..6bde1b76325 --- /dev/null +++ b/queue-5.4/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 +@@ -74,7 +74,7 @@ static struct list_head *zlib_alloc_work + + 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 = kmalloc(PAGE_SIZE, GFP_KERNEL); + if (!workspace->strm.workspace || !workspace->buf) diff --git a/queue-5.4/series b/queue-5.4/series index 92348aeb55b..304000da5cf 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -57,3 +57,5 @@ fbdev-smscufx-fix-error-handling-code-in-ufx_usb_probe.patch f2fs-fix-to-do-sanity-check-on-i_extra_isize-in-is_alive.patch wifi-brcmfmac-check-the-count-value-of-channel-spec-to-prevent-out-of-bounds-reads.patch iio-adc-twl6030-enable-measurement-of-vac.patch +btrfs-limit-device-extents-to-the-device-size.patch +btrfs-zlib-zero-initialize-zlib-workspace.patch