From: <zhangqiuhao@huawei.com>
To: "Richard Russon (FlatCap)" <ldm@flatcap.org>,
Jens Axboe <axboe@kernel.dk>
Cc: <hewenliang4@huawei.com>, <yangyun50@huawei.com>,
<chenrenhui1@huawei.com>, <wuguanghao3@h-partners.com>,
<wozizhi@huawei.com>, <linux-ntfs-dev@lists.sourceforge.net>,
<linux-block@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: [PATCH] block: partitions: ldm: avoid overflow in VMDB size check
Date: Mon, 2 Nov 2026 14:38:17 +0800 [thread overview]
Message-ID: <179360149774.20265.17257530536010482220@huawei.com> (raw)
ldm_validate_vmdb() can accept a VMDB whose declared VBLK extent
exceeds the TOCBLOCK configuration bitmap.
For example, these fields on a 4 MiB image pass the preceding PRIVHEAD
and TOCBLOCK bounds checks:
disk capacity = 8192 sectors
config_start = 6144 sectors
config_size = 2048 sectors
bitmap1_start = 17 sectors
bitmap1_size = 1024 sectors (524288 bytes)
vblk_size = 128 bytes
last_vblk_seq = 0x02000008 (33554440)
The configuration area fits on the disk, and the bitmap ends at sector
1041 within the 2048-sector area. The VBLK extent is 128 * 33554440 =
4294968320 bytes (4 GiB + 1024 bytes), so the VMDB should be rejected.
Both multiplicands are u32, however, so the product wraps to 1024 before
it is promoted to u64 for the comparison. The check evaluates
1024 > 524288 as false and incorrectly accepts the VMDB.
Cast vblk_size to u64 before multiplying. The check then evaluates
4294968320 > 524288 as true and rejects the out-of-range extent.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: zhangqiuhao <zhangqiuhao@huawei.com>
---
Based on Jens Axboe's for-next at
70866cfa169d5ee149364267289e71d50f9a7ae9.
block/partitions/ldm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/block/partitions/ldm.c b/block/partitions/ldm.c
index c0bdcae58..d5c133a33 100644
--- a/block/partitions/ldm.c
+++ b/block/partitions/ldm.c
@@ -458,7 +458,8 @@ static bool ldm_validate_vmdb(struct parsed_partitions *state,
* The last_vblkd_seq can be before the end of the vmdb, just make sure
* it is not out of bounds.
*/
- if ((vm->vblk_size * vm->last_vblk_seq) > (toc->bitmap1_size << 9)) {
+ if (((u64)vm->vblk_size * vm->last_vblk_seq) >
+ (toc->bitmap1_size << 9)) {
ldm_crit ("VMDB exceeds allowed size specified by TOCBLOCK. "
"Database is corrupt. Aborting.");
goto out;
--
2.33.0
reply other threads:[~2026-11-02 6:47 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=179360149774.20265.17257530536010482220@huawei.com \
--to=zhangqiuhao@huawei.com \
--cc=axboe@kernel.dk \
--cc=chenrenhui1@huawei.com \
--cc=hewenliang4@huawei.com \
--cc=ldm@flatcap.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-ntfs-dev@lists.sourceforge.net \
--cc=wozizhi@huawei.com \
--cc=wuguanghao3@h-partners.com \
--cc=yangyun50@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®