From: "Darrick J. Wong" <djwong@kernel.org>
To: Manognya Singuru <msinguru@redhat.com>
Cc: linux-xfs@vger.kernel.org, aalbersh@redhat.com
Subject: Re: [PATCH] mdrestore: fix extent length overflow in v2 restore path
Date: Thu, 9 Jul 2026 07:33:05 -0700 [thread overview]
Message-ID: <20260709143305.GC15210@frogsfrogsfrogs> (raw)
In-Reply-To: <20260709103915.275363-1-msinguru@redhat.com>
On Thu, Jul 09, 2026 at 04:09:15PM +0530, Manognya Singuru wrote:
> Aisle Research reported that a crafted metadump v2 extent
> length can overflow the signed int used for length,
> leading to incorrect size calculations and a
> potential heap buffer over-read in restore_meta_extent().
>
> Change the length type to uint64_t and ensure all size
> arithmetic in 64-bit before converting to size_t for I/O
> calls.
>
> Signed-off-by: Manognya Singuru <msinguru@redhat.com>
> ---
> mdrestore/xfs_mdrestore.c | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/mdrestore/xfs_mdrestore.c b/mdrestore/xfs_mdrestore.c
> index f10c4bef..9c7f77e0 100644
> --- a/mdrestore/xfs_mdrestore.c
> +++ b/mdrestore/xfs_mdrestore.c
> @@ -395,11 +395,9 @@ restore_meta_extent(
> char *device,
> void *buf,
> uint64_t offset,
> - int len)
> + uint64_t len)
Please make the indentation consistent with the existing code here and
elsewhere in the patch.
> {
> - int io_size;
> -
> - io_size = min(len, MDR_IO_BUF_SIZE);
> + size_t io_size = min(len, MDR_IO_BUF_SIZE);
>
> do {
> if (fread(buf, io_size, 1, md_fp) != 1)
> @@ -428,7 +426,7 @@ restore_v2(
> int64_t mb_read = 0;
> int64_t bytes_read;
> uint64_t offset;
> - int len;
> + uint64_t len;
>
> block_buffer = malloc(MDR_IO_BUF_SIZE);
> if (block_buffer == NULL)
> @@ -442,7 +440,7 @@ restore_v2(
> XME_ADDR_DATA_DEVICE)
> fatal("Invalid superblock disk address/length\n");
>
> - len = BBTOB(be32_to_cpu(xme.xme_len));
> + len = BBTOB((uint64_t)be32_to_cpu(xme.xme_len));
/me wonders if BBTOB ought to cast its parameter to uint64_t but this
change here avoids shift truncation if xme_len is large, so
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
--D
>
> if (fread(block_buffer, len, 1, md_fp) != 1)
> fatal("error reading from metadump file\n");
> @@ -503,7 +501,7 @@ restore_v2(
> break;
> }
>
> - len = BBTOB(be32_to_cpu(xme.xme_len));
> + len = BBTOB((uint64_t)be32_to_cpu(xme.xme_len));
>
> restore_meta_extent(md_fp, fd, device, block_buffer, offset,
> len);
> --
> 2.54.0
>
>
next prev parent reply other threads:[~2026-07-09 14:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 10:39 [PATCH] mdrestore: fix extent length overflow in v2 restore path Manognya Singuru
2026-07-09 14:33 ` Darrick J. Wong [this message]
2026-07-13 6:20 ` Manognya Singuru
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=20260709143305.GC15210@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=aalbersh@redhat.com \
--cc=linux-xfs@vger.kernel.org \
--cc=msinguru@redhat.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.