[PATCH AUTOSEL 6.18-6.6] fs/ntfs3: fix KMSAN uninit-value in ni_create_attr_list

[Sasha Levin <sashal@kernel.org>]

From: Nirbhay Sharma <nirbhay.lkd@gmail.com>

[ Upstream commit 5f33da04e6ceee849e76e6592cc283c72fef7af9 ]

The call to kmalloc() to allocate the attribute list buffer is given a
size of al_aligned(rs). This size can be larger than the data
subsequently copied into the buffer, leaving trailing bytes uninitialized.

This can trigger a KMSAN "uninit-value" warning if that memory is
later accessed.

Fix this by using kzalloc() instead, which ensures the entire
allocated buffer is zero-initialized, preventing the warning.

Reported-by: syzbot+83c9dd5c0dcf6184fdbf@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=83c9dd5c0dcf6184fdbf
Signed-off-by: Nirbhay Sharma <nirbhay.lkd@gmail.com>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have a complete understanding. Let me summarize my analysis:

---

## Detailed Analysis

### 1. COMMIT MESSAGE ANALYSIS

**Subject**: `fs/ntfs3: fix KMSAN uninit-value in ni_create_attr_list`

**Keywords identified**:
- "fix" - clearly a bug fix
- "KMSAN uninit-value" - refers to Kernel Memory Sanitizer detecting
  uninitialized memory access

**Tags present**:
- `Reported-by: syzbot+83c9dd5c0dcf6184fdbf@syzkaller.appspotmail.com` -
  bug was found by automated fuzzer syzkaller
- `Closes: https://syzkaller.appspot.com/bug?extid=83c9dd5c0dcf6184fdbf`
  - links to original bug report
- `Signed-off-by`: Two sign-offs from the author and ntfs3 maintainer

**Missing tags**:
- No `Cc: stable@vger.kernel.org` tag (though this doesn't preclude
  backporting)
- No `Fixes:` tag pointing to the original buggy commit

### 2. CODE CHANGE ANALYSIS

**The Bug**: In `ni_create_attr_list()` at line 770:

```c
le = kmalloc(al_aligned(rs), GFP_NOFS);
```

**Problem mechanism**:
1. `al_aligned(rs)` rounds up `rs` (record_size, typically 1024 or 4096
   bytes) to the nearest 1024-byte boundary: `(size + 1023) & ~1023`
2. The allocated buffer can be larger than the actual data populated
   into it
3. The loop copies attribute list entries into the buffer, and the
   actual used size is computed as `lsize = PtrOffset(ni->attr_list.le,
   le)`
4. The trailing bytes between `lsize` and `al_aligned(rs)` remain
   uninitialized
5. KMSAN detects when these uninitialized bytes are later accessed (even
   for comparison checks)

**The Fix**:
```c
le = kzalloc(al_aligned(rs), GFP_NOFS);
```

This changes to `kzalloc()` which zero-initializes the entire buffer,
eliminating any uninitialized memory concerns.

**Why it works**: Zero-initialization ensures all bytes in the allocated
buffer have known values, preventing KMSAN warnings even if the unused
trailing bytes are accessed during boundary checks or other operations.

### 3. CLASSIFICATION

- **Bug fix**: Yes, this fixes a real bug (KMSAN uninit-value warning)
- **Device ID/quirk**: No
- **Build fix**: No
- **Security**: Not directly a security vulnerability, but uninitialized
  memory issues can sometimes have security implications (information
  disclosure)

### 4. SCOPE AND RISK ASSESSMENT

**Lines changed**: 1 line
**Files touched**: 1 file (`fs/ntfs3/frecord.c`)
**Complexity**: Minimal - simple `kmalloc` → `kzalloc` change

**Subsystem**: NTFS3 filesystem driver
- This is a relatively mature filesystem driver (introduced in v5.15)
- Used for reading/writing NTFS-formatted storage devices

**Risk assessment**: **VERY LOW**
- The change only adds initialization, cannot introduce new bugs
- `kzalloc()` is a standard, well-tested kernel API
- Zero-initialization is always safe - at worst it's slightly slower
  (negligible for this use case)
- No functional changes to the logic

### 5. USER IMPACT

**Who is affected**:
- Any user mounting NTFS filesystems
- Operations that create attribute lists (complex NTFS files with many
  attributes)

**Severity of original bug**:
- KMSAN warnings indicate potential undefined behavior
- While this may not cause crashes in production (KMSAN is typically
  only enabled in test builds), it indicates a code quality issue
- Could potentially cause intermittent data corruption if the
  uninitialized data is ever written to disk (though the code appears to
  bound writes by `attr_list.size`)

**Likelihood**:
- Medium - attribute list creation is a common operation in NTFS
- The bug was found by syzkaller fuzzing, indicating it's triggerable

### 6. STABILITY INDICATORS

- **Reported-by**: syzkaller (automated fuzzer with good track record)
- **Maintainer Sign-off**: Yes, signed off by Konstantin Komarov (NTFS3
  maintainer)
- Commit has been in mainline since v6.18-rc1

### 7. DEPENDENCY CHECK

- **Dependencies**: None - this is a self-contained one-line fix
- **Code exists in stable trees**: Yes, `ni_create_attr_list()` and the
  `kmalloc()` call exist in all stable kernels since v5.15 (when ntfs3
  was introduced)
- **Clean backport**: Should apply cleanly to any kernel 5.15+

### Summary

This commit is an excellent candidate for stable backporting because:

1. **Fixes a real bug**: KMSAN uninit-value warning triggered by
   syzkaller
2. **Minimal and surgical**: Single-line change from `kmalloc` to
   `kzalloc`
3. **Obviously correct**: Zero-initialization is always safe
4. **Zero risk**: Cannot introduce regressions - only adds
   initialization
5. **Reported by automated testing**: syzkaller found this, indicating
   it's triggerable
6. **Maintainer approved**: Signed off by ntfs3 maintainer
7. **Applicable to all stable trees**: The buggy code exists since ntfs3
   was introduced in v5.15
8. **No dependencies**: Completely self-contained fix

The only minor concern is the lack of an explicit `Cc: stable` tag and
`Fixes:` tag, but this is not a hard requirement. The commit clearly
fixes a bug in filesystem code that affects users mounting NTFS drives.

**YES**

 fs/ntfs3/frecord.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ntfs3/frecord.c b/fs/ntfs3/frecord.c
index 8f9fe1d7a6908..4fe8da7fc0343 100644
--- a/fs/ntfs3/frecord.c
+++ b/fs/ntfs3/frecord.c
@@ -767,7 +767,7 @@ int ni_create_attr_list(struct ntfs_inode *ni)
 	 * Skip estimating exact memory requirement.
 	 * Looks like one record_size is always enough.
 	 */
-	le = kmalloc(al_aligned(rs), GFP_NOFS);
+	le = kzalloc(al_aligned(rs), GFP_NOFS);
 	if (!le)
 		return -ENOMEM;
 
-- 
2.51.0