From: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
To: Michael Bommarito <michael.bommarito@gmail.com>
Cc: <ntfs3@lists.linux.dev>, <linux-fsdevel@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <stable@vger.kernel.org>
Subject: Re: [PATCH] ntfs3: validate split-point offset in indx_insert_into_buffer
Date: Thu, 30 Apr 2026 13:58:53 +0200 [thread overview]
Message-ID: <3b76b31d-ebd4-4c83-b100-481b89960a00@paragon-software.com> (raw)
In-Reply-To: <20260417225712.1736320-1-michael.bommarito@gmail.com>
On 4/18/26 00:57, Michael Bommarito wrote:
> [You don't often get email from michael.bommarito@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> indx_insert_into_buffer() computes
>
> used = used1 - to_copy - sp_size;
> memmove(de_t, Add2Ptr(sp, sp_size), used - le32_to_cpu(hdr1->de_off));
>
> where sp and sp_size come from hdr_find_split(). hdr_find_split()
> walks entries by le16_to_cpu(e->size) without validating that each
> step stays within hdr->used or that the size field is at least
> sizeof(struct NTFS_DE). index_hdr_check(), the on-load gatekeeper,
> only validates header-level fields (used, total, de_off) and does
> not walk per-entry sizes.
>
> A crafted NTFS image whose leaf INDEX_HDR reports used == total but
> contains one interior NTFS_DE with size = 0xFFF0 therefore passes
> validation, descends to indx_insert_into_buffer() through the
> ntfs_create() -> indx_insert_entry() path, and makes hdr_find_split()
> return an sp whose sp_size (0xFFF0) greatly exceeds the remaining
> bytes in the buffer. The u32 subtraction underflows and the memmove
> count becomes a near-4-GiB value, producing an out-of-bounds kernel
> write that corrupts adjacent allocations and panics the kernel.
>
> Reproduced on 7.0.0-rc7 with UML + KASAN via a crafted image and a
> single 'touch' inside the mounted directory; crash site resolves to
> fs/ntfs3/index.c at the memmove. Trigger requires only local mount
> of an attacker-supplied filesystem image (USB, loopback, or removable
> media auto-mount).
>
> Reject the split whenever the chosen sp plus its declared size
> already extends past hdr1->used. This is the minimal fix; it
> preserves the existing hdr_find_split() contract and relies on the
> same out: cleanup path as the pre-existing error returns.
>
> A prior OOB read in the very same indx_insert_into_buffer() memmove
> was fixed in commit b8c44949044e ("fs/ntfs3: Fix OOB read in
> indx_insert_into_buffer") by tightening hdr_find_e(), but that fix
> does not cover the split-point size field path addressed here: sp is
> returned by hdr_find_split(), not hdr_find_e(), and the underflow is
> driven by sp->size rather than hdr->used exceeding hdr->total.
>
> Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block")
> Cc: stable@vger.kernel.org
> Reported-by: Michael Bommarito <michael.bommarito@gmail.com>
> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
> Assisted-by: Claude:claude-opus-4-7
> ---
>
> - FYI, I have a larger refactor variant that migrates
> hdr_find_split() to the validated hdr_next_de() helper and closes
> the whole per-entry size-read class for that walker. Happy to
> send it as v2 if you prefer the wider change; otherwise this
> minimal guard is scoped to the actual memmove underflow site and
> is easier to backport.
>
> fs/ntfs3/index.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/fs/ntfs3/index.c b/fs/ntfs3/index.c
> index 2c43e7c27861..24add048b4b5 100644
> --- a/fs/ntfs3/index.c
> +++ b/fs/ntfs3/index.c
> @@ -1844,6 +1844,20 @@ indx_insert_into_buffer(struct ntfs_index *indx, struct ntfs_inode *ni,
> memcpy(up_e, sp, sp_size);
>
> used1 = le32_to_cpu(hdr1->used);
> +
> + /*
> + * hdr_find_split does not validate per-entry sizes, so a crafted
> + * NTFS_DE whose le16 size field is out of range can place sp such
> + * that (PtrOffset(hdr1, sp) + sp_size) exceeds used1. Without this
> + * guard the u32 'used = used1 - to_copy - sp_size' underflows and
> + * the subsequent memmove count becomes a near-4-GiB value,
> + * triggering an out-of-bounds kernel write.
> + */
> + if (PtrOffset(hdr1, sp) + sp_size > used1) {
> + err = -EINVAL;
> + goto out;
> + }
> +
> hdr1_saved = kmemdup(hdr1, used1, GFP_NOFS);
> if (!hdr1_saved) {
> err = -ENOMEM;
> --
> 2.53.0
>
Hello,
Sorry for the delay.
Patch is applied. Thank you.
Regards,
Konstantin
prev parent reply other threads:[~2026-04-30 11:58 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-17 22:57 [PATCH] ntfs3: validate split-point offset in indx_insert_into_buffer Michael Bommarito
2026-04-30 11:58 ` Konstantin Komarov [this message]
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=3b76b31d-ebd4-4c83-b100-481b89960a00@paragon-software.com \
--to=almaz.alexandrovich@paragon-software.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.bommarito@gmail.com \
--cc=ntfs3@lists.linux.dev \
--cc=stable@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox