From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
patches@lists.linux.dev,
syzbot+4376a9a073770c173269@syzkaller.appspotmail.com,
David Sterba <dsterba@suse.com>, Sasha Levin <sashal@kernel.org>
Subject: [PATCH 5.4 04/13] btrfs: send: limit number of clones and allocated memory size
Date: Wed, 1 Mar 2023 19:07:27 +0100 [thread overview]
Message-ID: <20230301180651.325879104@linuxfoundation.org> (raw)
In-Reply-To: <20230301180651.177668495@linuxfoundation.org>
From: David Sterba <dsterba@suse.com>
[ Upstream commit 33e17b3f5ab74af12aca58c515bc8424ff69a343 ]
The arg->clone_sources_count is u64 and can trigger a warning when a
huge value is passed from user space and a huge array is allocated.
Limit the allocated memory to 8MiB (can be increased if needed), which
in turn limits the number of clone sources to 8M / sizeof(struct
clone_root) = 8M / 40 = 209715. Real world number of clones is from
tens to hundreds, so this is future proof.
Reported-by: syzbot+4376a9a073770c173269@syzkaller.appspotmail.com
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/btrfs/send.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index fb1996980d265..97417b5569a98 100644
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -7347,10 +7347,10 @@ long btrfs_ioctl_send(struct file *mnt_file, struct btrfs_ioctl_send_args *arg)
/*
* Check that we don't overflow at later allocations, we request
* clone_sources_count + 1 items, and compare to unsigned long inside
- * access_ok.
+ * access_ok. Also set an upper limit for allocation size so this can't
+ * easily exhaust memory. Max number of clone sources is about 200K.
*/
- if (arg->clone_sources_count >
- ULONG_MAX / sizeof(struct clone_root) - 1) {
+ if (arg->clone_sources_count > SZ_8M / sizeof(struct clone_root)) {
ret = -EINVAL;
goto out;
}
--
2.39.0
next prev parent reply other threads:[~2023-03-01 18:08 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-01 18:07 [PATCH 5.4 00/13] 5.4.234-rc1 review Greg Kroah-Hartman
2023-03-01 18:07 ` [PATCH 5.4 01/13] arm64: dts: rockchip: drop unused LED mode property from rk3328-roc-cc Greg Kroah-Hartman
2023-03-01 18:07 ` [PATCH 5.4 02/13] ARM: dts: rockchip: add power-domains property to dp node on rk3288 Greg Kroah-Hartman
2023-03-01 18:07 ` [PATCH 5.4 03/13] ACPI: NFIT: fix a potential deadlock during NFIT teardown Greg Kroah-Hartman
2023-03-01 18:07 ` Greg Kroah-Hartman [this message]
2023-03-01 18:07 ` [PATCH 5.4 05/13] IB/hfi1: Assign npages earlier Greg Kroah-Hartman
2023-03-01 18:07 ` [PATCH 5.4 06/13] neigh: make sure used and confirmed times are valid Greg Kroah-Hartman
2023-03-01 18:07 ` [PATCH 5.4 07/13] HID: core: Fix deadloop in hid_apply_multiplier Greg Kroah-Hartman
2023-03-01 18:07 ` [PATCH 5.4 08/13] bpf: bpf_fib_lookup should not return neigh in NUD_FAILED state Greg Kroah-Hartman
2023-03-01 18:07 ` [PATCH 5.4 09/13] net: Remove WARN_ON_ONCE(sk->sk_forward_alloc) from sk_stream_kill_queues() Greg Kroah-Hartman
2023-03-01 18:07 ` [PATCH 5.4 10/13] vc_screen: dont clobber return value in vcs_read Greg Kroah-Hartman
2023-03-01 18:07 ` [PATCH 5.4 11/13] dmaengine: sh: rcar-dmac: Check for error num after dma_set_max_seg_size Greg Kroah-Hartman
2023-03-01 18:07 ` [PATCH 5.4 12/13] USB: serial: option: add support for VW/Skoda "Carstick LTE" Greg Kroah-Hartman
2023-03-01 18:07 ` [PATCH 5.4 13/13] USB: core: Dont hold device lock while reading the "descriptors" sysfs file Greg Kroah-Hartman
2023-03-01 18:48 ` [PATCH 5.4 00/13] 5.4.234-rc1 review Slade Watkins
2023-03-01 19:26 ` Florian Fainelli
2023-03-02 1:50 ` Shuah Khan
2023-03-02 7:27 ` Jon Hunter
2023-03-02 11:32 ` Sudip Mukherjee (Codethink)
2023-03-02 13:38 ` Naresh Kamboju
2023-03-03 1:29 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230301180651.325879104@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=dsterba@suse.com \
--cc=patches@lists.linux.dev \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
--cc=syzbot+4376a9a073770c173269@syzkaller.appspotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.