mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Joas Antonio dos Santos via B4 Relay <devnull+joasantonio108.gmail.com@kernel.org>
To: joasantonio108@gmail.com,
	 Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH] ntfs3: fix bitmap corruption in attr_allocate_clusters() error path
Date: Sun, 08 Nov 2026 18:05:33 +0000	[thread overview]
Message-ID: <20261108-ntfs3-alloc-undo-fix-v1-1-280fc5d06af6@gmail.com> (raw)

From: Joas Antonio dos Santos <joasantonio108@gmail.com>

The undo_alloc error path in attr_allocate_clusters() calls
mark_as_free_ex() with len (remaining clusters to allocate) instead
of flen (clusters actually allocated in the last iteration).

After the first loop iteration, len is decremented by flen, so on
subsequent iterations len represents only the remaining request size.
When run_add_entry() or run_remove_range() fails, the undo frees len
clusters starting at lcn, but only flen clusters at that position
were actually allocated. The excess clusters may belong to other files,
corrupting the allocation bitmap and causing silent data loss.

For example: a 100-cluster request where the first iteration allocates
60 (len becomes 40), and the second allocates 20 at a new lcn. If
run_add_entry() fails, undo frees 40 clusters at lcn when only 20 were
allocated there, marking 20 clusters of other files as free.

Fix by passing flen instead of len to mark_as_free_ex().

Found by LLM-assisted manual code review.

Fixes: be71b5cba2e6 ("fs/ntfs3: Add attrib operations")
Signed-off-by: Joas Antonio dos Santos <joasantonio108@gmail.com>
---
 fs/ntfs3/attrib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ntfs3/attrib.c b/fs/ntfs3/attrib.c
index 805acc3ed..2a75ee162 100644
--- a/fs/ntfs3/attrib.c
+++ b/fs/ntfs3/attrib.c
@@ -207,7 +207,7 @@ int attr_allocate_clusters(struct ntfs_sb_info *sbi, struct runs_tree *run,
 		if (!run_add_entry(run, vcn, lcn, flen, opt & ALLOCATE_MFT)) {
 undo_alloc:
 			/* Undo last 'ntfs_look_for_free_space' */
-			mark_as_free_ex(sbi, lcn, len, false);
+			mark_as_free_ex(sbi, lcn, flen, false);
 			err = -ENOMEM;
 			goto out;
 		}

---
base-commit: 05441d697f7f9a927264f4058cbbc6a03dfcac9d
change-id: 20261108-ntfs3-alloc-undo-fix-e64b8b0f8ea5

Best regards,
-- 
Joas Antonio dos Santos <joasantonio108@gmail.com>



                 reply	other threads:[~2026-11-08 18:05 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20261108-ntfs3-alloc-undo-fix-v1-1-280fc5d06af6@gmail.com \
    --to=devnull+joasantonio108.gmail.com@kernel.org \
    --cc=almaz.alexandrovich@paragon-software.com \
    --cc=joasantonio108@gmail.com \
    --cc=linux-kernel@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

all inboxes | Powered by JetHome®