kernel/linux.git/fs/ntfs3, branch v5.15.208

fs/ntfs3: avoid calling run_get_entry() when run == NULL in ntfs_read_run_nb_ra()

2026-03-04T12:20:18+00:00

[ Upstream commit c5226b96c08a010ebef5fdf4c90572bcd89e4299 ] When ntfs_read_run_nb_ra() is invoked with run == NULL the code later assumes run is valid and may call run_get_entry(NULL, ...), and also uses clen/idx without initializing them. Smatch reported uninitialized variable warnings and this can lead to undefined behaviour. This patch fixes it. Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202512230646.v5hrYXL0-lkp@intel.com/ Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin

fs: ntfs3: fix infinite loop triggered by zero-sized ATTR_LIST

2026-03-04T12:20:18+00:00

[ Upstream commit 06909b2549d631a47fcda249d34be26f7ca1711d ] We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed NTFS image can cause an infinite loop when an ATTR_LIST attribute indicates a zero data size while the driver allocates memory for it. When ntfs_load_attr_list() processes a resident ATTR_LIST with data_size set to zero, it still allocates memory because of al_aligned(0). This creates an inconsistent state where ni->attr_list.size is zero, but ni->attr_list.le is non-null. This causes ni_enum_attr_ex to incorrectly assume that no attribute list exists and enumerates only the primary MFT record. When it finds ATTR_LIST, the code reloads it and restarts the enumeration, repeating indefinitely. The mount operation never completes, hanging the kernel thread. This patch adds validation to ensure that data_size is non-zero before memory allocation. When a zero-sized ATTR_LIST is detected, the function returns -EINVAL, preventing a DoS vulnerability. Co-developed-by: Seunghun Han Signed-off-by: Seunghun Han Co-developed-by: Jihoon Kwon Signed-off-by: Jihoon Kwon Signed-off-by: Jaehun Gou Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin

fs: ntfs3: fix infinite loop in attr_load_runs_range on inconsistent metadata

2026-03-04T12:20:18+00:00

[ Upstream commit 4b90f16e4bb5607fb35e7802eb67874038da4640 ] We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed NTFS image can cause an infinite loop when an attribute header indicates an empty run list, while directory entries reference it as containing actual data. In NTFS, setting evcn=-1 with svcn=0 is a valid way to represent an empty run list, and run_unpack() correctly handles this by checking if evcn + 1 equals svcn and returning early without parsing any run data. However, this creates a problem when there is metadata inconsistency, where the attribute header claims to be empty (evcn=-1) but the caller expects to read actual data. When run_unpack() immediately returns success upon seeing this condition, it leaves the runs_tree uninitialized with run->runs as a NULL. The calling function attr_load_runs_range() assumes that a successful return means that the runs were loaded and sets clen to 0, expecting the next run_lookup_entry() call to succeed. Because runs_tree remains uninitialized, run_lookup_entry() continues to fail, and the loop increments vcn by zero (vcn += 0), leading to an infinite loop. This patch adds a retry counter to detect when run_lookup_entry() fails consecutively after attr_load_runs_vcn(). If the run is still not found on the second attempt, it indicates corrupted metadata and returns -EINVAL, preventing the Denial-of-Service (DoS) vulnerability. Co-developed-by: Seunghun Han Signed-off-by: Seunghun Han Co-developed-by: Jihoon Kwon Signed-off-by: Jihoon Kwon Signed-off-by: Jaehun Gou Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin

fs: ntfs3: check return value of indx_find to avoid infinite loop

2026-03-04T12:20:18+00:00

[ Upstream commit 1732053c8a6b360e2d5afb1b34fe9779398b072c ] We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed dentry in the ntfs3 filesystem can cause the kernel to hang during the lookup operations. By setting the HAS_SUB_NODE flag in an INDEX_ENTRY within a directory's INDEX_ALLOCATION block and manipulating the VCN pointer, an attacker can cause the indx_find() function to repeatedly read the same block, allocating 4 KB of memory each time. The kernel lacks VCN loop detection and depth limits, causing memory exhaustion and an OOM crash. This patch adds a return value check for fnd_push() to prevent a memory exhaustion vulnerability caused by infinite loops. When the index exceeds the size of the fnd->nodes array, fnd_push() returns -EINVAL. The indx_find() function checks this return value and stops processing, preventing further memory allocation. Co-developed-by: Seunghun Han Signed-off-by: Seunghun Han Co-developed-by: Jihoon Kwon Signed-off-by: Jihoon Kwon Signed-off-by: Jaehun Gou Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin

fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot

2026-03-04T12:19:49+00:00

[ Upstream commit b2bc7c44ed1779fc9eaab9a186db0f0d01439622 ] In the 'DeleteIndexEntryRoot' case of the 'do_action' function, the entry size ('esize') is retrieved from the log record without adequate bounds checking. Specifically, the code calculates the end of the entry ('e2') using: e2 = Add2Ptr(e1, esize); It then calculates the size for memmove using 'PtrOffset(e2, ...)', which subtracts the end pointer from the buffer limit. If 'esize' is maliciously large, 'e2' exceeds the used buffer size. This results in a negative offset which, when cast to size_t for memmove, interprets as a massive unsigned integer, leading to a heap buffer overflow. This commit adds a check to ensure that the entry size ('esize') strictly fits within the remaining used space of the index header before performing memory operations. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Signed-off-by: Jiasheng Jiang Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin

