All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
To: fra-build <zhanxusheng1024@gmail.com>, <david.laight.linux@gmail.com>
Cc: <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: Thu, 28 May 2026 16:03:13 +0200	[thread overview]
Message-ID: <71e5333c-bb8a-4886-bfa1-e1b4cb8ea451@paragon-software.com> (raw)
In-Reply-To: <20260515082305.54624-1-fra@build.local>

On 5/15/26 10:23, fra-build 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>
> ---
>   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);

Hello,

This patch doesn't apply as-is - during internal testing it caused a
number of failures.

I believe the cause is empty non-resident attributes, which are
legitimately encoded with svcn=0 and evcn=U64_MAX (a -1 sentinel for no
allocated clusters). The new evcn >= sbi->used.bitmap.nbits check rejects
those valid attributes. The U64_MAX wraparound you're guarding against is
real, but it needs to be handled without rejecting the empty-attribute
sentinel.

Not applied yet. Thanks.

Regards,
Konstantin


  parent reply	other threads:[~2026-05-28 14:03 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
2026-05-28 14:03               ` Konstantin Komarov [this message]
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=71e5333c-bb8a-4886-bfa1-e1b4cb8ea451@paragon-software.com \
    --to=almaz.alexandrovich@paragon-software.com \
    --cc=david.laight.linux@gmail.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.