[PATCH 0/2] ntfs3: fix OOB read and integer overflow in run_unpack()

[PATCH 0/2] ntfs3: fix OOB read and integer overflow in run_unpack()

[tobgaertner]

From: Tobias Gaertner <tob.gaertner@me.com>

Two bugs in run_unpack() found by fuzzing with a source-patched harness
(LibAFL + QEMU ARM64 system-mode):

Patch 1: run_unpack() checks `run_buf < run_last` at the loop top but
then reads size_size and offset_size bytes via run_unpack_s64() without
verifying they fit in the remaining buffer.  A crafted NTFS image with
truncated run data triggers a heap OOB read of up to 15 bytes on mount.

Patch 2: The volume boundary check `lcn + len > sbi->used.bitmap.nbits`
uses raw addition that can wrap for large values, bypassing the
validation.  CVE-2025-40068 added check_add_overflow() for adjacent
arithmetic but missed this instance.

Both bugs are present since NTFS3 was merged in 5.15.

Could CVE IDs be assigned for these two issues?

tobgaertner (2):
  ntfs3: add buffer boundary checks to run_unpack()
  ntfs3: fix integer overflow in run_unpack() volume boundary check

 fs/ntfs3/run.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

-- 
2.43.0

[PATCH 1/2] ntfs3: add buffer boundary checks to run_unpack()

[tobgaertner]

From: Tobias Gaertner <tob.gaertner@me.com>

run_unpack() checks `run_buf < run_last` at the top of the while loop
but then reads size_size and offset_size bytes via run_unpack_s64()
without verifying they fit within the remaining buffer.  A crafted NTFS
image with truncated run data in an MFT attribute triggers an OOB heap
read of up to 15 bytes when the filesystem is mounted.

Add boundary checks before each run_unpack_s64() call to ensure the
declared field size does not exceed the remaining buffer.

Found by fuzzing with a source-patched harness (LibAFL + QEMU).

Fixes: 82cae269cfa95 ("fs/ntfs3: Add initialization of super block")
Cc: stable@vger.kernel.org
Signed-off-by: Tobias Gaertner <tob.gaertner@me.com>
---
 fs/ntfs3/run.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/fs/ntfs3/run.c b/fs/ntfs3/run.c