fs/ntfs3: prevent infinite loops caused by the next valid being the same

2026-03-04T12:19:49+00:00

[ Upstream commit 27b75ca4e51e3e4554dc85dbf1a0246c66106fd3 ] When processing valid within the range [valid : pos), if valid cannot be retrieved correctly, for example, if the retrieved valid value is always the same, this can trigger a potential infinite loop, similar to the hung problem reported by syzbot [1]. Adding a check for the valid value within the loop body, and terminating the loop and returning -EINVAL if the value is the same as the current value, can prevent this. [1] INFO: task syz.4.21:6056 blocked for more than 143 seconds. Call Trace: rwbase_write_lock+0x14f/0x750 kernel/locking/rwbase_rt.c:244 inode_lock include/linux/fs.h:1027 [inline] ntfs_file_write_iter+0xe6/0x870 fs/ntfs3/file.c:1284 Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation") Reported-by: syzbot+bcf9e1868c1a0c7e04f1@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=bcf9e1868c1a0c7e04f1 Signed-off-by: Edward Adam Davis Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin

fs/ntfs3: Initialize allocated memory before use

2026-02-06T15:42:03+00:00

[ Upstream commit a8a3ca23bbd9d849308a7921a049330dc6c91398 ] KMSAN reports: Multiple uninitialized values detected: - KMSAN: uninit-value in ntfs_read_hdr (3) - KMSAN: uninit-value in bcmp (3) Memory is allocated by __getname(), which is a wrapper for kmem_cache_alloc(). This memory is used before being properly cleared. Change kmem_cache_alloc() to kmem_cache_zalloc() to properly allocate and clear memory before use. Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block") Fixes: 78ab59fee07f ("fs/ntfs3: Rework file operations") Tested-by: syzbot+332bd4e9d148f11a87dc@syzkaller.appspotmail.com Reported-by: syzbot+332bd4e9d148f11a87dc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=332bd4e9d148f11a87dc Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block") Fixes: 78ab59fee07f ("fs/ntfs3: Rework file operations") Tested-by: syzbot+0399100e525dd9696764@syzkaller.appspotmail.com Reported-by: syzbot+0399100e525dd9696764@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0399100e525dd9696764 Reviewed-by: Khalid Aziz Signed-off-by: Bartlomiej Kubik Signed-off-by: Konstantin Komarov Signed-off-by: Li hongliang <1468888505@139.com> Signed-off-by: Greg Kroah-Hartman

fs/ntfs3: fix mount failure for sparse runs in run_unpack()

2026-01-19T12:09:49+00:00

commit 801f614ba263cb37624982b27b4c82f3c3c597a9 upstream. Some NTFS volumes failed to mount because sparse data runs were not handled correctly during runlist unpacking. The code performed arithmetic on the special SPARSE_LCN64 marker, leading to invalid LCN values and mount errors. Add an explicit check for the case described above, marking the run as sparse without applying arithmetic. Fixes: 736fc7bf5f68 ("fs: ntfs3: Fix integer overflow in run_unpack()") Cc: stable@vger.kernel.org Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman

fs/ntfs3: Support timestamps prior to epoch

2026-01-19T12:09:42+00:00

[ Upstream commit 5180138604323895b5c291eca6aa7c20be494ade ] Before it used an unsigned 64-bit type, which prevented proper handling of timestamps earlier than 1970-01-01. Switch to a signed 64-bit type to support pre-epoch timestamps. The issue was caught by xfstests. Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin

fs/ntfs3: Prevent memory leaks in add sub record

2026-01-19T12:09:31+00:00

[ Upstream commit ccc4e86d1c24260c18ae94541198c3711c140da6 ] If a rb node with the same ino already exists in the rb tree, the newly alloced mft_inode in ni_add_subrecord() will not have its memory cleaned up, which leads to the memory leak issue reported by syzbot. The best option to avoid this issue is to put the newly alloced mft node when a rb node with the same ino already exists in the rb tree and return the rb node found in the rb tree to the parent layer. syzbot reported: BUG: memory leak unreferenced object 0xffff888110bef280 (size 128): backtrace (crc 126a088f): ni_add_subrecord+0x31/0x180 fs/ntfs3/frecord.c:317 ntfs_look_free_mft+0xf0/0x790 fs/ntfs3/fsntfs.c:715 BUG: memory leak unreferenced object 0xffff888109093400 (size 1024): backtrace (crc 7197c55e): mi_init+0x2b/0x50 fs/ntfs3/record.c:105 mi_format_new+0x40/0x220 fs/ntfs3/record.c:422 Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation") Reported-by: syzbot+3932ccb896e06f7414c9@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin