From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
patches@lists.linux.dev, Eric Biggers <ebiggers@google.com>
Subject: [PATCH 6.3 04/11] fsverity: explicitly check for buffer overflow in build_merkle_tree()
Date: Fri, 28 Apr 2023 13:27:39 +0200 [thread overview]
Message-ID: <20230428112040.046587104@linuxfoundation.org> (raw)
In-Reply-To: <20230428112039.886496777@linuxfoundation.org>
From: Eric Biggers <ebiggers@google.com>
commit 39049b69ec9fc125fa1f314165dcc86f72cb72ec upstream.
The new Merkle tree construction algorithm is a bit fragile in that it
may overflow the 'root_hash' array if the tree actually generated does
not match the calculated tree parameters.
This should never happen unless there is a filesystem bug that allows
the file size to change despite deny_write_access(), or a bug in the
Merkle tree logic itself. Regardless, it's fairly easy to check for
buffer overflow here, so let's do so.
This is a robustness improvement only; this case is not currently known
to be reachable. I've added a Fixes tag anyway, since I recommend that
this be included in kernels that have the mentioned commit.
Fixes: 56124d6c87fd ("fsverity: support enabling with tree block size < PAGE_SIZE")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230328041505.110162-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/verity/enable.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/fs/verity/enable.c
+++ b/fs/verity/enable.c
@@ -13,6 +13,7 @@
struct block_buffer {
u32 filled;
+ bool is_root_hash;
u8 *data;
};
@@ -24,6 +25,14 @@ static int hash_one_block(struct inode *
struct block_buffer *next = cur + 1;
int err;
+ /*
+ * Safety check to prevent a buffer overflow in case of a filesystem bug
+ * that allows the file size to change despite deny_write_access(), or a
+ * bug in the Merkle tree logic itself
+ */
+ if (WARN_ON_ONCE(next->is_root_hash && next->filled != 0))
+ return -EINVAL;
+
/* Zero-pad the block if it's shorter than the block size. */
memset(&cur->data[cur->filled], 0, params->block_size - cur->filled);
@@ -97,6 +106,7 @@ static int build_merkle_tree(struct file
}
}
buffers[num_levels].data = root_hash;
+ buffers[num_levels].is_root_hash = true;
BUILD_BUG_ON(sizeof(level_offset) != sizeof(params->level_start));
memcpy(level_offset, params->level_start, sizeof(level_offset));
next prev parent reply other threads:[~2023-04-28 11:28 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-28 11:27 [PATCH 6.3 00/11] 6.3.1-rc1 review Greg Kroah-Hartman
2023-04-28 11:27 ` [PATCH 6.3 01/11] wifi: brcmfmac: slab-out-of-bounds read in brcmf_get_assoc_ies() Greg Kroah-Hartman
2023-04-28 11:27 ` [PATCH 6.3 02/11] fsverity: reject FS_IOC_ENABLE_VERITY on mode 3 fds Greg Kroah-Hartman
2023-04-28 11:27 ` [PATCH 6.3 03/11] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var Greg Kroah-Hartman
2023-04-28 11:27 ` Greg Kroah-Hartman [this message]
2023-04-28 11:27 ` [PATCH 6.3 05/11] gpiolib: acpi: Add a ignore wakeup quirk for Clevo NL5xNU Greg Kroah-Hartman
2023-04-28 11:27 ` [PATCH 6.3 06/11] bluetooth: Perform careful capability checks in hci_sock_ioctl() Greg Kroah-Hartman
2023-04-28 11:27 ` [PATCH 6.3 07/11] wifi: brcmfmac: add Cypress 43439 SDIO ids Greg Kroah-Hartman
2023-04-28 11:27 ` [PATCH 6.3 08/11] btrfs: fix uninitialized variable warnings Greg Kroah-Hartman
2023-04-28 11:27 ` [PATCH 6.3 09/11] mm/mremap: fix vm_pgoff in vma_merge() case 3 Greg Kroah-Hartman
2023-04-28 11:27 ` [PATCH 6.3 10/11] USB: serial: option: add UNISOC vendor and TOZED LT70C product Greg Kroah-Hartman
2023-04-28 11:27 ` [PATCH 6.3 11/11] driver core: Dont require dynamic_debug for initcall_debug probe timing Greg Kroah-Hartman
2023-04-28 16:42 ` [PATCH 6.3 00/11] 6.3.1-rc1 review Markus Reichelt
2023-04-28 22:24 ` Shuah Khan
2023-04-28 23:14 ` Naresh Kamboju
2023-04-29 0:37 ` Rudi Heitbaum
2023-04-29 3:56 ` Ron Economos
2023-04-29 4:10 ` Guenter Roeck
2023-04-29 7:39 ` Bagas Sanjaya
2023-04-29 17:14 ` Florian Fainelli
2023-05-02 8:17 ` Chris Paterson
2023-05-02 16:18 ` Jon Hunter
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=20230428112040.046587104@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=ebiggers@google.com \
--cc=patches@lists.linux.dev \
--cc=stable@vger.kernel.org \
/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.