All of lore.kernel.org
 help / color / mirror / Atom feed
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
> 
> 

  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.