All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: fra-build <zhanxusheng1024@gmail.com>
Cc: almaz.alexandrovich@paragon-software.com, ntfs3@lists.linux.dev,
	linux-kernel@vger.kernel.org, zhanxusheng@xiaomi.com
Subject: Re: [PATCH v4] fs/ntfs3: reject out-of-range evcn in mi_enum_attr()
Date: Fri, 15 May 2026 10:28:08 +0100	[thread overview]
Message-ID: <20260515102808.14134e02@pumpkin> (raw)
In-Reply-To: <20260515082305.54624-1-fra@build.local>

On Fri, 15 May 2026 16:23:05 +0800
fra-build <zhanxusheng1024@gmail.com> wrote:

> From: Zhan Xusheng <zhanxusheng@xiaomi.com>
> 
> In mi_enum_attr(), the start/end VCN validation for non-resident
> attributes is:
> 
> 	if (svcn > evcn + 1) goto out;
> 
> When evcn is U64_MAX the "evcn + 1" expression wraps to 0 and any
> svcn passes the check.  For evcn values close to U64_MAX (but not
> equal to it) the right-hand side is still a meaningless near-wrap
> upper bound, so a malformed on-disk attribute with svcn == 0 and
> evcn near U64_MAX can pass mi_enum_attr() unrejected.
> 
> VCN (virtual cluster number) is a cluster index, so any valid evcn
> is bounded by the volume's total cluster count, which ntfs3 holds
> in sbi->used.bitmap.nbits (set up in ntfs_init_from_boot() before
> any caller of mi_enum_attr() runs).  Reject evcn values that fall
> outside this range; this rejects all out-of-range evcn values,
> not just U64_MAX, and as a side effect prevents the "evcn + 1"
> wraparound entirely.
> 
> Fixes: 013ff63b6494 ("fs/ntfs3: Add more attributes checks in mi_enum_attr()")
> Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>

Reviewed-by: David Laight <david.laight.linux@gmail.com>

> ---
>  fs/ntfs3/record.c | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/ntfs3/record.c b/fs/ntfs3/record.c
> index 32bdb034c2a3..4379446bcf96 100644
> --- a/fs/ntfs3/record.c
> +++ b/fs/ntfs3/record.c
> @@ -202,7 +202,7 @@ struct ATTRIB *mi_enum_attr(struct ntfs_inode *ni, struct mft_inode *mi,
>  	u32 used = le32_to_cpu(rec->used);
>  	u32 t32, off, asize, prev_type;
>  	u16 t16;
> -	u64 data_size, alloc_size, tot_size;
> +	u64 svcn, evcn, data_size, alloc_size, tot_size;
>  
>  	if (!attr) {
>  		u32 total = le32_to_cpu(rec->total);
> @@ -310,8 +310,17 @@ struct ATTRIB *mi_enum_attr(struct ntfs_inode *ni, struct mft_inode *mi,
>  	if (t32 && le16_to_cpu(attr->name_off) + t32 > t16)
>  		goto out;
>  
> -	/* Check start/end vcn. */
> -	if (le64_to_cpu(attr->nres.svcn) > le64_to_cpu(attr->nres.evcn) + 1)
> +	/*
> +	 * Check start/end vcn.  evcn must be a valid cluster index, i.e.
> +	 * less than the volume's total cluster count (sbi->used.bitmap.nbits);
> +	 * rejecting it here also keeps "svcn > evcn + 1" meaningful, since
> +	 * evcn == U64_MAX would wrap "evcn + 1" to 0.  svcn does not need
> +	 * its own bound: once evcn < nbits, "svcn > evcn + 1" implies
> +	 * svcn <= nbits.
> +	 */
> +	svcn = le64_to_cpu(attr->nres.svcn);
> +	evcn = le64_to_cpu(attr->nres.evcn);
> +	if (evcn >= mi->sbi->used.bitmap.nbits || svcn > evcn + 1)
>  		goto out;
>  
>  	data_size = le64_to_cpu(attr->nres.data_size);


  reply	other threads:[~2026-05-15  9:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-24  2:46 [PATCH] fs/ntfs3: reject evcn == U64_MAX in mi_enum_attr() Zhan Xusheng
2026-04-24  9:20 ` David Laight
2026-04-24 13:20   ` Zhan Xusheng
2026-04-24 15:15     ` David Laight
2026-04-25  2:03       ` Zhan Xusheng
2026-04-25 10:42         ` David Laight
2026-04-27  3:47           ` [PATCH v2] fs/ntfs3: reject invalid evcn == (u64)-1 " Zhan Xusheng
2026-04-27  3:50           ` [PATCH v3] " Zhan Xusheng
2026-05-15  8:23             ` [PATCH v4] fs/ntfs3: reject out-of-range evcn " fra-build
2026-05-15  9:28               ` David Laight [this message]
2026-05-28 14:03               ` Konstantin Komarov
2026-06-24  3:44                 ` [PATCH v5] " Zhan Xusheng

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=20260515102808.14134e02@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=almaz.alexandrovich@paragon-software.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ntfs3@lists.linux.dev \
    --cc=zhanxusheng1024@gmail.com \
    --cc=zhanxusheng@xiaomi.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.