index 395b20492..c3c6917fa 100644
--- a/fs/ntfs3/run.c
+++ b/fs/ntfs3/run.c
@@ -970,6 +970,9 @@ int run_unpack(struct runs_tree *run, struct ntfs_sb_info *sbi, CLST ino,
 		if (size_size > sizeof(len))
 			return -EINVAL;
 
+		if (run_buf + size_size > run_last)
+			return -EINVAL;
+
 		len = run_unpack_s64(run_buf, size_size, 0);
 		/* Skip size_size. */
 		run_buf += size_size;
@@ -982,6 +985,9 @@ int run_unpack(struct runs_tree *run, struct ntfs_sb_info *sbi, CLST ino,
 		else if (offset_size <= sizeof(s64)) {
 			s64 dlcn;
 
+			if (run_buf + offset_size > run_last)
+				return -EINVAL;
+
 			/* Initial value of dlcn is -1 or 0. */
 			dlcn = (run_buf[offset_size - 1] & 0x80) ? (s64)-1 : 0;
 			dlcn = run_unpack_s64(run_buf, offset_size, dlcn);
-- 
2.43.0

[PATCH 2/2] ntfs3: fix integer overflow in run_unpack() volume boundary check

[tobgaertner]

From: Tobias Gaertner <tob.gaertner@me.com>

The volume boundary check `lcn + len > sbi->used.bitmap.nbits` uses raw
addition which can wrap around for large lcn and len values, bypassing
the validation.  Use check_add_overflow() as is already done for the
adjacent prev_lcn + dlcn and vcn64 + len checks added by commit
3ac37e100385 ("ntfs3: Fix integer overflow in run_unpack()").

Found by fuzzing with a source-patched harness (LibAFL + QEMU).

Fixes: 82cae269cfa95 ("fs/ntfs3: Add initialization of super block")
Cc: stable@vger.kernel.org
Signed-off-by: Tobias Gaertner <tob.gaertner@me.com>
---
 fs/ntfs3/run.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/fs/ntfs3/run.c b/fs/ntfs3/run.c
index c3c6917fa..a68000bd4 100644
--- a/fs/ntfs3/run.c
+++ b/fs/ntfs3/run.c
@@ -1027,9 +1027,15 @@ int run_unpack(struct runs_tree *run, struct ntfs_sb_info *sbi, CLST ino,
 			return -EOPNOTSUPP;
 		}
 #endif
-		if (lcn != SPARSE_LCN64 && lcn + len > sbi->used.bitmap.nbits) {
-			/* LCN range is out of volume. */
-			return -EINVAL;
+		if (lcn != SPARSE_LCN64) {
+			u64 lcn_end;
+
+			if (check_add_overflow(lcn, len, &lcn_end))
+				return -EINVAL;
+			if (lcn_end > sbi->used.bitmap.nbits) {
+				/* LCN range is out of volume. */
+				return -EINVAL;
+			}
 		}
 
 		if (!run)
-- 
2.43.0

Re: [PATCH 0/2] ntfs3: fix OOB read and integer overflow in run_unpack()

[Konstantin Komarov]

On 3/29/26 13:17, tobgaertner wrote:

> [You don't often get email from tob.gaertner@me.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> From: Tobias Gaertner <tob.gaertner@me.com>
>
> Two bugs in run_unpack() found by fuzzing with a source-patched harness
> (LibAFL + QEMU ARM64 system-mode):
>
> Patch 1: run_unpack() checks `run_buf < run_last` at the loop top but
> then reads size_size and offset_size bytes via run_unpack_s64() without
> verifying they fit in the remaining buffer.  A crafted NTFS image with
> truncated run data triggers a heap OOB read of up to 15 bytes on mount.
>
> Patch 2: The volume boundary check `lcn + len > sbi->used.bitmap.nbits`
> uses raw addition that can wrap for large values, bypassing the
> validation.  CVE-2025-40068 added check_add_overflow() for adjacent
> arithmetic but missed this instance.
>
> Both bugs are present since NTFS3 was merged in 5.15.
>
> Could CVE IDs be assigned for these two issues?
>
> tobgaertner (2):
>    ntfs3: add buffer boundary checks to run_unpack()
>    ntfs3: fix integer overflow in run_unpack() volume boundary check
>
>   fs/ntfs3/run.c | 18 +++++++++++++++---
>   1 file changed, 15 insertions(+), 3 deletions(-)
>
> --
> 2.43.0
>
Hello,

Patches are queued for the next merge window, thanks.

Regards,
Konstantin

Re: [PATCH 0/2] ntfs3: fix OOB read and integer overflow in run_unpack()

[Tobias Gaertner]

Hi Konstantin,

Great news! 

Will I get a CVE for that memory leak? 

Can you credit the patch and CVE to “Tiefgang Security Labs”? 

info@tiefgangsecuritylabs.com

Cheers,

Tobias


> On Apr 7, 2026, at 10:19, Konstantin Komarov <almaz.alexandrovich@paragon-software.com> wrote:
> 
> On 3/29/26 13:17, tobgaertner wrote:
> 
>> [You don't often get email from tob.gaertner@me.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>> 
>> From: Tobias Gaertner <tob.gaertner@me.com>
>> 
>> Two bugs in run_unpack() found by fuzzing with a source-patched harness
>> (LibAFL + QEMU ARM64 system-mode):
>> 
>> Patch 1: run_unpack() checks `run_buf < run_last` at the loop top but
>> then reads size_size and offset_size bytes via run_unpack_s64() without
>> verifying they fit in the remaining buffer.  A crafted NTFS image with
>> truncated run data triggers a heap OOB read of up to 15 bytes on mount.
>> 
>> Patch 2: The volume boundary check `lcn + len > sbi->used.bitmap.nbits`
>> uses raw addition that can wrap for large values, bypassing the
>> validation.  CVE-2025-40068 added check_add_overflow() for adjacent
>> arithmetic but missed this instance.
>> 
>> Both bugs are present since NTFS3 was merged in 5.15.
>> 
>> Could CVE IDs be assigned for these two issues?
>> 
>> tobgaertner (2):
>>   ntfs3: add buffer boundary checks to run_unpack()
>>   ntfs3: fix integer overflow in run_unpack() volume boundary check
>> 
>>  fs/ntfs3/run.c | 18 +++++++++++++++---
>>  1 file changed, 15 insertions(+), 3 deletions(-)
>> 
>> --
>> 2.43.0
>> 
> Hello,
> 
> Patches are queued for the next merge window, thanks.
> 
> Regards,
> Konstantin
> 

Re: [PATCH 0/2] ntfs3: fix OOB read and integer overflow in run_unpack()

[Willy Tarreau]

Hi,

On Tue, Apr 14, 2026 at 09:19:15PM -0700, Tobias Gaertner wrote:
> Hi Konstantin,
> 
> Great news! 
> 
> Will I get a CVE for that memory leak? 

CVEs are assigned by the CVE team once the patches are backported to
stable, according to the process described here:

   Documentation/process/cve.rst

regards,
Willy