From: David Laight <david.laight.linux@gmail.com>
To: Zhan Xusheng <zhanxusheng1024@gmail.com>
Cc: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>,
linux-kernel@vger.kernel.org,
Zhan Xusheng <zhanxusheng@xiaomi.com>
Subject: Re: [PATCH] fs/ntfs3: reject evcn == U64_MAX in mi_enum_attr()
Date: Fri, 24 Apr 2026 10:20:24 +0100 [thread overview]
Message-ID: <20260424102024.74d20552@pumpkin> (raw)
In-Reply-To: <20260424024619.285630-1-zhanxusheng@xiaomi.com>
On Fri, 24 Apr 2026 10:46:19 +0800
Zhan Xusheng <zhanxusheng1024@gmail.com> wrote:
> In mi_enum_attr(), the start/end VCN validation for non-resident
> attributes is:
>
> if (svcn > evcn + 1) goto out;
>
> When on-disk evcn is 0xFFFFFFFFFFFFFFFF (U64_MAX), the addition
> evcn + 1 wraps to 0, and the check becomes "if (svcn > 0)" which
> incorrectly accepts svcn == 0 with evcn == U64_MAX.
>
> mi_enum_attr() is the core attribute iterator used throughout ntfs3.
> Allowing this malformed VCN range to pass the initial validation can
> feed a bogus 64-bit extent span into downstream code that computes
> evcn + 1 - svcn (producing 0 due to wrap) or uses evcn as a loop
> bound.
>
> A crafted NTFS image can trigger this on mount or file access.
>
> Fix by explicitly rejecting evcn == U64_MAX before the addition.
>
> Fixes: 013ff63b6494 ("fs/ntfs3: Add more attributes checks in mi_enum_attr()")
> Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
> ---
> fs/ntfs3/record.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ntfs3/record.c b/fs/ntfs3/record.c
> index 32bdb034c2a3..2ff28bfbedad 100644
> --- a/fs/ntfs3/record.c
> +++ b/fs/ntfs3/record.c
> @@ -311,7 +311,8 @@ struct ATTRIB *mi_enum_attr(struct ntfs_inode *ni, struct mft_inode *mi,
> goto out;
>
> /* Check start/end vcn. */
> - if (le64_to_cpu(attr->nres.svcn) > le64_to_cpu(attr->nres.evcn) + 1)
> + if (le64_to_cpu(attr->nres.evcn) == (u64)-1 ||
> + le64_to_cpu(attr->nres.svcn) > le64_to_cpu(attr->nres.evcn) + 1)
Isn't that just:
if (le64_to_cpu(attr->nres.svcn) >= le64_to_cpu(attr->nres.evcn))
David
> goto out;
>
> data_size = le64_to_cpu(attr->nres.data_size);
next prev parent reply other threads:[~2026-04-24 9:20 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 [this message]
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
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=20260424102024.74d20552@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=almaz.alexandrovich@paragon-software.com \
--cc=linux-kernel@vger.kernel.org \
--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.