[PATCH AUTOSEL 7.0-6.12] exfat: fix s_maxbytes

[PATCH AUTOSEL 7.0-6.12] exfat: fix s_maxbytes

[Sasha Levin]

From: David Timber <dxdt@dev.snart.me>

[ Upstream commit 4129a3a2751cba8511cee5d13145223662a8e019 ]

With fallocate support, xfstest unit generic/213 fails with

   QA output created by 213
   We should get: fallocate: No space left on device
   Strangely, xfs_io sometimes says "Success" when something went wrong
  -fallocate: No space left on device
  +fallocate: File too large

because sb->s_maxbytes is set to the volume size.

To be in line with other non-extent-based filesystems, set to max volume
size possible with the cluster size of the volume.

Signed-off-by: David Timber <dxdt@dev.snart.me>
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The context lines match exactly - the patch would apply cleanly to this
tree. Now let me compile my full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem**: `exfat` (filesystem)
- **Action verb**: "fix" — explicit bug fix
- **Summary**: Corrects the `s_maxbytes` value set for exFAT superblock

### Step 1.2: Tags
- `Signed-off-by: David Timber <dxdt@dev.snart.me>` — author
- `Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>` — exFAT subsystem
  maintainer, who applied the patch
- No Fixes: tag, no Reported-by, no Cc: stable (expected for commits
  under review)
- No Link: tag

Record: Maintainer-signed patch, applied by exFAT maintainer Namjae
Jeon.

### Step 1.3: Commit Body
- Bug: `sb->s_maxbytes` is set to volume size, but should represent the
  maximum file size for the filesystem format
- Symptom: xfstest generic/213 fails returning `EFBIG` ("File too
  large") instead of `ENOSPC` ("No space left on device") when the
  filesystem is full
- Root cause: The VFS layer checks `s_maxbytes` in `vfs_fallocate()`
  (`fs/open.c:333`), `generic_write_check_limits()`, and
  `inode_newsize_ok()`. When `s_maxbytes = volume_data_size`, operations
  near the volume boundary get `EFBIG` from VFS instead of letting the
  filesystem return `ENOSPC`

### Step 1.4: Hidden Bug Fix Detection
This is an explicit fix, not hidden. The commit clearly states "fix
s_maxbytes".

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **fs/exfat/exfat_raw.h**: +1 line (adds `EXFAT_MAX_NUM_CLUSTER`
  constant)
- **fs/exfat/file.c**: +1 line (adds clarifying comment about integer
  overflow)
- **fs/exfat/super.c**: ~3 lines changed (replaces s_maxbytes
  calculation + comment)
- Total: ~5 lines of logic, ~5 lines of comments. Very small and
  surgical.

### Step 2.2: Code Flow Change
1. **exfat_raw.h**: Adds `EXFAT_MAX_NUM_CLUSTER (0xFFFFFFF5)` — the
   exFAT specification maximum cluster count
2. **super.c `exfat_read_boot_sector()`**:
   - Before: `sb->s_maxbytes = (u64)(sbi->num_clusters -
     EXFAT_RESERVED_CLUSTERS) << sbi->cluster_size_bits` — volume data
     size
   - After: `sb->s_maxbytes = min(MAX_LFS_FILESIZE,
     EXFAT_CLU_TO_B((loff_t)EXFAT_MAX_NUM_CLUSTER, sbi))` — format
     maximum clamped to VFS limit
3. **file.c `exfat_cont_expand()`**: Adds comment above
   `EXFAT_B_TO_CLU_ROUND_UP(size, sbi)` noting that `inode_newsize_ok()`
   already checked for integer overflow

### Step 2.3: Bug Mechanism
This is a **logic/correctness fix**: `s_maxbytes` was set to the wrong
value. The VFS uses `s_maxbytes` to represent the maximum file size the
filesystem FORMAT supports, not the volume capacity. Multiple VFS entry
points return `EFBIG` when operations exceed `s_maxbytes`:
- `vfs_fallocate()` at `fs/open.c:333`
- `generic_write_check_limits()` at `fs/read_write.c:1728`
- `inode_newsize_ok()` at `fs/attr.c:264`

Additionally, on 32-bit platforms, the old code did NOT clamp to
`MAX_LFS_FILESIZE`, which could set `s_maxbytes` beyond what the VFS can
handle.

### Step 2.4: Fix Quality
- **Obviously correct**: YES — `0xFFFFFFF5` is the exFAT spec maximum;
  `min(MAX_LFS_FILESIZE, ...)` follows the pattern used by other
  filesystems (JFS, NTFS3, etc.)
- **Minimal**: YES — 3 files, ~5 logic lines
- **Regression risk**: VERY LOW — changes only the superblock
  initialization value; on 64-bit, `s_maxbytes` becomes larger (more
  permissive), which is correct VFS behavior

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
The buggy code was introduced in commit `719c1e182916` ("exfat: add
super block operations") by Namjae Jeon on 2020-03-02, when exfat was
first added to the kernel (v5.7). This means the bug has been present
since exfat's inception and affects ALL stable trees that include exfat.

### Step 3.2: Fixes Tag
No Fixes: tag present. The implicit target is `719c1e182916` (exfat
initial addition).

### Step 3.3: File History
Recent exfat super.c changes are mostly optimizations and unrelated
fixes. No conflicting changes to the `s_maxbytes` line.

### Step 3.4: Author
David Timber is a contributor to exfat. The patch was reviewed and
applied by Namjae Jeon, the exFAT subsystem maintainer.

### Step 3.5: Dependencies
The patch is **standalone** — it only uses existing macros
(`EXFAT_CLU_TO_B`, `MAX_LFS_FILESIZE`) and adds a new constant. It does
NOT depend on the fallocate support patch.

---

## PHASE 4: MAILING LIST RESEARCH

### Step 4.1: Patch Discussion
Found the related fallocate patch at `https://yhbt.net/lore/linux-
fsdevel/20260228084542.485615-1-dxdt@dev.snart.me/T/`. The s_maxbytes
fix was discovered during fallocate testing but is a separate,
standalone correction. Namjae Jeon applied the fallocate patch to the
exfat #dev branch on 2026-03-04.

### Step 4.2: Reviewers
Namjae Jeon (exFAT maintainer) signed off on the patch, indicating
review and approval.

### Step 4.3-4.5: Bug Report / Related Patches / Stable Discussion
The bug was discovered via xfstest generic/213 failure. No explicit
stable nomination found, which is expected for commits under review.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1-5.4: Functions and Call Chains
The key function is `exfat_read_boot_sector()` which sets `s_maxbytes`
during mount. The value is then used by:
- `inode_newsize_ok()` — called from `exfat_cont_expand()`
  (truncate/setattr path)
- `generic_write_check_limits()` — called from `generic_write_checks()`
  (write path)
- `vfs_fallocate()` — VFS fallocate entry (if fallocate is supported)

These are all common I/O paths that any exfat user would hit.

### Step 5.5: Similar Patterns
Other non-extent-based filesystems set `s_maxbytes` to the format
maximum:
- FAT: `sb->s_maxbytes = 0xffffffff` (4GB format limit)
- NTFS3: `sb->s_maxbytes = MAX_LFS_FILESIZE`
- JFS: `sb->s_maxbytes = min(((loff_t)sb->s_blocksize) << 40,
  MAX_LFS_FILESIZE)`

exFAT was the outlier using volume size instead of format maximum.

---

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Buggy Code in Stable
The buggy code exists in ALL stable trees that include exfat (v5.7+).
The exfat `s_maxbytes` initialization has never been changed since the
initial commit in 2020.

### Step 6.2: Backport Complications
The patch context matches the current 7.0 tree exactly. Clean
application expected.

### Step 6.3: Related Fixes
No other fix for this specific issue exists in any stable tree.

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem Criticality
- **Subsystem**: fs/exfat — filesystem driver
- **Criticality**: IMPORTANT — exFAT is widely used for USB drives, SD
  cards, and cross-platform storage

### Step 7.2: Activity
Active subsystem with regular maintenance by Namjae Jeon.

---

## PHASE 8: IMPACT AND RISK

### Step 8.1: Affected Users
All exfat users who perform write/truncate operations on files near the
volume's data capacity boundary.

### Step 8.2: Trigger Conditions
- Volume nearly full, file operations that would exceed volume capacity
- On 32-bit platforms: any large exfat volume could have incorrect
  `s_maxbytes`
- Unprivileged users can trigger this via normal file operations

### Step 8.3: Failure Mode
- **Wrong error code** (EFBIG instead of ENOSPC) — MEDIUM severity
- **32-bit platform issue**: `s_maxbytes` not clamped to
  `MAX_LFS_FILESIZE` — potentially more serious, could cause VFS-level
  issues

### Step 8.4: Risk-Benefit
- **Benefit**: MEDIUM — corrects wrong errno for all exfat users, fixes
  32-bit clamping, aligns with VFS conventions
- **Risk**: VERY LOW — tiny change, only modifies initialization value,
  follows established pattern from other filesystems
- **Ratio**: Favorable for backport

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence
**FOR backporting:**
- Real correctness bug: wrong errno returned to userspace (EFBIG vs
  ENOSPC)
- Missing `MAX_LFS_FILESIZE` clamping on 32-bit platforms
- Bug present since exfat inception (v5.7, 2020)
- Very small fix: ~5 logic lines across 3 files
- Obviously correct: follows exFAT specification and VFS conventions
  used by all other filesystems
- Applied by subsystem maintainer Namjae Jeon
- Standalone: no dependencies on other patches
- Clean apply expected

**AGAINST backporting:**
- Severity is LOW-MEDIUM (wrong error code, not a
  crash/corruption/security issue)
- The xfstest failure mentioned requires fallocate support (not in
  current stable)
- But the underlying bug still affects writes and truncate paths

### Step 9.2: Stable Rules Checklist
1. Obviously correct? **YES** — follows spec, matches all other
   filesystems
2. Fixes real bug? **YES** — wrong errno, missing 32-bit clamping
3. Important issue? **MEDIUM** — wrong error code, potential 32-bit
   issues
4. Small and contained? **YES** — ~5 logic lines, 3 files
5. No new features? **CORRECT** — pure bug fix
6. Applies to stable? **YES** — clean context match

### Step 9.3: Exception Categories
None applicable — this is a straightforward bug fix.

---

## Verification

- [Phase 1] Parsed tags: Signed-off-by from author (David Timber) and
  maintainer (Namjae Jeon)
- [Phase 2] Diff analysis: 3 files, ~5 logic lines; adds
  EXFAT_MAX_NUM_CLUSTER constant, changes s_maxbytes calc, adds comment
- [Phase 2] Verified VFS uses of s_maxbytes: `fs/open.c:333`
  (vfs_fallocate), `fs/read_write.c:1714,1728`
  (generic_write_check_limits), `fs/attr.c:264` (inode_newsize_ok)
- [Phase 3] git blame: buggy code introduced in `719c1e182916` (v5.7,
  2020-03-02), present in all stable trees with exfat
- [Phase 3] No intermediate fixes for this issue
- [Phase 3] Recent file history shows no conflicting changes around
  s_maxbytes line
- [Phase 4] Found related fallocate patch on lore (`yhbt.net/lore/linux-
  fsdevel/20260228084542.485615-1-dxdt@dev.snart.me/T/`); s_maxbytes fix
  is separate standalone patch
- [Phase 4] Namjae Jeon (maintainer) reviewed and applied
- [Phase 5] s_maxbytes is used by VFS write checks, truncate checks, and
  fallocate checks — confirmed via grep
- [Phase 5] Compared with FAT (`0xffffffff`), NTFS3
  (`MAX_LFS_FILESIZE`), JFS (`min(..., MAX_LFS_FILESIZE)`) — all use
  format max, not volume size
- [Phase 6] Code context matches 7.0 tree exactly — clean apply
  confirmed
- [Phase 6] No competing fix in any stable tree
- [Phase 8] Failure mode: wrong errno (EFBIG vs ENOSPC), severity
  MEDIUM; 32-bit MAX_LFS_FILESIZE clamping issue

The fix is small, obviously correct, follows established VFS conventions
used by all other filesystems, and fixes a long-standing correctness bug
in exfat's `s_maxbytes` initialization. The risk is very low and the
benefit is clear.

**YES**

 fs/exfat/exfat_raw.h |  1 +
 fs/exfat/file.c      |  1 +
 fs/exfat/super.c     | 11 ++++++++---
 3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/fs/exfat/exfat_raw.h b/fs/exfat/exfat_raw.h
index 4082fa7b8c142..ec70cd35bba0c 100644
--- a/fs/exfat/exfat_raw.h
+++ b/fs/exfat/exfat_raw.h
@@ -25,6 +25,7 @@
 #define EXFAT_FIRST_CLUSTER	2
 #define EXFAT_DATA_CLUSTER_COUNT(sbi)	\
 	((sbi)->num_clusters - EXFAT_RESERVED_CLUSTERS)
+#define EXFAT_MAX_NUM_CLUSTER		(0xFFFFFFF5)
 
 /* AllocationPossible and NoFatChain field in GeneralSecondaryFlags Field */
 #define ALLOC_POSSIBLE		0x01
diff --git a/fs/exfat/file.c b/fs/exfat/file.c
index 90cd540afeaa7..310083537a91d 100644
--- a/fs/exfat/file.c
+++ b/fs/exfat/file.c
@@ -33,6 +33,7 @@ static int exfat_cont_expand(struct inode *inode, loff_t size)
 		return ret;
 
 	num_clusters = EXFAT_B_TO_CLU(exfat_ondisk_size(inode), sbi);
+	/* integer overflow is already checked in inode_newsize_ok(). */
 	new_num_clusters = EXFAT_B_TO_CLU_ROUND_UP(size, sbi);
 
 	if (new_num_clusters == num_clusters)
diff --git a/fs/exfat/super.c b/fs/exfat/super.c
index 83396fd265cda..95d87e2d7717f 100644
--- a/fs/exfat/super.c
+++ b/fs/exfat/super.c
@@ -531,9 +531,14 @@ static int exfat_read_boot_sector(struct super_block *sb)
 	if (sbi->vol_flags & MEDIA_FAILURE)
 		exfat_warn(sb, "Medium has reported failures. Some data may be lost.");
 
-	/* exFAT file size is limited by a disk volume size */
-	sb->s_maxbytes = (u64)(sbi->num_clusters - EXFAT_RESERVED_CLUSTERS) <<
-		sbi->cluster_size_bits;
+	/*
+	 * Set to the max possible volume size for this volume's cluster size so
+	 * that any integer overflow from bytes to cluster size conversion is
+	 * checked in inode_newsize_ok(). Clamped to MAX_LFS_FILESIZE for 32-bit
+	 * machines.
+	 */
+	sb->s_maxbytes = min(MAX_LFS_FILESIZE,
+			     EXFAT_CLU_TO_B((loff_t)EXFAT_MAX_NUM_CLUSTER, sbi));
 
 	/* check logical sector size */
 	if (exfat_calibrate_blocksize(sb, 1 << p_boot->sect_size_bits))
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] hfsplus: fix generic/642 failure

[Sasha Levin]

From: Viacheslav Dubeyko <slava@dubeyko.com>

[ Upstream commit c1307d18caa819ddc28459d858eb38fdd6c3f8a0 ]

The xfstests' test-case generic/642 finishes with
corrupted HFS+ volume:

sudo ./check generic/642
[sudo] password for slavad:
FSTYP -- hfsplus
PLATFORM -- Linux/x86_64 hfsplus-testing-0001 7.0.0-rc1+ #26 SMP PREEMPT_DYNAMIC Mon Mar 23 17:24:32 PDT 2026
MKFS_OPTIONS -- /dev/loop51
MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch

generic/642 6s ... _check_generic_filesystem: filesystem on /dev/loop51 is inconsistent
(see xfstests-dev/results//generic/642.full for details)

Ran: generic/642
Failures: generic/642
Failed 1 of 1 tests

sudo fsck.hfs -d /dev/loop51
** /dev/loop51
Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K.
Executing fsck_hfs (version 540.1-Linux).
** Checking non-journaled HFS Plus Volume.
The volume name is untitled
** Checking extents overflow file.
** Checking catalog file.
** Checking multi-linked files.
** Checking catalog hierarchy.
** Checking extended attributes file.
invalid free nodes - calculated 1637 header 1260
Invalid B-tree header
Invalid map node
(8, 0)
** Checking volume bitmap.
** Checking volume information.
Verify Status: VIStat = 0x0000, ABTStat = 0xc000 EBTStat = 0x0000
CBTStat = 0x0000 CatStat = 0x00000000
** Repairing volume.
** Rechecking volume.
** Checking non-journaled HFS Plus Volume.
The volume name is untitled
** Checking extents overflow file.
** Checking catalog file.
** Checking multi-linked files.
** Checking catalog hierarchy.
** Checking extended attributes file.
** Checking volume bitmap.
** Checking volume information.
** The volume untitled was repaired successfully.

The fsck tool detected that Extended Attributes b-tree is corrupted.
Namely, the free nodes number is incorrect and map node
bitmap has inconsistent state. Analysis has shown that during
b-tree closing there are still some lost b-tree's nodes in
the hash out of b-tree structure. But this orphaned b-tree nodes
are still accounted as used in map node bitmap:

tree_cnid 8, nidx 0, node_count 1408, free_nodes 1403
tree_cnid 8, nidx 1, node_count 1408, free_nodes 1403
tree_cnid 8, nidx 3, node_count 1408, free_nodes 1403
tree_cnid 8, nidx 54, node_count 1408, free_nodes 1403
tree_cnid 8, nidx 67, node_count 1408, free_nodes 1403
tree_cnid 8, nidx 0, prev 0, next 0, parent 0, num_recs 3, type 0x1, height 0
tree_cnid 8, nidx 1, prev 0, next 0, parent 3, num_recs 1, type 0xff, height 1
tree_cnid 8, nidx 3, prev 0, next 0, parent 0, num_recs 1, type 0x0, height 2
tree_cnid 8, nidx 54, prev 29, next 46, parent 3, num_recs 0, type 0xff, height 1
tree_cnid 8, nidx 67, prev 8, next 14, parent 3, num_recs 0, type 0xff, height 1

This issue happens in hfs_bnode_split() logic during detection
the possibility of moving half ot the records out of the node.
The hfs_bnode_split() contains a loop that implements
a roughly 50/50 split of the B-tree node's records by scanning
the offset table to find where the data crosses the node's midpoint.
If this logic detects the incapability of spliting the node, then
it simply calls hfs_bnode_put() for newly created node. However,
node is not set as HFS_BNODE_DELETED and real deletion of node
doesn't happen. As a result, the empty node becomes orphaned but
it is still accounted as used. Finally, fsck tool detects this
inconsistency of HFS+ volume.

This patch adds call of hfs_bnode_unlink() before hfs_bnode_put()
for the case if new node cannot be used for spliting the existing
node.

sudo ./check generic/642
FSTYP         -- hfsplus
PLATFORM      -- Linux/x86_64 hfsplus-testing-0001 7.0.0-rc1+ #26 SMP PREEMPT_DYNAMIC Fri Apr  3 12:39:13 PDT 2026
MKFS_OPTIONS  -- /dev/loop51
MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch

generic/642 40s ...  39s
Ran: generic/642
Passed all 1 tests

Closes: https://github.com/hfs-linux-kernel/hfs-linux-kernel/issues/242
cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
cc: Yangtao Li <frank.li@vivo.com>
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
Link: https://lore.kernel.org/r/20260403230556.614171-6-slava@dubeyko.com
Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed. Let me compile the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
Record: [hfsplus] [fix] Fix filesystem corruption triggered by xfstests
generic/642 test case in the B-tree node split logic.

**Step 1.2: Tags**
- `Closes: https://github.com/hfs-linux-kernel/hfs-linux-
  kernel/issues/242` - Tracked issue
- `cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>` - HFS
  co-maintainer
- `cc: Yangtao Li <frank.li@vivo.com>` - HFS co-maintainer
- `cc: linux-fsdevel@vger.kernel.org` - filesystem mailing list
- `Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>` - Author and
  HFS maintainer
- `Link:
  https://lore.kernel.org/r/20260403230556.614171-6-slava@dubeyko.com`
- No Fixes: tag, no Reported-by, no Cc: stable (expected)

Record: Author is the HFS/HFS+ subsystem maintainer. No syzbot
involvement. Fix has a tracked GitHub issue.

**Step 1.3: Commit Body Analysis**
The commit message includes detailed fsck output showing the corruption:
"invalid free nodes - calculated 1637 header 1260" and "Invalid B-tree
header / Invalid map node". The Extended Attributes B-tree (cnid 8)
becomes corrupted with orphaned nodes that are allocated in the bitmap
but not part of the B-tree structure. The root cause is that
`hfs_bnode_split()` allocates a new node via `hfs_bmap_alloc()` but when
the split fails (node can't be split), it only calls `hfs_bnode_put()`
without `hfs_bnode_unlink()`, so the node remains "used" in the bitmap
forever.

Record: Bug = filesystem corruption (orphaned B-tree nodes). Symptom =
fsck detects inconsistent free node count and invalid map node bitmap.
Root cause = missing `hfs_bnode_unlink()` in `hfs_bnode_split()` error
path.

**Step 1.4: Hidden Bug Fix Detection**
Record: This is an explicit bug fix, not disguised. The title says "fix"
and the description clearly explains the corruption mechanism.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Files changed: `fs/hfsplus/brec.c` only
- Single function modified: `hfs_bnode_split()`
- Net change: ~8 lines added (3 new variables, 1 `hfs_bnode_unlink`
  call, plus magic-number-to-named-constant replacements)
- Scope: Single-file, single-function surgical fix + cleanup

Record: 1 file changed. Function: `hfs_bnode_split()`. Classification:
single-file surgical fix.

**Step 2.2: Code Flow Changes**
The diff has two categories of changes:

1. **Bug fix (critical)**: Addition of `hfs_bnode_unlink(new_node)`
   before `hfs_bnode_put(new_node)` in the error path when the split
   fails (the `/* panic? */` path). Before: node was only `put` (memory
   freed but bitmap allocation kept). After: node is properly `unlinked`
   (sets `HFS_BNODE_DELETED` flag) then `put` (triggers
   `hfs_bmap_free()` to release bitmap allocation).

2. **Cleanup (non-functional)**: Magic numbers `14` → `node_desc_size`,
   `2` → `rec_size`, `4` → `(2 * rec_size)`. All mathematically
   equivalent.

Record: Error path fix + equivalent constant replacement. The error path
now properly frees allocated nodes.

**Step 2.3: Bug Mechanism**
This is a **resource leak** (bitmap allocation leak) that causes
**filesystem corruption**:
- `hfs_bmap_alloc()` marks a node as used in the bitmap
- `hfs_bnode_put()` only calls `hfs_bmap_free()` if `HFS_BNODE_DELETED`
  flag is set (verified in `bnode.c` lines 685-692)
- `hfs_bnode_unlink()` sets `HFS_BNODE_DELETED` (verified in `bnode.c`
  line 423)
- Without `hfs_bnode_unlink()`, the bitmap entry persists = orphaned
  node

Record: Resource leak (bitmap) → filesystem corruption. Bug category:
missing cleanup on error path.

**Step 2.4: Fix Quality**
- The fix follows the exact same pattern used in `hfs_brec_remove()` at
  line 199: `hfs_bnode_unlink(node)` before the node is released
- Obviously correct: the mechanism chain is verifiable (`unlink → set
  DELETED → put → bmap_free`)
- Regression risk: LOW. `hfs_bnode_unlink()` adjusts prev/next pointers,
  but at this point the node was never fully linked into the tree
  (node->next was set but the predecessor's next pointer wasn't updated
  yet), so the unlink is effectively a no-op for the linked list and
  just sets the DELETED flag
- The magic number cleanup is equivalent and safe

Record: Fix is obviously correct, follows established pattern. Minimal
regression risk.

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
The buggy code (lines 268-283, the `for(;;)` loop and error path with
`/* panic? */`) dates to commit `1da177e4c3f41` (Linux 2.6.12-rc2, April
2005). This means the bug has existed since the very beginning of the
git era - ALL stable kernel trees are affected.

Record: Bug introduced in 2005 (Linux 2.6.12-rc2). Present in ALL stable
trees.

**Step 3.2: Fixes Tag**
No Fixes: tag present (expected).

**Step 3.3: File History**
`fs/hfsplus/brec.c` has 18 commits total. Recent activity shows multiple
xfstests fixes from the same author (generic/020, generic/037,
generic/062, generic/480, generic/498). The function has been
essentially unchanged since 2005 with only minor modifications by Al
Viro in 2010 for error handling.

Record: File has low churn. Related recent fixes from same author for
other xfstests.

**Step 3.4: Author**
Viacheslav Dubeyko is the HFS/HFS+ subsystem MAINTAINER (confirmed by
the merge tag from Linus pulling from his tree). He has numerous recent
commits in this subsystem.

Record: Author is the subsystem maintainer. High authority.

**Step 3.5: Dependencies**
This is PATCH 5/5 of a series "hfsplus: fix b-tree logic issues".
However:
- Patches 1-4 modify `bnode.c`, `btree.c`, `xattr.c`, `inode.c`,
  `super.c` - NONE modify `brec.c`
- PATCH 5 is the ONLY patch touching `brec.c` → no textual conflicts
- PATCH 1 adds spin_lock in `hfs_bnode_unlink()` (race protection) but
  `hfs_bnode_unlink()` works correctly without it
- PATCHes 2-3 improve `hfs_bmap_free()` error handling and add
  `hfs_btree_write()` calls, but the basic free mechanism works without
  these
- PATCH 4 reworks xattr map node creation - unrelated to `brec.c`

Record: No dependencies on patches 1-4. This patch is self-contained.

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1: Original Discussion**
b4 dig was unable to find the commit. The Link tag points to
`https://lore.kernel.org/r/20260403230556.614171-6-slava@dubeyko.com`.
The series is "[PATCH 0/5] hfsplus: fix b-tree logic issues". The GitHub
issue #242 confirmed the bug report and was closed by the author
referencing this patchset.

Record: Tracked via GitHub issue. Series posted to linux-fsdevel. Lore
not accessible due to bot protection.

**Step 4.2: Reviewers**
The patch was CC'd to John Paul Adrian Glaubitz and Yangtao Li (HFS co-
maintainers) and linux-fsdevel@vger.kernel.org. The author is the
subsystem maintainer.

Record: Sent to appropriate maintainers and mailing list.

**Step 4.3: Bug Report**
GitHub issue #242 was filed by the maintainer himself after xfstests
testing on v7.0.0-rc1. The issue includes full fsck output confirming
the corruption.

Record: Bug report with full evidence of corruption.

**Step 4.4-4.5: Related Patches / Stable History**
No prior stable discussions found for this specific issue.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Key Functions**
Modified: `hfs_bnode_split()` (the only function changed)

**Step 5.2: Callers**
`hfs_bnode_split()` is called from:
1. `hfs_brec_insert()` (line 100) - triggered by ANY B-tree insertion
2. `hfs_brec_update_parent()` (line 400) - triggered during parent key
   updates

`hfs_brec_insert()` is called from:
- `catalog.c` - file/directory creation, renaming (4 call sites)
- `attributes.c` - extended attribute insertion
- `extents.c` - extent record insertion
- `brec.c` - recursive parent update

Record: Extremely high-impact code path. Reachable from all HFS+ file
operations that require B-tree insertion.

**Step 5.3-5.4: Callees / Call Chain**
The bug path: userspace file operation → VFS → HFS+ catalog/xattr/extent
operation → `hfs_brec_insert()` → `hfs_bnode_split()` →
`hfs_bmap_alloc()` → fail to split → missing `hfs_bnode_unlink()` →
orphaned node → filesystem corruption.

Record: Fully reachable from userspace file operations.

**Step 5.5: Similar Patterns**
`hfs_brec_remove()` at line 199 already uses `hfs_bnode_unlink(node)`
before releasing the node - this is the correct pattern. The bug in
`hfs_bnode_split()` was the omission of this call.

Record: Established pattern exists in sibling function.

## PHASE 6: CROSS-REFERENCING

**Step 6.1: Buggy Code in Stable**
The buggy code dates to 2005 (Linux 2.6.12). ALL active stable trees
contain this bug.

Record: All stable trees affected.

**Step 6.2: Backport Complications**
The function in stable trees should be nearly identical to the current
v7.0 code (blame shows minimal changes). The diff includes magic-number-
to-constant cleanup which adds minor noise but should apply cleanly
since the base code is unchanged. If minor conflicts arise, the critical
one-line fix (`hfs_bnode_unlink(new_node)`) can be easily cherry-picked
manually.

Record: Expected clean apply or trivial adaptation needed.

**Step 6.3: Related Fixes Already in Stable**
No related fixes for this specific issue found in stable.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: Subsystem**
HFS+ filesystem (`fs/hfsplus/`). Criticality: IMPORTANT - used by macOS
dual-boot systems, media devices, and anyone accessing Apple-formatted
volumes.

**Step 7.2: Activity**
Active development with ~20 recent commits, many of which are xfstests
fixes from the maintainer.

Record: Subsystem is actively maintained.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**
Users of HFS+ filesystems on Linux (dual-boot macOS, Apple media
devices, external drives).

**Step 8.2: Trigger Conditions**
Triggered when a B-tree node split fails (records too large to split
evenly). This happens during normal file operations (creating files with
xattrs, large directories, etc.). The xfstests generic/642 test reliably
triggers it.

Record: Triggered by normal file operations. Reproducible.

**Step 8.3: Failure Mode Severity**
**CRITICAL**: Filesystem corruption (orphaned B-tree nodes, incorrect
free node count, invalid map node bitmap). This is silent data
corruption - the filesystem appears to work but is internally
inconsistent, potentially leading to data loss.

Record: CRITICAL - silent filesystem corruption.

**Step 8.4: Risk-Benefit Ratio**
- BENEFIT: Very High - prevents filesystem corruption on all HFS+
  volumes
- RISK: Very Low - one added function call following established
  pattern, plus equivalent constant replacements
- Fix is 1 functional line + cleanup in a single function

Record: Extremely favorable benefit-to-risk ratio.

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence Compilation**

FOR backporting:
- Fixes CRITICAL filesystem corruption (orphaned B-tree nodes)
- Bug present since Linux 2.6.12 (2005) - affects ALL stable trees
- Reproducible via xfstests generic/642
- Fix is obviously correct, follows established pattern
  (`hfs_brec_remove()` already uses `hfs_bnode_unlink()`)
- Mechanism verified: `unlink → set DELETED → put → bmap_free`
- Author is the HFS/HFS+ subsystem maintainer
- Self-contained - no dependencies on other patches in the series
- Only modifies one function in one file
- Test evidence: xfstests passes after fix

AGAINST backporting:
- Patch includes magic-number cleanup alongside the bug fix (makes diff
  larger than necessary)
- Part of a 5-patch series (but verified as standalone)
- No explicit `Cc: stable` or `Fixes:` tag (expected)

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** - verified mechanism, follows
   established pattern, tested with xfstests
2. Fixes real bug? **YES** - filesystem corruption
3. Important issue? **YES** - CRITICAL (data corruption)
4. Small and contained? **YES** - single function in single file, ~50
   lines of diff
5. No new features/APIs? **YES** - pure bug fix + cleanup
6. Can apply to stable? **YES** - code unchanged since 2005

**Step 9.3: Exception Categories**
Not applicable - this is a standard bug fix.

**Step 9.4: Decision**
The evidence overwhelmingly supports backporting. This fixes filesystem
data corruption that has existed since 2005 in a commonly exercised code
path. The fix is minimal, correct, and verified.

## Verification

- [Phase 1] Parsed tags: Closes: GitHub issue #242, Link: to lore, CC:
  to HFS co-maintainers
- [Phase 2] Diff analysis: Core fix is 1 line
  (`hfs_bnode_unlink(new_node)`) + magic number cleanup, all in
  `hfs_bnode_split()`
- [Phase 2] Verified equivalence: `14 == sizeof(struct hfs_bnode_desc)`,
  `2 == sizeof(__be16)`, `4 == 2*sizeof(__be16)` - all constant
  replacements are mathematically identical
- [Phase 3] git blame: Buggy code from commit `1da177e4c3f41` (Linux
  2.6.12-rc2, 2005), present in ALL stable trees
- [Phase 3] git log: 18 total commits to brec.c, minimal changes to the
  affected function
- [Phase 3] Author check: Viacheslav Dubeyko is the HFS/HFS+ maintainer
  (confirmed via merge tag from Linus)
- [Phase 3] Series analysis: PATCH 5/5, but patches 1-4 don't touch
  brec.c - verified no textual or functional dependencies
- [Phase 4] GitHub issue #242: Confirmed bug report with fsck evidence,
  closed by patchset
- [Phase 5] Verified `hfs_bnode_unlink()` sets `HFS_BNODE_DELETED` flag
  (bnode.c:423)
- [Phase 5] Verified `hfs_bnode_put()` calls `hfs_bmap_free()` only when
  `HFS_BNODE_DELETED` set (bnode.c:685-690)
- [Phase 5] Verified `hfs_brec_remove()` uses same `hfs_bnode_unlink()`
  pattern (brec.c:199)
- [Phase 5] Callers traced: `hfs_bnode_split()` reachable from
  catalog/xattr/extent operations → all normal file operations
- [Phase 6] Code unchanged since 2005 in all stable trees
- [Phase 8] Failure mode: CRITICAL - silent filesystem corruption

**YES**

 fs/hfsplus/brec.c | 32 ++++++++++++++++++++------------
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/fs/hfsplus/brec.c b/fs/hfsplus/brec.c
index 6796c1a80e997..e3df89284079d 100644
--- a/fs/hfsplus/brec.c
+++ b/fs/hfsplus/brec.c
@@ -239,6 +239,9 @@ static struct hfs_bnode *hfs_bnode_split(struct hfs_find_data *fd)
 	struct hfs_bnode_desc node_desc;
 	int num_recs, new_rec_off, new_off, old_rec_off;
 	int data_start, data_end, size;
+	size_t rec_off_tbl_size;
+	size_t node_desc_size = sizeof(struct hfs_bnode_desc);
+	size_t rec_size = sizeof(__be16);
 
 	tree = fd->tree;
 	node = fd->bnode;
@@ -265,18 +268,22 @@ static struct hfs_bnode *hfs_bnode_split(struct hfs_find_data *fd)
 		return next_node;
 	}
 
-	size = tree->node_size / 2 - node->num_recs * 2 - 14;
-	old_rec_off = tree->node_size - 4;
+	rec_off_tbl_size = node->num_recs * rec_size;
+	size = tree->node_size / 2;
+	size -= node_desc_size;
+	size -= rec_off_tbl_size;
+	old_rec_off = tree->node_size - (2 * rec_size);
+
 	num_recs = 1;
 	for (;;) {
 		data_start = hfs_bnode_read_u16(node, old_rec_off);
 		if (data_start > size)
 			break;
-		old_rec_off -= 2;
+		old_rec_off -= rec_size;
 		if (++num_recs < node->num_recs)
 			continue;
-		/* panic? */
 		hfs_bnode_put(node);
+		hfs_bnode_unlink(new_node);
 		hfs_bnode_put(new_node);
 		if (next_node)
 			hfs_bnode_put(next_node);
@@ -287,7 +294,7 @@ static struct hfs_bnode *hfs_bnode_split(struct hfs_find_data *fd)
 		/* new record is in the lower half,
 		 * so leave some more space there
 		 */
-		old_rec_off += 2;
+		old_rec_off += rec_size;
 		num_recs--;
 		data_start = hfs_bnode_read_u16(node, old_rec_off);
 	} else {
@@ -295,27 +302,28 @@ static struct hfs_bnode *hfs_bnode_split(struct hfs_find_data *fd)
 		hfs_bnode_get(new_node);
 		fd->bnode = new_node;
 		fd->record -= num_recs;
-		fd->keyoffset -= data_start - 14;
-		fd->entryoffset -= data_start - 14;
+		fd->keyoffset -= data_start - node_desc_size;
+		fd->entryoffset -= data_start - node_desc_size;
 	}
 	new_node->num_recs = node->num_recs - num_recs;
 	node->num_recs = num_recs;
 
-	new_rec_off = tree->node_size - 2;
-	new_off = 14;
+	new_rec_off = tree->node_size - rec_size;
+	new_off = node_desc_size;
 	size = data_start - new_off;
 	num_recs = new_node->num_recs;
 	data_end = data_start;
 	while (num_recs) {
 		hfs_bnode_write_u16(new_node, new_rec_off, new_off);
-		old_rec_off -= 2;
-		new_rec_off -= 2;
+		old_rec_off -= rec_size;
+		new_rec_off -= rec_size;
 		data_end = hfs_bnode_read_u16(node, old_rec_off);
 		new_off = data_end - size;
 		num_recs--;
 	}
 	hfs_bnode_write_u16(new_node, new_rec_off, new_off);
-	hfs_bnode_copy(new_node, 14, node, data_start, data_end - data_start);
+	hfs_bnode_copy(new_node, node_desc_size,
+			node, data_start, data_end - data_start);
 
 	/* update new bnode header */
 	node_desc.next = cpu_to_be32(new_node->next);
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] virtiofs: add FUSE protocol validation

[Sasha Levin]

From: Yuto Ohnuki <ytohnuki@amazon.com>

[ Upstream commit 68b69fa0edb241a946cd4c850110990f30705164 ]

Add virtio_fs_verify_response() to validate that the server properly
follows the FUSE protocol by checking:

- Response length is at least sizeof(struct fuse_out_header).
- oh.len matches the actual response length.
- oh.unique matches the request's unique identifier.

On validation failure, set error to -EIO and normalize oh.len to prevent
underflow in copy_args_from_argbuf().

Addresses the TODO comment in virtio_fs_request_complete().

Signed-off-by: Yuto Ohnuki <ytohnuki@amazon.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a comprehensive analysis. Let
me compile my findings.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: virtiofs (fs/fuse)
- Action verb: "add" — but the body reveals this is actually a bug fix
  (prevents underflow in `copy_args_from_argbuf()`)
- Summary: Adds FUSE protocol response validation to prevent memory
  corruption from invalid server responses

**Step 1.2: Tags**
- Signed-off-by: Yuto Ohnuki (author)
- Reviewed-by: Stefan Hajnoczi (original virtiofs author, Red Hat)
- Signed-off-by: Miklos Szeredi (FUSE subsystem maintainer)
- No Fixes: tag (expected for autosel)
- No Cc: stable (expected)
- No Reported-by (proactive fix addressing long-standing TODO)

**Step 1.3: Commit Body**
- Explicitly states: "normalize oh.len to prevent underflow in
  copy_args_from_argbuf()"
- Addresses a known TODO since 2020 (commit bb737bbe48bea9)
- Three specific checks: minimum length, oh.len match, oh.unique match

**Step 1.4: Hidden Bug Fix Detection**
YES — this is a bug fix disguised as "add validation." The key phrase is
"prevent underflow in copy_args_from_argbuf()." Looking at line 732 of
`copy_args_from_argbuf()`:

```732:732:fs/fuse/virtio_fs.c
        remaining = req->out.h.len - sizeof(req->out.h);
```

If `req->out.h.len < sizeof(req->out.h)` (16 bytes), `remaining` is
`unsigned int` and underflows to ~4 billion. This `remaining` is then
used to control `memcpy` at line 746 — a buffer overflow.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Files: fs/fuse/virtio_fs.c only
- Lines: +25 added, -4 removed (net +21)
- Functions modified: `virtio_fs_requests_done_work()` (4 lines added)
- Function added: `virtio_fs_verify_response()` (22 lines)
- TODO comment removed from `virtio_fs_request_complete()`
- Scope: single-file, surgical fix

**Step 2.2: Code Flow Change**
- BEFORE: No validation of server responses. `virtqueue_get_buf()`
  returns response → immediately processed by `copy_args_from_argbuf()`
  with no bounds checking on `oh.len` or `oh.unique`.
- AFTER: Each response is validated before processing. Invalid responses
  get `error = -EIO` and `oh.len = sizeof(struct fuse_out_header)`,
  preventing underflow.

**Step 2.3: Bug Mechanism**
Category: **Buffer overflow / memory safety fix** — specifically
preventing unsigned integer underflow leading to out-of-bounds memcpy.

Three failure modes without this fix:
1. `oh.len < sizeof(fuse_out_header)`: `remaining` underflows → massive
   memcpy → buffer overflow
2. `oh.len != actual_len`: `remaining` doesn't match actual buffer →
   over-read/over-write
3. `oh.unique` mismatch: response processed for wrong request → data
   corruption

**Step 2.4: Fix Quality**
- Obviously correct: simple comparisons against known-good values
- Minimal/surgical: only adds validation, no behavioral changes to valid
  responses
- No regression risk: valid responses pass through unchanged; invalid
  ones get -EIO (safe)
- Well-contained: single file, single subsystem

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
- `copy_args_from_argbuf()`: introduced by Stefan Hajnoczi in
  a62a8ef9d97da2 (2018-06-12) — the original virtiofs driver
- The TODO comment was added by Vivek Goyal in bb737bbe48bea9
  (2020-04-20) when refactoring the request completion path
- The buggy code (lack of validation) has existed since virtiofs was
  first introduced in 2018

**Step 3.2: Fixes tag**: None present (expected)

**Step 3.3: File History**: The file has 86 changes since v5.4. Recent
changes are unrelated (kzalloc_obj conversions, sysfs fixes, folio
conversions).

**Step 3.4: Author**: Yuto Ohnuki has 8 other commits in the tree (xfs,
ext4, igbvf, ixgbevf). Active kernel contributor at Amazon.

**Step 3.5: Dependencies**: None. The fix is entirely self-contained. It
uses existing structures (`fuse_out_header`, `fuse_req`) and doesn't
depend on any recent changes.

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1: Original Discussion**
- Submitted: Feb 16, 2026 by Yuto Ohnuki
- Stefan Hajnoczi (original virtiofs author) gave Reviewed-by same day
  (Feb 17)
- Miklos Szeredi (FUSE maintainer) replied "Applied, thanks." same day
  (Feb 17)
- Single-version patch (no v2/v3), applied immediately
- A competing patch by Li Wang (March 18, 2026) was submitted later —
  Stefan noted this patch was already applied

**Step 4.2: Reviewers**
- Stefan Hajnoczi: original virtiofs author, Red Hat — provided
  Reviewed-by
- Miklos Szeredi: FUSE subsystem maintainer — applied the patch
- Proper mailing lists CC'd: virtualization, linux-fsdevel, linux-kernel

**Step 4.3: Bug Report**: No formal bug report. This was a proactive fix
addressing a known TODO in the code.

**Step 4.5: Stable Discussion**: No explicit stable nomination found.
The fact that another developer independently submitted the same fix (Li
Wang) shows the issue was recognized by multiple people.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions Modified**
- `virtio_fs_verify_response()` (new)
- `virtio_fs_requests_done_work()` (caller of validation)

**Step 5.2: Callers**
- `virtio_fs_requests_done_work()` is the work function for ALL request
  completions off the virtqueue
- Called via `schedule_work()` from `virtio_fs_vq_done()`, the virtqueue
  interrupt handler
- Every FUSE response goes through this path

**Step 5.4: Call Chain**
```
virtio_fs_vq_done() [virtqueue interrupt]
  → schedule_work(&fsvq->done_work)
    → virtio_fs_requests_done_work()
      → virtqueue_get_buf(vq, &len)  [gets response from virtqueue]
      → **virtio_fs_verify_response(req, len)**  [NEW: validates
response]
      → ... → virtio_fs_request_complete()
             → copy_args_from_argbuf()  [contains the underflow
vulnerability]
```

The validation is placed correctly — before `copy_args_from_argbuf()` is
called through any path.

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

**Step 6.1: Buggy Code Exists in Stable**
- The original `copy_args_from_argbuf()` with the unvalidated
  `remaining` calculation was introduced in 2018 (a62a8ef9d97da2)
- virtiofs exists in all kernels since v5.4
- The vulnerability exists in ALL stable trees: 5.4.y, 5.10.y, 5.15.y,
  6.1.y, 6.6.y, 6.12.y, 7.0.y

**Step 6.2: Backport Complications**
- The code around the affected area is very stable — hasn't changed
  significantly
- The patch should apply cleanly or with trivial offset adjustments
- No conflicting refactors in the validation insertion point

**Step 6.3: Related Fixes**: No other fix for this issue exists in
stable.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: Subsystem Criticality**
- virtiofs (fs/fuse): IMPORTANT — used in VM environments (QEMU, cloud)
- Used in containers, cloud workloads, development environments
- Security boundary: guest kernel trusting host FUSE server responses

**Step 7.2: Activity**: Active subsystem with 86 changes since v5.4.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**
- All users of virtiofs (VM guests mounting host filesystems via virtio-
  fs)
- Cloud users, container users, QEMU/KVM users

**Step 8.2: Trigger Conditions**
- A malicious or buggy virtiofs server (virtiofsd) sends a response
  with:
  - `oh.len < 16` (trigger underflow)
  - `oh.len != actual_response_len` (trigger buffer mismatch)
  - Wrong `oh.unique` (trigger data corruption)
- In a VM security context, this is security-relevant: a compromised
  host could exploit this to corrupt guest kernel memory

**Step 8.3: Failure Mode Severity**
- **CRITICAL**: unsigned integer underflow → massive memcpy → buffer
  overflow → kernel memory corruption
- This can lead to: kernel crash (oops/panic), data corruption, or
  potential code execution in the guest kernel

**Step 8.4: Risk-Benefit Ratio**
- BENEFIT: Prevents memory corruption from malicious/buggy FUSE server
  responses — HIGH
- RISK: 25 lines of simple validation logic, obviously correct — VERY
  LOW
- Ratio: Very favorable for backport

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence Compilation**

FOR backport:
- Fixes real unsigned underflow → buffer overflow vulnerability in
  `copy_args_from_argbuf()`
- Security-relevant in VM environments (host→guest attack vector)
- Small, surgical fix (25 lines added, 4 removed)
- Obviously correct (simple comparisons)
- Reviewed by original virtiofs author (Stefan Hajnoczi)
- Applied by FUSE maintainer (Miklos Szeredi)
- No dependencies — completely standalone
- Bug exists in all stable trees since v5.4
- Another developer independently tried to fix the same issue (validates
  its importance)

AGAINST backport:
- Commit message says "add" not "fix" — but the body explicitly mentions
  preventing underflow
- No formal bug report or syzbot report — proactive fix
- Requires a malicious/buggy server to trigger (but this IS the threat
  model for VMs)

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — simple bounds checking,
   reviewed by subsystem experts
2. Fixes a real bug? **YES** — unsigned underflow → buffer overflow
3. Important issue? **YES** — memory corruption (CRITICAL severity)
4. Small and contained? **YES** — 25 lines, single file
5. No new features or APIs? **YES** — only adds validation
6. Can apply to stable? **YES** — no dependencies, code unchanged since
   2018

**Step 9.3: Exception Categories**: N/A — this qualifies as a regular
bug fix

**Step 9.4: Decision**

This commit fixes a genuine memory safety vulnerability — an unsigned
integer underflow in `copy_args_from_argbuf()` that leads to a buffer
overflow via `memcpy`. The fix is small (25 lines), obviously correct
(simple comparison checks), reviewed by the original virtiofs author,
and applied by the FUSE maintainer. The vulnerable code has existed
since virtiofs was introduced in 2018, affecting all stable trees from
v5.4 onward.

## Verification

- [Phase 1] Parsed tags: Reviewed-by Stefan Hajnoczi, Signed-off-by
  Miklos Szeredi (FUSE maintainer)
- [Phase 2] Diff analysis: +25/-4 lines in fs/fuse/virtio_fs.c; adds
  `virtio_fs_verify_response()` and 4-line caller
- [Phase 2] Verified underflow: line 732 `remaining = req->out.h.len -
  sizeof(req->out.h)` — unsigned int subtraction with no bounds check →
  underflow when oh.len < 16
- [Phase 2] Verified memcpy consequence: line 746
  `memcpy(args->out_args[i].value, req->argbuf + offset, argsize)` uses
  the underflowed `remaining`
- [Phase 3] git blame: buggy code introduced in a62a8ef9d97da2
  (2018-06-12, Stefan Hajnoczi, virtiofs initial implementation)
- [Phase 3] git blame: TODO comment added by bb737bbe48bea9 (2020-04-20,
  Vivek Goyal)
- [Phase 3] git tag: original code exists since v5.4 (confirmed via git
  log v5.4 -- fs/fuse/virtio_fs.c)
- [Phase 4] Lore discussion: original patch at
  spinics.net/lists/kernel/msg6051405.html — single version, applied
  immediately
- [Phase 4] Stefan Hajnoczi provided Reviewed-by (Feb 17, 2026)
- [Phase 4] Miklos Szeredi replied "Applied, thanks." (Feb 17, 2026)
- [Phase 4] Competing fix by Li Wang (March 2026) confirms independent
  recognition of the issue
- [Phase 5] Traced call chain: virtqueue interrupt → done_work →
  virtio_fs_requests_done_work() → validation → copy_args_from_argbuf()
- [Phase 5] Confirmed all response processing paths go through the
  validation point
- [Phase 6] Code exists unchanged in stable 7.0 tree (verified by
  reading current file, lines 724-759)
- [Phase 6] No conflicting changes — patch should apply cleanly
- [Phase 8] Failure mode: unsigned underflow → buffer overflow → kernel
  memory corruption (CRITICAL)
- UNVERIFIED: Exact clean-apply status on older stable trees (5.10,
  5.15, 6.1) — minor offset adjustments may be needed due to folio
  conversions

**YES**

 fs/fuse/virtio_fs.c | 29 +++++++++++++++++++++++++----
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c
index 057e65b51b99d..2f7485ffac527 100644
--- a/fs/fuse/virtio_fs.c
+++ b/fs/fuse/virtio_fs.c
@@ -758,6 +758,27 @@ static void copy_args_from_argbuf(struct fuse_args *args, struct fuse_req *req)
 	req->argbuf = NULL;
 }
 
+/* Verify that the server properly follows the FUSE protocol */
+static bool virtio_fs_verify_response(struct fuse_req *req, unsigned int len)
+{
+	struct fuse_out_header *oh = &req->out.h;
+
+	if (len < sizeof(*oh)) {
+		pr_warn("virtio-fs: response too short (%u)\n", len);
+		return false;
+	}
+	if (oh->len != len) {
+		pr_warn("virtio-fs: oh.len mismatch (%u != %u)\n", oh->len, len);
+		return false;
+	}
+	if (oh->unique != req->in.h.unique) {
+		pr_warn("virtio-fs: oh.unique mismatch (%llu != %llu)\n",
+			oh->unique, req->in.h.unique);
+		return false;
+	}
+	return true;
+}
+
 /* Work function for request completion */
 static void virtio_fs_request_complete(struct fuse_req *req,
 				       struct virtio_fs_vq *fsvq)
@@ -767,10 +788,6 @@ static void virtio_fs_request_complete(struct fuse_req *req,
 	unsigned int len, i, thislen;
 	struct folio *folio;
 
-	/*
-	 * TODO verify that server properly follows FUSE protocol
-	 * (oh.uniq, oh.len)
-	 */
 	args = req->args;
 	copy_args_from_argbuf(args, req);
 
@@ -824,6 +841,10 @@ static void virtio_fs_requests_done_work(struct work_struct *work)
 		virtqueue_disable_cb(vq);
 
 		while ((req = virtqueue_get_buf(vq, &len)) != NULL) {
+			if (!virtio_fs_verify_response(req, len)) {
+				req->out.h.error = -EIO;
+				req->out.h.len = sizeof(struct fuse_out_header);
+			}
 			spin_lock(&fpq->lock);
 			list_move_tail(&req->list, &reqs);
 			spin_unlock(&fpq->lock);
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] exfat: Fix bitwise operation having different size

[Sasha Levin]

From: Philipp Hahn <phahn-oss@avm.de>

[ Upstream commit 3dce5bb82c97fc2ac28d80d496120a6525ce3fb7 ]

cpos has type loff_t (long long), while s_blocksize has type u32. The
inversion wil happen on u32, the coercion to s64 happens afterwards and
will do 0-left-paddding, resulting in the upper bits getting masked out.

Cast s_blocksize to loff_t before negating it.

Found by static code analysis using Klocwork.

Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Good. Now I have all the information needed for the complete analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
Record: [subsystem: exfat (fs/exfat)] [action verb: Fix] [summary: Fix a
type mismatch in bitwise operation where `~(sb->s_blocksize - 1)`
operates at `unsigned long` width, clearing upper bits of 64-bit `cpos`]

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Signed-off-by: Philipp Hahn <phahn-oss@avm.de>** - author from AVM
  (router/embedded device vendor, makes Fritz!Box etc.)
- **Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>** - exfat
  subsystem maintainer accepted the patch
- No Fixes: tag (expected for candidates under review)
- No Cc: stable tag (expected)
- No Reported-by: (found by static analysis)
- No Link: tag

Record: Minimal tags. Author is from an embedded device company.
Maintainer signed off.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The commit describes:
- `cpos` is `loff_t` (long long, 64-bit)
- `s_blocksize` is `unsigned long` (32-bit on 32-bit platforms)
- The `~` (bitwise NOT) operates at `unsigned long` width
- When the result is coerced to `loff_t`, zero-extension clears upper 32
  bits
- Fix: cast `s_blocksize` to `loff_t` before negation

Record: Bug mechanism is clearly explained. Found by Klocwork static
analysis. This is a C integer promotion/type width bug on 32-bit
platforms.

### Step 1.4: DETECT HIDDEN BUG FIXES
Record: This is an explicitly stated bug fix, not hidden. The word "Fix"
is in the subject.

---

## PHASE 2: DIFF ANALYSIS - LINE BY LINE

### Step 2.1: INVENTORY THE CHANGES
- **File:** `fs/exfat/dir.c`
- **Change:** 1 line modified (replace `~(sb->s_blocksize - 1)` with
  `~(loff_t)(sb->s_blocksize - 1)`)
- **Function modified:** `exfat_iterate()` (line 252)
- **Scope:** Single-file, single-line surgical fix

Record: Minimal change. One file, one line, one cast added.

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
The changed line is in `exfat_iterate()` at the error recovery path when
`exfat_readdir()` returns `-EIO`:

```c
if (err == -EIO) {
    cpos += 1 << (sb->s_blocksize_bits);
    cpos &= ~(loff_t)(sb->s_blocksize - 1);  // <-- fix here
}
```

**Before:** `~(sb->s_blocksize - 1)` operates at `unsigned long` width.
On 32-bit: produces 32-bit mask, zero-extended to 64 bits, clearing
upper 32 bits of `cpos`.
**After:** `~(loff_t)(sb->s_blocksize - 1)` operates at 64-bit width.
Upper 32 bits of `cpos` are preserved.

Record: Error recovery path. Before: incorrect masking on 32-bit. After:
correct 64-bit masking.

### Step 2.3: IDENTIFY THE BUG MECHANISM
Category: **Type / endianness bug** (specifically, integer
promotion/width bug)

On 32-bit systems, `sb->s_blocksize` is `unsigned long` = 32 bits:
- `sb->s_blocksize - 1` = 0x00000FFF (for 4K blocks)
- `~(sb->s_blocksize - 1)` = 0xFFFFF000 (32-bit unsigned)
- When AND'd with 64-bit `cpos`, this zero-extends to 0x00000000FFFFF000
- Bits 32-63 of `cpos` are incorrectly cleared

Record: Type width mismatch bug on 32-bit platforms. Incorrect zero-
extension of unsigned 32-bit mask when used with 64-bit value.

### Step 2.4: ASSESS THE FIX QUALITY
- **Obviously correct?** YES - the cast ensures the negation operates at
  64-bit width
- **Minimal?** YES - one cast addition
- **Regression risk?** ZERO - identical behavior on 64-bit systems
  (where `unsigned long` is already 64-bit), and correct behavior on
  32-bit
- **Red flags?** None

Record: Perfect fix quality. Zero regression risk.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
The buggy code was introduced in commit `ca06197382bde0` by Namjae Jeon
on 2020-03-02, titled "exfat: add directory operations." This was part
of the initial exfat merge into the kernel for Linux 5.7.

Record: Bug present since initial exfat creation (v5.7, 2020). Affects
all stable trees that contain exfat (5.10+, 5.15+, 6.1+, 6.6+, 6.12+,
7.0).

### Step 3.2: FOLLOW THE FIXES TAG
No Fixes: tag present. The implicit fix target is `ca06197382bde0`.

Record: N/A (no explicit Fixes: tag, which is expected).

### Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
55 commits to `fs/exfat/dir.c` since the initial creation. The file has
been actively developed. Notable: commit `6b151eb5df78d` was a recent
cleanup of `exfat_readdir()` but did not touch the buggy line.

Record: Active file history. The buggy line has been untouched since
initial creation. No prerequisites needed.

### Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
Philipp Hahn (phahn-oss@avm.de) has 5 commits in the tree, mostly
documentation and quirk-related. AVM is a German embedded device company
(Fritz!Box routers). Not the exfat maintainer, but the maintainer
(Namjae Jeon) signed off on this fix.

Record: External contributor from embedded device company. Maintainer
accepted.

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
The fix is a single cast to an existing line. No dependencies on other
commits.

Record: Fully standalone. No dependencies.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1-4.5: MAILING LIST INVESTIGATION
b4 dig could not find the commit (it may be very recent).
lore.kernel.org was behind Anubis anti-scraping protection. Web searches
didn't return the specific lore thread.

Record: Could not access lore discussion. The commit was signed off by
the exfat maintainer Namjae Jeon, confirming acceptance.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: IDENTIFY KEY FUNCTIONS
Modified function: `exfat_iterate()` - the VFS directory iteration
callback for exfat.

### Step 5.2: TRACE CALLERS
`exfat_iterate` is wrapped by `WRAP_DIR_ITER(exfat_iterate)` and used as
`.iterate_shared` in `exfat_dir_operations`. It's called by the VFS when
userspace reads a directory (e.g., `ls`, `readdir()`). This is a very
common operation.

### Step 5.3-5.4: CALL CHAIN
Userspace `getdents64()` syscall -> VFS `iterate_dir()` ->
`exfat_iterate()`. The buggy path is triggered when `exfat_readdir()`
returns `-EIO`.

Record: Reachable from common syscalls. Error path triggered by I/O
errors on storage media.

### Step 5.5: SEARCH FOR SIMILAR PATTERNS
The same pattern `& ~(sb->s_blocksize - 1)` with `loff_t` or `ctx->pos`
variables exists in:
- `fs/ext4/dir.c` (line 255) - same type mismatch with `ctx->pos`
- `fs/ocfs2/dir.c` (line 1912) - same pattern
- `fs/jfs/xattr.c` (multiple places)
- `fs/ntfs3/ntfs_fs.h` (line 1109) - **already fixed** with
  `~(u64)(sb->s_blocksize - 1)` cast

The ntfs3 code already has this fix, confirming this is a known bug
pattern.

Record: Similar bug exists in ext4, ocfs2, jfs. ntfs3 already fixed it.

---

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

### Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?
The buggy code was introduced in `ca06197382bde0` (v5.7). exfat exists
in all active stable trees (5.10, 5.15, 6.1, 6.6, 6.12, 7.0). The
specific buggy line at line 252 has been untouched since creation.

Record: Bug present in ALL active stable trees.

### Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
The surrounding code context is clean and unchanged since the initial
creation. The patch should apply cleanly to all stable trees.

Record: Clean apply expected for all stable trees.

### Step 6.3: RELATED FIXES IN STABLE
A similar exfat overflow fix (`2e9ceb6728f1d` "exfat: fix overflow for
large capacity partition") was explicitly tagged with `Cc:
stable@vger.kernel.org # v5.19+`, establishing precedent for
type/overflow fixes in exfat going to stable.

Record: Precedent exists for similar exfat type fixes going to stable.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: SUBSYSTEM CRITICALITY
**Subsystem:** fs/exfat - exFAT filesystem
**Criticality:** IMPORTANT - exFAT is used on SD cards, USB drives, and
external storage across millions of devices, especially embedded/IoT
devices that run 32-bit ARM.

### Step 7.2: SUBSYSTEM ACTIVITY
Very active - 55+ commits to this file, 20+ recent exfat commits.
Actively maintained by Namjae Jeon.

Record: Important subsystem, actively maintained.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: DETERMINE WHO IS AFFECTED
Users of exFAT filesystems on **32-bit systems** (ARM, MIPS). This
includes many embedded devices, IoT systems, and older hardware. 64-bit
systems are unaffected.

### Step 8.2: DETERMINE THE TRIGGER CONDITIONS
- **Platform:** 32-bit systems only
- **Trigger:** Reading a directory on an exFAT filesystem where
  `exfat_readdir()` returns `-EIO` AND `cpos` > 2^32 (>4GB directory
  position)
- **Likelihood:** LOW - requires very large directory + I/O error +
  32-bit system
- **Unprivileged trigger:** Yes, any user can `ls` a directory

### Step 8.3: FAILURE MODE SEVERITY
When triggered, the upper 32 bits of `cpos` are zeroed, causing the
directory position to jump backward, potentially causing:
- Incorrect directory listing
- Potential infinite loop in directory iteration
- Severity: MEDIUM (incorrect behavior, potential loop)

### Step 8.4: RISK-BENEFIT RATIO
- **Benefit:** LOW-MEDIUM (fixes correctness bug on 32-bit, rare
  trigger)
- **Risk:** EXTREMELY LOW (one cast addition, provably correct, zero
  regression risk on 64-bit)
- **Ratio:** Strongly favorable - near-zero risk for a provable
  correctness fix

Record: Benefit is low-medium, risk is near-zero. Ratio strongly favors
backporting.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**FOR backporting:**
- Provably correct fix for a real C type promotion bug
- One-line change with zero regression risk
- Bug present in all stable trees since v5.7
- Similar fixes in exfat have been backported before (Cc: stable)
- ntfs3 already has the same fix applied, confirming the pattern is
  recognized
- exFAT is widely used on 32-bit embedded systems (SD cards, USB drives)
- Signed off by the exfat maintainer
- Clean apply expected for all stable trees
- Author is from embedded device company (AVM) - directly affected use
  case

**AGAINST backporting:**
- Very low probability trigger (32-bit + huge directory + I/O error)
- Found by static analysis, no user reports
- No Fixes: tag, no Cc: stable (expected for candidates)

### Step 9.2: STABLE RULES CHECKLIST
1. **Obviously correct and tested?** YES - trivially correct cast,
   signed off by maintainer
2. **Fixes a real bug?** YES - provable type width bug on 32-bit
   platforms
3. **Important issue?** BORDERLINE - low probability but real
   correctness issue
4. **Small and contained?** YES - one line, one file
5. **No new features or APIs?** YES
6. **Can apply to stable trees?** YES - untouched line since initial
   creation

### Step 9.3: CHECK FOR EXCEPTION CATEGORIES
No exception category applies. This is a standard correctness fix.

### Step 9.4: DECISION
The fix has essentially zero regression risk (a single type cast that is
provably correct) and fixes a real, if unlikely to trigger, bug. The
risk-benefit ratio overwhelmingly favors backporting. Similar
type/overflow fixes in exfat have been backported before. The code
exists unchanged in all stable trees.

---

## Verification

- [Phase 1] Parsed tags: Signed-off-by from author (AVM) and maintainer
  (Namjae Jeon). No Fixes/Cc:stable (expected).
- [Phase 2] Diff analysis: Single line change in `exfat_iterate()`, adds
  `(loff_t)` cast to ensure 64-bit mask width.
- [Phase 3] git blame: Buggy code introduced in ca06197382bde0 (v5.7,
  2020-03-02), "exfat: add directory operations"
- [Phase 3] git log: 55 commits to file since creation; buggy line
  untouched since initial creation
- [Phase 3] Author check: Philipp Hahn has 5 commits, external
  contributor from AVM (embedded device company)
- [Phase 4] b4 dig: Could not find the commit (may be too recent). Lore
  blocked by anti-scraping.
- [Phase 5] Callers: `exfat_iterate()` is the VFS `.iterate_shared`
  callback, reached via `getdents64()` syscall
- [Phase 5] Similar patterns: Same bug exists in ext4/dir.c,
  ocfs2/dir.c, jfs/xattr.c. ntfs3 already fixed with `~(u64)` cast.
- [Phase 6] Code exists in all active stable trees (5.10, 5.15, 6.1,
  6.6, 6.12, 7.0) - verified via git history
- [Phase 6] Precedent: commit 2e9ceb6728f1d ("exfat: fix overflow for
  large capacity partition") was tagged Cc: stable
- [Phase 6] Clean apply expected - buggy line unchanged since v5.7
- [Phase 7] `s_blocksize` type verified as `unsigned long` in
  `include/linux/fs/super_types.h:136`
- [Phase 8] Failure mode: incorrect directory position on 32-bit,
  potential loop - severity MEDIUM
- UNVERIFIED: Could not verify lore discussion or reviewer comments due
  to anti-scraping protection

**YES**

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

diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c
index 3a4853693d8bf..e710dd196e2f0 100644
--- a/fs/exfat/dir.c
+++ b/fs/exfat/dir.c
@@ -249,7 +249,7 @@ static int exfat_iterate(struct file *file, struct dir_context *ctx)
 		 */
 		if (err == -EIO) {
 			cpos += 1 << (sb->s_blocksize_bits);
-			cpos &= ~(sb->s_blocksize - 1);
+			cpos &= ~(loff_t)(sb->s_blocksize - 1);
 		}
 
 		err = -EIO;
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.1] fuse: validate outarg offset and size in notify store/retrieve

[Sasha Levin]

From: Joanne Koong <joannelkoong@gmail.com>

[ Upstream commit 65161470f95bb579a72673bf303ecf0800b9054b ]

Add validation checking for outarg offset and outarg size values passed
in by the server. MAX_LFS_FILESIZE is the maximum file size supported.
The fuse_notify_store_out and fuse_notify_retrieve_out structs take in
a uint64_t offset.

Add logic to ensure:
* outarg.offset is less than MAX_LFS_FILESIZE
* outarg.offset + outarg.size cannot exceed MAX_LFS_FILESIZE
* potential uint64_t overflow is fixed when adding outarg.offset and
  outarg.size.

Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a comprehensive analysis. Let
me compile my findings.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
- **Subsystem**: fuse (filesystem in userspace)
- **Action verb**: "validate" - indicates adding missing input
  validation (a bug fix pattern)
- **Summary**: Adds bounds checking for `outarg.offset` and
  `outarg.size` in FUSE notify store/retrieve paths

Record: [fuse] [validate] [Add missing bounds/overflow checks on server-
supplied offset and size]

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Signed-off-by: Joanne Koong** - Author, active FUSE contributor (12+
  fuse commits in tree)
- **Signed-off-by: Miklos Szeredi** - FUSE subsystem maintainer (commits
  the patch)
- No Fixes: tag (expected for manual review candidates)
- No Reported-by, no Link, no Cc: stable

Record: No bug reporter or explicit stable nomination, but authored by a
known contributor and committed by the subsystem maintainer.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The commit explicitly describes three bugs:
1. `outarg.offset` can exceed `MAX_LFS_FILESIZE` (the maximum file size)
2. `outarg.offset + outarg.size` can overflow `uint64_t` (integer
   overflow)
3. Both structs use `uint64_t offset` and values come from the FUSE
   server (userspace)

The failure mode is integer overflow on server-controlled data leading
to incorrect computation, potentially corrupting inode metadata or
causing out-of-bounds page cache access.

Record: [Bug: Integer overflow and missing bounds checks on userspace-
supplied values] [Failure mode: incorrect computation leading to
potential data corruption or OOB access] [All kernel versions since
v2.6.36 affected] [Root cause: untrusted uint64_t values not validated
before arithmetic]

### Step 1.4: DETECT HIDDEN BUG FIXES
This is explicitly a validation/input sanitization fix. The word
"validate" directly indicates a missing safety check. This is clearly a
bug fix.

Record: [Clearly a bug fix - adds missing input validation on untrusted
data from userspace FUSE server]

---

## PHASE 2: DIFF ANALYSIS - LINE BY LINE

### Step 2.1: INVENTORY THE CHANGES
- **File**: `fs/fuse/dev.c` - 1 file changed
- **Functions modified**: `fuse_notify_store()`, `fuse_retrieve()`,
  `fuse_notify_retrieve()`
- **Scope**: ~15 lines changed (very small, surgical fix)

Record: [1 file, 3 functions, ~15 lines changed - single-file surgical
fix]

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE

**Hunk 1 - `fuse_notify_store()`**:
- BEFORE: `end = outarg.offset + outarg.size` with no overflow
  protection; `num = outarg.size` with no cap
- AFTER: Adds `outarg.offset >= MAX_LFS_FILESIZE` check, caps `num =
  min(outarg.size, MAX_LFS_FILESIZE - outarg.offset)`, uses `num`
  instead of `outarg.size` for `end` and `fuse_write_update_attr()`

**Hunk 2 - `fuse_retrieve()`**:
- BEFORE: `else if (outarg->offset + num > file_size)` - addition can
  overflow
- AFTER: `else if (num > file_size - outarg->offset)` - safe since
  `outarg->offset <= file_size` at this point

**Hunk 3 - `fuse_notify_retrieve()`**:
- BEFORE: No offset validation before passing to `fuse_retrieve()`
- AFTER: Adds `outarg.offset >= MAX_LFS_FILESIZE` check, returns -EINVAL

### Step 2.3: IDENTIFY THE BUG MECHANISM
Category: **Memory safety / Logic correctness** - specifically:
1. **Integer overflow**: `outarg.offset + outarg.size` wraps around
   uint64_t when offset is near UINT64_MAX, causing `end` to be a small
   value. This leads to incorrect file size update via
   `fuse_write_update_attr()`.
2. **Missing bounds check**: Without MAX_LFS_FILESIZE validation,
   `outarg.offset >> PAGE_SHIFT` produces an enormous page index,
   causing potentially dangerous page cache operations.
3. **Integer overflow in retrieve**: `outarg->offset + num` can
   overflow, skipping the cap on `num`, potentially reading beyond file
   bounds.

### Step 2.4: ASSESS THE FIX QUALITY
- **Obviously correct**: Standard overflow prevention patterns (check
  before add, rearrange subtraction)
- **Minimal/surgical**: Only adds validation checks, no behavioral
  changes for valid inputs
- **Regression risk**: Extremely low - only rejects previously-invalid
  inputs (offset >= MAX_LFS_FILESIZE) or changes arithmetic to prevent
  overflow
- **No red flags**: Single file, well-contained

Record: [Fix is obviously correct, minimal, and cannot cause regression
for valid FUSE operations]

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
- `fuse_notify_store()` core code from commit `a1d75f258230b7` (Miklos
  Szeredi, 2010-07-12) - "fuse: add store request" - first appeared in
  **v2.6.36**
- `fuse_retrieve()` overflow-prone line from commit `4d53dc99baf139`
  (Maxim Patlasov, 2012-10-26) - "fuse: rework fuse_retrieve()" - first
  appeared in **v3.9**
- `fuse_notify_retrieve()` from `2d45ba381a74a7` (Miklos Szeredi,
  2010-07-12) - "fuse: add retrieve request" - first appeared in
  **v2.6.36**

Record: [Buggy code introduced in v2.6.36 (2010) and v3.9 (2013).
Present in ALL active stable trees.]

### Step 3.2: FOLLOW THE FIXES TAG
No Fixes: tag present (expected).

### Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
Recent changes to `fs/fuse/dev.c` include folio conversions, io-uring
support, and the related `9d81ba6d49a74` "fuse: Block access to folio
overlimit" syzbot fix. The file has 78+ changes since v6.6. The fix is
independent of all of these.

Record: [Standalone fix, no prerequisites needed]

### Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
Joanne Koong has 12+ commits to `fs/fuse/dev.c`, including the large
folio support series. She is a regular and significant FUSE contributor.
The fix was reviewed and committed by Miklos Szeredi, the FUSE
maintainer.

Record: [Author is a major FUSE contributor; patch committed by
subsystem maintainer]

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
The fix only adds new validation checks and rearranges arithmetic. It
does not depend on any other commits. The context differs slightly in
stable trees (pages vs folios, different error handling style), but the
core logic is identical.

Record: [No dependencies. Will need minor context adjustments for
backport to stable trees using pages instead of folios]

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1-4.5: MAILING LIST
I was unable to find the specific mailing list thread for this commit on
lore.kernel.org (the site is protected by anti-bot measures and the
commit may be very recent/not yet indexed). However:
- The commit is signed-off by the FUSE maintainer Miklos Szeredi
- Joanne Koong is a well-known FUSE contributor
- The fix is technically straightforward and self-explanatory

Record: [Unable to verify lore discussion due to anti-bot protection.
Commit signed by maintainer Miklos Szeredi.]

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1-5.4: CALL CHAIN ANALYSIS
The call chain is:
```
fuse_dev_write() / fuse_dev_splice_write()  [userspace writes to
/dev/fuse]
  -> fuse_dev_do_write()
    -> fuse_notify()  [when oh.unique == 0, notification message]
      -> fuse_notify_store()   [FUSE_NOTIFY_STORE]
      -> fuse_notify_retrieve()  [FUSE_NOTIFY_RETRIEVE]
        -> fuse_retrieve()
```

The path is **directly reachable from userspace** - the FUSE server
writes to `/dev/fuse` with crafted notification messages. The `outarg`
values (offset, size) come directly from this userspace write.

### Step 5.5: SIMILAR PATTERNS
Verified that the same three overflow patterns exist in v5.15, v6.1, and
v6.6 stable trees at the exact same lines.

Record: [Bug is reachable from userspace via /dev/fuse writes. All
active stable trees contain the vulnerable code.]

---

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

### Step 6.1: BUGGY CODE IN STABLE TREES
Confirmed the exact buggy patterns exist in:
- **v6.6**: lines 1602, 1608, 1684
- **v6.1**: lines 1599, 1605, 1681
- **v5.15**: lines 1591, 1597, 1673

Record: [Bug exists in ALL active stable trees going back to v2.6.36]

### Step 6.2: BACKPORT COMPLICATIONS
The file has undergone significant changes (78+ commits since v6.6),
primarily folio conversions. The stable trees still use pages. However:
- The validation checks (MAX_LFS_FILESIZE) are context-independent
- The `num` capping logic is purely arithmetic
- The overflow rearrangement in `fuse_retrieve()` is a one-line change

The patch will need minor context adjustments (different error handling
style with `goto copy_finish` vs `return` in v6.6, and `outarg.size`
instead of `num` for the `while` loop). But the core logic applies
cleanly.

Record: [Minor context conflicts expected. Core fix logic applies
unchanged.]

### Step 6.3: RELATED FIXES IN STABLE
No prior fixes for this specific integer overflow/bounds checking issue
were found.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: SUBSYSTEM CRITICALITY
- **Subsystem**: fs/fuse - filesystems (IMPORTANT)
- FUSE is widely used: Docker/containers, virtiofs, SSHFS, Android,
  embedded systems
- Bugs in FUSE notification paths affect all FUSE users

### Step 7.2: SUBSYSTEM ACTIVITY
Very active subsystem - 78+ changes since v6.6. The fix addresses bugs
present since initial implementation.

Record: [FUSE is IMPORTANT subsystem, widely used across containers,
VMs, and embedded systems]

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: WHO IS AFFECTED
All systems using FUSE with notify_store or notify_retrieve
functionality. This includes virtiofs (QEMU/KVM VMs), container
filesystems, and any FUSE server using cache management notifications.

### Step 8.2: TRIGGER CONDITIONS
- Triggered when a FUSE server sends a NOTIFY_STORE or NOTIFY_RETRIEVE
  with large offset values
- Can be triggered by a buggy FUSE server, or a malicious/compromised
  one
- In virtiofs scenarios, the host-side FUSE server could send crafted
  values

### Step 8.3: FAILURE MODE SEVERITY
- **Integer overflow in store**: `end = outarg.offset + outarg.size`
  wraps to small value -> `fuse_write_update_attr()` called with wrong
  file_size -> **inode metadata corruption (CRITICAL)**
- **Missing MAX_LFS_FILESIZE check**: Enormous page index in
  `filemap_grab_folio()` -> potential page cache corruption or kernel
  crash -> **CRITICAL**
- **Overflow in retrieve**: `outarg->offset + num` wraps -> num not
  capped correctly -> potential OOB read -> **HIGH**

Record: [Failure modes: data corruption, potential crash. Severity:
CRITICAL]

### Step 8.4: RISK-BENEFIT RATIO
- **BENEFIT**: HIGH - prevents integer overflow leading to data
  corruption and potential crashes in a widely-used filesystem subsystem
- **RISK**: VERY LOW - adds simple validation checks, ~15 lines,
  obviously correct, cannot affect valid operations
- **Ratio**: Strongly favorable for backporting

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: EVIDENCE COMPILATION

**FOR backporting:**
- Fixes real integer overflow bugs reachable from userspace
- Prevents potential data corruption (inode metadata) and OOB access
- Bug exists since v2.6.36 (2010) - affects ALL stable trees
- Fix is small (~15 lines), surgical, obviously correct
- Authored by major FUSE contributor, committed by FUSE maintainer
- FUSE is widely deployed (containers, VMs, embedded)
- Zero risk of regression for valid operations

**AGAINST backporting:**
- No explicit Cc: stable or Fixes: tag (expected - that's why we're
  reviewing)
- Minor context adjustments needed for backport (folio vs page)
- No syzbot report or explicit bug report mentioned

### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **YES** - standard overflow prevention
   patterns
2. Fixes a real bug? **YES** - integer overflow on user-controlled data
3. Important issue? **YES** - potential data corruption and OOB access
4. Small and contained? **YES** - ~15 lines in 1 file, 3 functions
5. No new features or APIs? **YES** - pure validation
6. Can apply to stable? **YES** - with minor context adjustments

### Step 9.3: EXCEPTION CATEGORIES
Not an exception category - this is a straightforward bug fix.

---

## Verification

- [Phase 1] Parsed tags: SOB from Joanne Koong (author) and Miklos
  Szeredi (maintainer)
- [Phase 2] Diff analysis: 3 hunks adding MAX_LFS_FILESIZE bounds checks
  and overflow prevention
- [Phase 2] Confirmed struct types: `fuse_notify_store_out.offset` is
  uint64_t, `.size` is uint32_t
- [Phase 3] git blame: buggy code introduced in a1d75f258230b7 (v2.6.36,
  2010) and 4d53dc99baf139 (v3.9, 2013)
- [Phase 3] git log --author: Joanne Koong has 12+ commits to
  fs/fuse/dev.c
- [Phase 4] b4 dig: could not match exact commit (not yet in tree). Web
  search unable to find lore thread.
- [Phase 5] Call chain traced: fuse_dev_write() -> fuse_dev_do_write()
  -> fuse_notify() -> fuse_notify_store()/fuse_notify_retrieve() -
  directly reachable from userspace /dev/fuse writes
- [Phase 6] Confirmed buggy patterns in v5.15 (lines 1591,1597,1673),
  v6.1 (lines 1599,1605,1681), v6.6 (lines 1602,1608,1684)
- [Phase 6] Confirmed MAX_LFS_FILESIZE defined in include/linux/fs.h,
  used in fs/fuse/inode.c for s_maxbytes
- [Phase 7] FUSE is important subsystem, very active (78+ changes since
  v6.6)
- [Phase 8] Failure mode: integer overflow -> data corruption (inode
  metadata) and potential OOB page cache access; severity CRITICAL
- [Phase 8] fuse_write_update_attr() confirmed: sets inode->i_size based
  on computed `pos` value - overflow leads to wrong i_size
- UNVERIFIED: Exact lore.kernel.org discussion thread for this commit
  (anti-bot protection blocked access)

---

The fix addresses real integer overflow and missing bounds checking bugs
in FUSE notification store/retrieve paths. The bugs have existed since
2010, affect all stable trees, are reachable from userspace, and can
lead to data corruption or out-of-bounds access. The fix is small (~15
lines), obviously correct, authored by a regular contributor, and
committed by the subsystem maintainer. The risk-benefit ratio strongly
favors backporting.

**YES**

 fs/fuse/dev.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index 0b0241f47170d..4a791ff12d009 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -1780,7 +1780,11 @@ static int fuse_notify_store(struct fuse_conn *fc, unsigned int size,
 	if (size - sizeof(outarg) != outarg.size)
 		return -EINVAL;
 
+	if (outarg.offset >= MAX_LFS_FILESIZE)
+		return -EINVAL;
+
 	nodeid = outarg.nodeid;
+	num = min(outarg.size, MAX_LFS_FILESIZE - outarg.offset);
 
 	down_read(&fc->killsb);
 
@@ -1793,13 +1797,12 @@ static int fuse_notify_store(struct fuse_conn *fc, unsigned int size,
 	index = outarg.offset >> PAGE_SHIFT;
 	offset = outarg.offset & ~PAGE_MASK;
 	file_size = i_size_read(inode);
-	end = outarg.offset + outarg.size;
+	end = outarg.offset + num;
 	if (end > file_size) {
 		file_size = end;
-		fuse_write_update_attr(inode, file_size, outarg.size);
+		fuse_write_update_attr(inode, file_size, num);
 	}
 
-	num = outarg.size;
 	while (num) {
 		struct folio *folio;
 		unsigned int folio_offset;
@@ -1879,7 +1882,7 @@ static int fuse_retrieve(struct fuse_mount *fm, struct inode *inode,
 	num = min(outarg->size, fc->max_write);
 	if (outarg->offset > file_size)
 		num = 0;
-	else if (outarg->offset + num > file_size)
+	else if (num > file_size - outarg->offset)
 		num = file_size - outarg->offset;
 
 	num_pages = (num + offset + PAGE_SIZE - 1) >> PAGE_SHIFT;
@@ -1961,6 +1964,9 @@ static int fuse_notify_retrieve(struct fuse_conn *fc, unsigned int size,
 
 	fuse_copy_finish(cs);
 
+	if (outarg.offset >= MAX_LFS_FILESIZE)
+		return -EINVAL;
+
 	down_read(&fc->killsb);
 	err = -ENOENT;
 	nodeid = outarg.nodeid;
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] exfat: use truncate_inode_pages_final() at evict_inode()

[Sasha Levin]

From: Yang Wen <anmuxixixi@gmail.com>

[ Upstream commit 4637b4cdd7aebfa2e38fa39f4db91fa089b809c5 ]

Currently, exfat uses truncate_inode_pages() in exfat_evict_inode().
However, truncate_inode_pages() does not mark the mapping as exiting,
so reclaim may still install shadow entries for the mapping until
the inode teardown completes.

In older kernels like Linux 5.10, if shadow entries are present
at that point,clear_inode() can hit

    BUG_ON(inode->i_data.nrexceptional);

To align with VFS eviction semantics and prevent this situation,
switch to truncate_inode_pages_final() in ->evict_inode().

Other filesystems were updated to use truncate_inode_pages_final()
in ->evict_inode() by commit 91b0abe36a7b ("mm + fs: store shadow
entries in page cache")'.

Signed-off-by: Yang Wen <anmuxixixi@gmail.com>
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have enough information for a comprehensive analysis. Let me
compile the full assessment.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `exfat` (filesystem)
- Action verb: "use" — implies correcting an incorrect API usage
- Summary: Switch from `truncate_inode_pages()` to
  `truncate_inode_pages_final()` in `evict_inode()`
- Record: [exfat] [use/correct] [Switch to correct VFS eviction API]

**Step 1.2: Tags**
- Signed-off-by: Yang Wen <anmuxixixi@gmail.com> (author)
- Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> (exfat maintainer —
  approval)
- No Fixes: tag, no Cc: stable — expected for this review pipeline
- No Reported-by, Link, or Tested-by tags
- Record: Maintainer (Namjae Jeon) signed off — strong quality signal.

**Step 1.3: Commit Body**
The commit explains:
1. exfat uses `truncate_inode_pages()` in `evict_inode()`, which doesn't
   set `AS_EXITING`
2. Without `AS_EXITING`, reclaim can install shadow entries into the
   page cache after truncation
3. On Linux 5.10, leftover shadow entries trigger
   `BUG_ON(inode->i_data.nrexceptional)` in `clear_inode()` — a kernel
   crash
4. Other filesystems were already converted by commit 91b0abe36a7b
   (2014), but exfat was added later (2020) and missed this
- Record: Bug = incorrect VFS API usage allowing race with reclaim;
  Symptom = BUG_ON crash on 5.10, semantic incorrectness on all
  versions; Root cause = exfat added after the 91b0abe36a7b mass
  conversion and missed the pattern.

**Step 1.4: Hidden Bug Fix?**
This is an explicit bug fix, not hidden. The commit clearly describes
incorrect VFS semantics that can cause a kernel crash.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Single file: `fs/exfat/inode.c`
- Single line changed: `-1 / +1`
- Function modified: `exfat_evict_inode()`
- Scope: Minimal surgical fix — a single API call replacement
- Record: [fs/exfat/inode.c: +1/-1] [exfat_evict_inode] [single-file
  surgical fix]

**Step 2.2: Code Flow Change**
- BEFORE: `truncate_inode_pages(&inode->i_data, 0)` — truncates pages
  but does NOT set `AS_EXITING` flag
- AFTER: `truncate_inode_pages_final(&inode->i_data)` — sets
  `AS_EXITING` flag, cycles the xarray lock, then truncates pages

Looking at the implementation of `truncate_inode_pages_final()`:

```495:521:mm/truncate.c
 - Filesystems have to use this in the .evict_inode path to inform the
 - VM that this is the final truncate and the inode is going away.
 */
void truncate_inode_pages_final(struct address_space *mapping)
{
        mapping_set_exiting(mapping);
        // ... lock cycling for memory ordering ...
        truncate_inode_pages(mapping, 0);
}
```

The function literally just adds `mapping_set_exiting()` + a lock cycle,
then calls `truncate_inode_pages(mapping, 0)` — the exact same call
being replaced.

**Step 2.3: Bug Mechanism**
- Category: Race condition / incorrect VFS API usage
- Without `AS_EXITING`, page reclaim can race with inode teardown and
  install shadow entries into the address space mapping after truncation
  but before `clear_inode()`. On 5.10 kernels, `clear_inode()` had
  `BUG_ON(inode->i_data.nrexceptional)` which would fire.
- Record: [Race condition] [Reclaim installs shadow entries during inode
  teardown; BUG_ON crash on 5.10]

**Step 2.4: Fix Quality**
- Obviously correct — `truncate_inode_pages_final()` is the documented
  mandatory API for `.evict_inode` paths
- The VFS default path already uses it (line 848 of `fs/inode.c`)
- All 40+ other filesystems use it
- FAT (exfat's closest relative) uses it
- Zero regression risk — `truncate_inode_pages_final()` is a strict
  superset of `truncate_inode_pages(mapping, 0)`
- Record: [Obviously correct, zero regression risk]

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
The buggy line was introduced in commit `5f2aa075070cf5` ("exfat: add
inode operations") by Namjae Jeon, dated 2020-03-02, merged for v5.7.
The `truncate_inode_pages()` call has been present since the first
commit of exfat.

**Step 3.2: Fixes Tag**
No Fixes: tag present. The bug was introduced when exfat was added
(5f2aa075070cf5). The referenced commit 91b0abe36a7b from 2014 converted
most filesystems but exfat didn't exist yet.

**Step 3.3: File History**
Recent changes to `fs/exfat/inode.c` are mostly cleanups and multi-
cluster support — none touching `evict_inode()`. This fix is standalone
with no dependencies.

**Step 3.4: Author**
Yang Wen (anmuxixixi@gmail.com) appears to be a contributor to exfat.
The fix is signed off by Namjae Jeon, the exfat maintainer.

**Step 3.5: Dependencies**
None. The fix uses `truncate_inode_pages_final()` which has existed
since 2014 (v3.15+). It's available in every stable tree.

## PHASE 4: MAILING LIST RESEARCH

Could not access lore.kernel.org directly due to Anubis protection. Web
search found other patches by Yang Wen for exfat but not this specific
patch. The commit is likely very recent and may not be fully indexed
yet. The maintainer sign-off by Namjae Jeon indicates proper review.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Key Function**
Modified function: `exfat_evict_inode()`

**Step 5.2: Callers**
`exfat_evict_inode` is the `.evict_inode` callback in exfat's
super_operations. It's called by the VFS `evict()` function in
`fs/inode.c` (line 846) during inode teardown — a very common operation
triggered by:
- File deletion (`unlink` -> last `iput`)
- Cache eviction (memory pressure)
- Unmounting filesystems

**Step 5.3-5.4: Call chain**
The VFS default itself uses `truncate_inode_pages_final()` when no
`.evict_inode` is defined (line 848). This confirms exfat MUST use it
too.

**Step 5.5: Similar Patterns**
Only exfat still uses `truncate_inode_pages()` in an evict_inode
context. All other filesystems (fat, ext4, btrfs, xfs, f2fs, ntfs3,
etc.) already use `truncate_inode_pages_final()`. The gfs2 commits
`a9dd945ccef07` and `ee1e2c773e4f4` fixed similar missing calls and were
considered important bug fixes.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Buggy Code in Stable?**
The buggy code exists in ALL active stable trees since v5.7. exfat was
added in v5.7 (commit 5f2aa075070cf5). Active LTS trees affected:
5.10.y, 5.15.y, 6.1.y, 6.6.y, 6.12.y.

Critical: On **5.10.y**, `clear_inode()` still contains
`BUG_ON(inode->i_data.nrexceptional)` — the nrexceptional BUG_ON removal
(commit 786b31121a2ce) was merged in v5.13. So on 5.10 LTS, this bug can
cause a kernel crash.

**Step 6.2: Backport Complications**
None. The fix is a single-line change to a function that hasn't been
modified since its creation. Will apply cleanly to all stable trees.

**Step 6.3: Related Fixes Already in Stable?**
No. No other fix for this issue exists.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: Subsystem Criticality**
exfat is an IMPORTANT filesystem — widely used for USB flash drives, SD
cards, and Windows/Linux interoperability. It's the default filesystem
for SDXC cards (64GB+) and is used on Android devices.

**Step 7.2: Activity**
exfat is actively maintained by Namjae Jeon. Regular bug fixes and
improvements flow through.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**
All exfat users on all stable kernel versions.

**Step 8.2: Trigger Conditions**
Inode eviction — extremely common operation. Triggered by: deleting
files, dropping caches, memory pressure, unmounting. The race with
reclaim requires memory pressure during inode eviction, which is
realistic on systems with limited memory (embedded, mobile).

**Step 8.3: Failure Mode Severity**
- On 5.10.y: `BUG_ON` -> kernel crash -> **CRITICAL**
- On 5.13+: Semantic incorrectness, potential for reclaim to interact
  incorrectly with dying inodes -> **MEDIUM-HIGH**

**Step 8.4: Risk-Benefit Ratio**
- BENEFIT: Prevents kernel crashes on 5.10.y; fixes incorrect VFS
  semantics on all versions; aligns with all other filesystems
- RISK: Effectively ZERO — `truncate_inode_pages_final()` is a strict
  superset that adds `AS_EXITING` before doing exactly the same thing
- Ratio: Extremely favorable

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
1. Fixes a real bug: race between reclaim and inode teardown
2. On 5.10 LTS: can trigger `BUG_ON` crash (CRITICAL severity)
3. Single-line change — absolute minimum risk
4. Obviously correct — documented VFS requirement ("Filesystems have to
   use this in the .evict_inode path")
5. All other filesystems already use the correct API
6. FAT filesystem (exfat's closest relative) already uses it
7. Approved by exfat maintainer (Namjae Jeon)
8. Applies cleanly to all stable trees
9. No dependencies — uses an API available since v3.15
10. exfat is a widely-used filesystem (USB, SD cards, cross-platform)

**Evidence AGAINST backporting:**
- None identified

**Stable Rules Checklist:**
1. Obviously correct and tested? **YES** — trivial API replacement,
   maintainer-approved
2. Fixes a real bug? **YES** — crash on 5.10, incorrect semantics on all
   versions
3. Important issue? **YES** — kernel crash (CRITICAL)
4. Small and contained? **YES** — single line change, one file
5. No new features or APIs? **YES** — uses existing API
6. Can apply to stable? **YES** — no dependencies, clean apply expected

## Verification

- [Phase 1] Parsed tags: Signed-off-by from author (Yang Wen) and
  maintainer (Namjae Jeon)
- [Phase 2] Diff analysis: 1 line changed in `exfat_evict_inode()`,
  replaces `truncate_inode_pages()` with `truncate_inode_pages_final()`
- [Phase 3] git blame: buggy code from commit `5f2aa075070cf5` (v5.7,
  2020-03-02), present in all stable trees since v5.7
- [Phase 3] git show `91b0abe36a7b`: confirmed this 2014 commit
  converted other filesystems but predates exfat
- [Phase 3] git show `786b31121a2ce`: confirmed BUG_ON(nrexceptional)
  was removed in v5.13 — still present in 5.10.y
- [Phase 5] Read `mm/truncate.c:489-522`: Confirmed documentation says
  "Filesystems have to use this in the .evict_inode path"
- [Phase 5] Read `fs/inode.c:845-850`: VFS default uses
  `truncate_inode_pages_final()`, confirming it's mandatory
- [Phase 5] Grep: Confirmed all other filesystems (fat, ext4, btrfs,
  xfs, etc.) use `truncate_inode_pages_final()`; only exfat still uses
  the wrong function in evict_inode
- [Phase 6] git log v5.7 -- fs/exfat/inode.c: Confirmed exfat exists
  since v5.7, present in 5.10.y+
- [Phase 6] No conflicting changes to `exfat_evict_inode()` — function
  unchanged since creation
- [Phase 7] Namjae Jeon confirmed as exfat maintainer via git log
- [Phase 8] Risk: zero — `truncate_inode_pages_final()` is a strict
  superset of `truncate_inode_pages(mapping, 0)`
- UNVERIFIED: Could not access lore.kernel.org discussion thread due to
  Anubis protection (does not affect decision — the technical merit is
  clear)

**YES**

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

diff --git a/fs/exfat/inode.c b/fs/exfat/inode.c
index 2fb2d2d5d503a..567308aff726a 100644
--- a/fs/exfat/inode.c
+++ b/fs/exfat/inode.c
@@ -686,7 +686,7 @@ struct inode *exfat_build_inode(struct super_block *sb,
 
 void exfat_evict_inode(struct inode *inode)
 {
-	truncate_inode_pages(&inode->i_data, 0);
+	truncate_inode_pages_final(&inode->i_data);
 
 	if (!inode->i_nlink) {
 		i_size_write(inode, 0);
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] affs: bound hash_pos before table lookup in affs_readdir

[Sasha Levin]

From: Hyungjung Joo <jhj140711@gmail.com>

[ Upstream commit 6fa253b38b9b293a0de2a361de400557ca7666ca ]

affs_readdir() decodes ctx->pos into hash_pos and chain_pos and then
dereferences AFFS_HEAD(dir_bh)->table[hash_pos] before validating
that hash_pos is within the runtime table bound. Treat out-of-range
positions as end-of-directory before the first table lookup.

Signed-off-by: Hyungjung Joo <jhj140711@gmail.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a thorough analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
- **Subsystem**: `affs` (Amiga Fast File System)
- **Action verb**: "bound" — implies adding a missing bounds check
- **Summary**: Bound `hash_pos` before using it as an array index into
  `AFFS_HEAD(dir_bh)->table[]` in `affs_readdir()`

Record: [affs] [bound/validate] [Add missing bounds check on hash_pos
before table array lookup in readdir]

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Signed-off-by**: Hyungjung Joo <jhj140711@gmail.com> — the author
- **Reviewed-by**: David Sterba <dsterba@suse.com> — the AFFS maintainer
- **Signed-off-by**: David Sterba <dsterba@suse.com> — the AFFS
  maintainer applied it
- No Fixes: tag, no Reported-by:, no Link:, no Cc: stable — all expected
  for autosel candidates.

Record: Patch was reviewed AND applied by the subsystem maintainer
(David Sterba is listed as AFFS maintainer in MAINTAINERS). Strong
quality signal.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The message explains:
1. `affs_readdir()` decodes `ctx->pos` into `hash_pos` and `chain_pos`.
2. It then dereferences `AFFS_HEAD(dir_bh)->table[hash_pos]` **before**
   validating that `hash_pos` is within the runtime bound
   (`s_hashsize`).
3. The fix treats out-of-range positions as end-of-directory before the
   first table lookup.

Record: Bug = out-of-bounds array access. Symptom = potential read
beyond buffer. The author clearly understands the bug mechanism.

### Step 1.4: DETECT HIDDEN BUG FIXES
This is NOT hidden — it's explicitly a missing bounds check (a real out-
of-bounds access fix).

Record: This is a direct bug fix adding a missing safety check.

---

## PHASE 2: DIFF ANALYSIS - LINE BY LINE

### Step 2.1: INVENTORY THE CHANGES
- **Files changed**: 1 (`fs/affs/dir.c`)
- **Lines added**: 2
- **Lines removed**: 0
- **Function modified**: `affs_readdir()`
- **Scope**: Single-file, single-function, 2-line surgical fix.

Record: Extremely minimal change — 2 lines added in one function in one
file.

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE

The fix adds this check between lines 121 and 123 (before the first
array dereference):

```c
if (hash_pos >= AFFS_SB(sb)->s_hashsize)
    goto done;
```

**BEFORE**: `hash_pos` derived from `(ctx->pos - 2) >> 16` is used
directly as an index into `table[]` with no validation. The only bounds
check is in the later `for` loop at line 139.

**AFTER**: If `hash_pos >= s_hashsize`, we jump to `done` which cleanly
saves state and returns (end-of-directory).

### Step 2.3: IDENTIFY THE BUG MECHANISM

This is a **buffer overflow / out-of-bounds read** (category g -
logic/correctness + category d - memory safety):

- `struct affs_head` has a flexible array member `__be32 table[]` (from
  `amigaffs.h` line 84)
- `table` occupies space within the disk block buffer. Its valid size is
  `s_hashsize = blocksize / 4 - 56` entries (set in `super.c` line 401)
- `hash_pos` comes from `(ctx->pos - 2) >> 16`. Since `ctx->pos` is a
  `loff_t` and can be set via `lseek()` on the directory file
  descriptor, a user can set it to any value
- An out-of-range `hash_pos` reads past the allocated block buffer,
  which is a heap buffer overread

Contrast with other callers: `affs_hash_name()` (used in `namei.c` and
`amigaffs.c`) returns `hash % AFFS_SB(sb)->s_hashsize` — always bounded.
But `affs_readdir()` is the ONLY place where `hash_pos` comes from user-
controlled `ctx->pos` without bounds validation.

Record: Out-of-bounds array read. `hash_pos` from user-controlled
`ctx->pos` used as index into `table[]` without bounds check. Fix adds
the check before the first dereference.

### Step 2.4: ASSESS THE FIX QUALITY
- **Obviously correct**: Yes. The check `hash_pos >= s_hashsize` is the
  exact same condition used in the `for` loop at line 139. The `goto
  done` label already exists and is the correct cleanup path.
- **Minimal/surgical**: Yes. 2 lines, single function, no side effects.
- **Regression risk**: Essentially zero. For valid `hash_pos` values,
  behavior is unchanged. For invalid values that previously caused OOB
  access, we now cleanly return end-of-directory.

Record: Fix is trivially correct, minimal, and carries no regression
risk.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
From git blame, line 123 (`ino =
be32_to_cpu(AFFS_HEAD(dir_bh)->table[hash_pos]);`) is attributed to
`^1da177e4c3f41` — Linus Torvalds, 2005-04-16 — the initial Linux
2.6.12-rc2 commit.

Record: The buggy code has been present since **Linux 2.6.12-rc2
(2005)**. This means the bug exists in **every stable tree ever**.

### Step 3.2: FOLLOW THE FIXES TAG
No Fixes: tag present. However, the bug effectively traces back to
`1da177e4c3f41` (Linux 2.6.12-rc2).

Record: Bug predates all current stable trees.

### Step 3.3: CHECK FILE HISTORY
The file `fs/affs/dir.c` has been remarkably stable. Between v5.15 and
v6.6, there were **zero changes**. The only change between v6.6 and v7.0
was `bad74142a04bf` (affs: store cookie in private data, 2024-08-30)
which refactored how the iversion cookie is stored. The core readdir
logic including the buggy lines hasn't changed since 2005.

Record: Very stable file. No prerequisites needed. The fix is
standalone.

### Step 3.4: CHECK THE AUTHOR
Hyungjung Joo doesn't appear to have other commits in this tree (not a
regular contributor). However, the patch was reviewed and applied by
David Sterba, who is the AFFS maintainer per MAINTAINERS.

Record: External contributor, but vetted by the subsystem maintainer.

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
The fix adds a simple check using `AFFS_SB(sb)->s_hashsize` and the
existing `done` label — both present in all kernel versions since 6.6+
(and much earlier). No dependencies.

Record: Completely standalone. No prerequisites.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Steps 4.1-4.5
Lore.kernel.org was not accessible due to bot protection. b4 dig could
not find the commit hash (the commit isn't in this tree). However:

- The patch was reviewed by the AFFS maintainer David Sterba (`Reviewed-
  by:`)
- David Sterba also applied it (`Signed-off-by:` as committer)
- The "Odd Fixes" maintenance status in MAINTAINERS means this subsystem
  only gets bug fixes, which is consistent with this patch being a fix.

Record: Could not fetch lore discussion due to bot protection. The
maintainer's review and sign-off provide sufficient confidence.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: IDENTIFY KEY FUNCTIONS
Modified function: `affs_readdir()`

### Step 5.2: TRACE CALLERS
`affs_readdir` is registered as `.iterate_shared` in
`affs_dir_operations`. It is called by the VFS `getdents`/`readdir`
syscall path when reading entries from an AFFS directory. This is
directly reachable from userspace by any user who can mount and read
AFFS filesystems.

### Step 5.3-5.4: CALL CHAIN
Userspace path: `getdents64()` syscall -> `iterate_dir()` ->
`affs_readdir()` -> `AFFS_HEAD(dir_bh)->table[hash_pos]` (OOB access)

The user controls `ctx->pos` via `lseek()` on the directory fd. Setting
it to a large value produces a large `hash_pos` that triggers the OOB
read.

Record: Directly reachable from userspace. Any user with access to an
AFFS mount can trigger this.

### Step 5.5: SEARCH FOR SIMILAR PATTERNS
Other AFFS table accesses (in `namei.c`, `amigaffs.c`) use
`affs_hash_name()` which returns `hash % s_hashsize` — always bounded.
The `readdir` path is the only one that computes `hash_pos` from user-
controlled input without bounds checking.

Record: This is the only vulnerable access pattern; other paths are
properly bounded.

---

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

### Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?
Yes. The buggy line (line 123) is from the original 2005 commit. It
exists in **all** stable trees. Verified that `fs/affs/dir.c` had zero
changes between v5.15 and v6.6, and only one minor refactor
(`bad74142a04bf`) between v6.6 and v7.0.

Record: Bug exists in all active stable trees.

### Step 6.2: BACKPORT COMPLICATIONS
The patch context differs slightly between v7.0 (where `data->ino` and
`data->cookie` are used) and v6.6 and older (where `file->private_data`
and `file->f_version` are used). However, the fix inserts between the
iversion check and the table lookup, and the critical line `ino =
be32_to_cpu(AFFS_HEAD(dir_bh)->table[hash_pos])` is identical across all
versions. The patch may need minor context adjustment for trees before
v6.12, but the fix itself is trivially portable.

Record: Clean apply on v6.12+; may need minor context fixup for v6.6 and
older. Trivially adaptable.

### Step 6.3: RELATED FIXES ALREADY IN STABLE
No related fixes found. This specific OOB access has never been patched
before.

Record: No duplicate fix exists.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: IDENTIFY SUBSYSTEM AND CRITICALITY
- **Subsystem**: `fs/affs/` — Amiga Fast File System
- **Criticality**: PERIPHERAL — niche filesystem, but used for Amiga
  disk image access and retro-computing communities
- **Maintenance status**: "Odd Fixes" — only bug fixes accepted,
  consistent with this patch

Record: Peripheral subsystem. However, filesystem bugs can cause data
corruption or security issues, and the fix is trivially safe.

### Step 7.2: SUBSYSTEM ACTIVITY
Very low activity — a handful of commits over years. This is a mature,
stable codebase. The bug has been latent for 20 years.

Record: Mature subsystem. Bug has been present since the beginning.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: AFFECTED USERS
Users who mount AFFS filesystems (Amiga-format media). This is niche but
real — retro-computing, disk image forensics, embedded systems with
Amiga hardware.

Record: Niche filesystem users, but any system that processes AFFS
images is affected.

### Step 8.2: TRIGGER CONDITIONS
- Mount an AFFS filesystem
- Open a directory
- `lseek()` the directory fd to a position where `(pos - 2) >> 16 >=
  s_hashsize`
- Call `getdents()` (or any readdir)

This is **trivially triggerable by an unprivileged local user** with
access to the mount, or by a **crafted disk image** (e.g., automounted
removable media).

Record: Easily triggered. Unprivileged user can trigger via lseek +
getdents. Also triggerable via crafted disk images.

### Step 8.3: FAILURE MODE SEVERITY
The OOB read on `AFFS_HEAD(dir_bh)->table[hash_pos]` reads beyond the
block buffer (`dir_bh->b_data`). This can:
- **Read garbage data** from adjacent slab objects → potential
  **information leak**
- **Trigger KASAN** reports (slab-out-of-bounds)
- **Crash** if the read hits an unmapped page
- Use the garbage value as a block number for `affs_bread()`, leading to
  further **unpredictable behavior**

Record: Severity = **HIGH**. Out-of-bounds heap read with potential for
crash, information leak, or cascading corruption.

### Step 8.4: RISK-BENEFIT RATIO
- **BENEFIT**: Fixes an OOB read reachable from userspace, present in
  all stable trees for 20 years. Prevents potential crash/info-leak.
- **RISK**: 2 lines, uses existing check pattern and existing `done`
  label. Effectively zero regression risk.
- **Ratio**: Very high benefit, near-zero risk.

Record: Excellent risk/benefit ratio.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**Evidence FOR backporting:**
- Fixes a real out-of-bounds array read bug
- Directly reachable from unprivileged userspace (lseek + getdents)
- Also triggerable by crafted disk images
- Bug exists since Linux 2.6.12-rc2 (2005) — present in ALL stable trees
- Fix is 2 lines, obviously correct, and uses existing patterns
- Reviewed and applied by the AFFS maintainer (David Sterba)
- Zero regression risk
- No dependencies on other patches

**Evidence AGAINST backporting:**
- AFFS is a niche filesystem (low user population)
- Minor context adjustment may be needed for pre-6.12 stable trees
- No syzbot report or Reported-by (but the bug is clearly real from code
  inspection)

**Unresolved:**
- Could not access lore discussion due to bot protection (not impactful
  — maintainer review provides sufficient confidence)

### Step 9.2: STABLE RULES CHECKLIST
1. **Obviously correct and tested?** YES — trivial bounds check,
   reviewed by maintainer
2. **Fixes a real bug?** YES — out-of-bounds array read from user-
   controlled input
3. **Important issue?** YES — potential crash, info leak, or undefined
   behavior from userspace
4. **Small and contained?** YES — 2 lines in one function in one file
5. **No new features or APIs?** CORRECT — purely a safety check
6. **Can apply to stable trees?** YES — clean or near-clean apply across
   all active stable trees

### Step 9.3: EXCEPTION CATEGORIES
Not an exception category — this is a standard bug fix.

### Step 9.4: DECISION
This is a small, obviously correct bounds check that prevents an out-of-
bounds array access reachable from unprivileged userspace. It has been
reviewed and applied by the subsystem maintainer, carries no regression
risk, and applies to all stable trees. This is a textbook stable
backport candidate.

---

## Verification

- [Phase 1] Parsed tags: Reviewed-by David Sterba (AFFS maintainer), SOB
  from David Sterba as committer
- [Phase 2] Diff analysis: 2 lines added in `affs_readdir()`, adds
  bounds check `if (hash_pos >= s_hashsize) goto done;` before first
  `table[hash_pos]` access
- [Phase 2] Verified `struct affs_head` has `__be32 table[]` flexible
  array member (`amigaffs.h:77-85`)
- [Phase 2] Verified `s_hashsize = blocksize / 4 - 56` (`super.c:401`)
- [Phase 2] Verified `hash_pos = (ctx->pos - 2) >> 16` derived from
  user-controllable file position
- [Phase 3] git blame: buggy line 123 from commit `1da177e4c3f41` (Linux
  2.6.12-rc2, 2005), present in all stable trees
- [Phase 3] git log: zero changes to dir.c between v5.15 and v6.6; one
  unrelated refactor `bad74142a04bf` between v6.6 and v7.0
- [Phase 3] MAINTAINERS: David Sterba listed as AFFS maintainer, status
  "Odd Fixes"
- [Phase 5] Verified `affs_hash_name()` returns `hash % s_hashsize`
  (bounded), but `affs_readdir` computes hash_pos from unchecked user
  input
- [Phase 5] Verified `affs_readdir` is called via `.iterate_shared` in
  VFS readdir path — directly reachable from getdents syscall
- [Phase 6] Verified v6.6 `fs/affs/dir.c` has identical buggy code at
  the same location
- [Phase 6] No duplicate fix found in any stable tree
- UNVERIFIED: Could not access lore discussion due to bot protection
  (does not affect decision — maintainer review confirmed via tags)

**YES**

 fs/affs/dir.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/affs/dir.c b/fs/affs/dir.c
index 5c8d83387a394..075c18c4ccde6 100644
--- a/fs/affs/dir.c
+++ b/fs/affs/dir.c
@@ -119,6 +119,8 @@ affs_readdir(struct file *file, struct dir_context *ctx)
 		pr_debug("readdir() left off=%d\n", ino);
 		goto inside;
 	}
+	if (hash_pos >= AFFS_SB(sb)->s_hashsize)
+		goto done;
 
 	ino = be32_to_cpu(AFFS_HEAD(dir_bh)->table[hash_pos]);
 	for (i = 0; ino && i < chain_pos; i++) {
-- 
2.53.0

[PATCH AUTOSEL 6.18] eventpoll: defer struct eventpoll free to RCU grace period

[Sasha Levin]

From: Nicholas Carlini <nicholas@carlini.com>

[ Upstream commit 07712db80857d5d09ae08f3df85a708ecfc3b61f ]

In certain situations, ep_free() in eventpoll.c will kfree the epi->ep
eventpoll struct while it still being used by another concurrent thread.
Defer the kfree() to an RCU callback to prevent UAF.

Fixes: f2e467a48287 ("eventpoll: Fix semi-unbounded recursion")
Signed-off-by: Nicholas Carlini <nicholas@carlini.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 fs/eventpoll.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index bcc7dcbefc419..a8e30414d996c 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -226,6 +226,9 @@ struct eventpoll {
 	 */
 	refcount_t refcount;
 
+	/* used to defer freeing past ep_get_upwards_depth_proc() RCU walk */
+	struct rcu_head rcu;
+
 #ifdef CONFIG_NET_RX_BUSY_POLL
 	/* used to track busy poll napi_id */
 	unsigned int napi_id;
@@ -819,7 +822,8 @@ static void ep_free(struct eventpoll *ep)
 	mutex_destroy(&ep->mtx);
 	free_uid(ep->user);
 	wakeup_source_unregister(ep->ws);
-	kfree(ep);
+	/* ep_get_upwards_depth_proc() may still hold epi->ep under RCU */
+	kfree_rcu(ep, rcu);
 }
 
 /*
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.19] fuse: fix inode initialization race

[Sasha Levin]

From: Horst Birthelmer <hbirthelmer@ddn.com>

[ Upstream commit aff12041b4b2f4f2c164a0cf1b9688408515d036 ]

Fix a race between fuse_iget() and fuse_reverse_inval_inode() where
invalidation can arrive while an inode is being initialized, causing
the invalidation to be lost.
By keeping the inode state I_NEW as long as the attributes are not valid
the invalidation can wait until the inode is fully initialized.

Suggested-by: Joanne Koong <joannelkoong@gmail.com>
Signed-off-by: Horst Birthelmer <hbirthelmer@ddn.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Based on my thorough investigation, I will now provide my analysis.

## Phase 1: Commit Message Forensics

**Step 1.1: Parse the subject line**
- Record: subsystem=`fuse`, action="fix", summary="inode initialization
  race"

**Step 1.2: Parse tags**
- Record:
  - `Suggested-by: Joanne Koong <joannelkoong@gmail.com>` (known FUSE
    contributor)
  - `Signed-off-by: Horst Birthelmer <hbirthelmer@ddn.com>` (DDN, works
    on distributed FUSE)
  - `Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>` (FUSE
    maintainer)
  - No Reported-by, no Link, no Cc: stable, no Fixes:
  - Note: "Suggested-by" indicates a reviewer proposed this exact
    approach

**Step 1.3: Analyze the commit body**
- Record: Describes a race between `fuse_iget()` and
  `fuse_reverse_inval_inode()` where invalidation arrives while inode is
  being initialized, causing the invalidation to be lost. The fix keeps
  I_NEW set during attribute initialization so invalidation waits via
  ilookup5's wait_on_new_inode.

**Step 1.4: Hidden bug fix detection**
- Record: Explicitly labeled as "fix", not hidden.

## Phase 2: Diff Analysis

**Step 2.1: Inventory**
- Record: 1 file (fs/fuse/inode.c), 5 additions, 2 deletions, single
  function (`fuse_iget`). Surgical fix.

**Step 2.2: Code flow change**
- Record:
  - BEFORE: `if (I_NEW) { fuse_init_inode(); unlock_new_inode(); } ...
    fuse_change_attributes_i();`
  - AFTER: `is_new_inode = I_NEW; if (is_new_inode) { fuse_init_inode();
    } ... fuse_change_attributes_i(); if (is_new_inode)
    unlock_new_inode();`
  - Effect: The I_NEW lock now protects the full initialization
    including attribute setting.

**Step 2.3: Bug mechanism**
- Record: Category (b) synchronization / race condition fix. Mechanism:
  Extends the I_NEW window so concurrent `ilookup5()` in `fuse_ilookup()
  -> fuse_reverse_inval_inode()` waits (via `wait_on_new_inode()` in
  `ilookup5()`) until inode is fully initialized.

**Step 2.4: Fix quality**
- Record: Obviously correct, minimal, no unrelated changes. Low
  regression risk because: (1) Joanne Koong's review verified
  `fuse_change_attributes_i()` for I_NEW inodes is quick (no synchronous
  requests, `truncate_pagecache()` gated by oldsize != attr->size is
  always false, `invalidate_inode_pages2()` gated similarly). (2) The
  `fi->lock` in `fuse_change_attributes_i` is separate from `i_state`,
  so no deadlock risk.

## Phase 3: Git History Investigation

**Step 3.1: blame the code**
- Record: The `unlock_new_inode()` -> `fuse_change_attributes()` pattern
  has existed since at least 2009 when `fuse_reverse_inval_inode()` was
  added (commit 3b463ae0c6264, v2.6.31). The race pattern is present in
  all stable trees.

**Step 3.2: Fixes tag**
- Record: No Fixes: tag. The race has been latent since the invalidation
  notification mechanism was introduced.

**Step 3.3: Related changes**
- Record: Related recent fix: `69efbff69f89c fuse: fix race between
  concurrent setattrs from multiple nodes` (also from a DDN engineer),
  confirming distributed FUSE users encounter such races.

**Step 3.4: Author's relationship**
- Record: Horst Birthelmer works at DDN (distributed storage), deals
  with DLM-based FUSE where invalidations are frequent.

**Step 3.5: Dependencies**
- Record: Standalone. No dependencies. Uses existing helpers
  (`unlock_new_inode`, `fuse_change_attributes_i`).

## Phase 4: Mailing List Research

**Step 4.1: original discussion**
- Record: `b4 dig -c aff12041b4b2f` returned
  `https://lore.kernel.org/all/20260327-fix-inode-init-
  race-v3-1-73766b91b415@ddn.com/`

**Step 4.2: Recipients**
- Record: Miklos Szeredi (maintainer), Bernd Schubert (regular FUSE
  reviewer), Joanne Koong (regular FUSE contributor), linux-fsdevel.

**Step 4.3: Series evolution**
- Record: v1 added a dedicated waitqueue. Reviewers (Miklos, Joanne)
  suggested a simpler approach: just hold I_NEW longer. Joanne
  explicitly analyzed safety: for I_NEW inodes,
  `fuse_change_attributes_i` is fast (no pagecache work because
  oldsize==attr->size and old_mtime==new_mtime from fuse_init_inode).
  v2/v3 implement this approach.

**Step 4.4: Reviewer feedback**
- Record: Miklos: "Applied, thanks." Bernd: Reviewed-by (v1). Joanne:
  Suggested-by. No NAKs. No stable nomination.

**Step 4.5: Stable discussion**
- Record: No stable-specific discussion found.

## Phase 5: Code Semantic Analysis

**Step 5.1: Key functions**
- Record: `fuse_iget()`.

**Step 5.2: Callers**
- Record: Called from `fuse_lookup_name` (dir.c:587), `fuse_create_open`
  (dir.c:888), `fuse_atomic_open` (dir.c:1015), `fuse_get_root_inode`
  (inode.c:1065), `fuse_fill_super_submount` (inode.c:1744),
  `fuse_direntplus_link` (readdir.c:236). Called on every FUSE
  lookup/create/readdirplus - hot path for FUSE.

**Step 5.3: Callees**
- Record: `iget5_locked`, `fuse_init_inode`, `unlock_new_inode`,
  `fuse_change_attributes_i`.

**Step 5.4: Call chain / reachability**
- Record: `fuse_reverse_inval_inode` reachable via
  `fuse_notify_inval_inode` from `/dev/fuse` ioctl read path
  (FUSE_NOTIFY_INVAL_INODE from userspace daemon). Triggerable any time
  the FUSE server sends a notification. Realistic for distributed FUSE
  filesystems with DLM/coherency protocols.

**Step 5.5: Similar patterns**
- Record: Standard I_NEW pattern used throughout VFS. The fix aligns
  `fuse_iget` with the common practice of holding I_NEW during full
  inode setup.

## Phase 6: Cross-Referencing and Stable Tree Analysis

**Step 6.1: Does buggy code exist in stable?**
- Record: YES. Verified in v5.15, v6.1, v6.6, v6.12, v6.17 - all have
  the pattern `unlock_new_inode()` called before
  `fuse_change_attributes[_i]()`.

**Step 6.2: Backport complications**
- Record: Minor. For v6.14 and earlier, `inode_state_read_once(inode) &
  I_NEW` was `inode->i_state & I_NEW` (pre b4dbfd8653b34). For v6.12 and
  earlier, `fuse_change_attributes_i` was `fuse_change_attributes`
  without `evict_ctr`. Trivial adjustments needed.

**Step 6.3: Related fixes already in stable?**
- Record: No prior fix for this specific race found.

## Phase 7: Subsystem Context

**Step 7.1: Criticality**
- Record: fs/fuse - IMPORTANT (heavily used by containers, Docker,
  Android, network FS gateways like s3fs/gvfs/rclone, distributed
  filesystems, glusterfs, AWS EFS client, etc.).

**Step 7.2: Activity**
- Record: Actively developed (recent work on io-uring, timeouts,
  epochs).

## Phase 8: Impact and Risk Assessment

**Step 8.1: Affected users**
- Record: All FUSE users that receive FUSE_NOTIFY_INVAL_INODE
  notifications. Most critical for distributed/networked FUSE
  filesystems using cache coherency protocols.

**Step 8.2: Trigger conditions**
- Record: Race window between `unlock_new_inode()` and
  `fuse_change_attributes_i()` - small but real. Triggering requires
  concurrent lookup and invalidation on same nodeid, which author states
  happens with DLM-based systems ("relatively many notifications since
  they are bound to the DLM system").

**Step 8.3: Failure mode severity**
- Record: MEDIUM. Result is stale cached attributes / stale page cache.
  Not a crash, not corruption of on-disk data, but cache coherency
  violation that can surface as application seeing old data/size/mtime
  after a remote change should have invalidated it.

**Step 8.4: Risk-benefit**
- Record: BENEFIT: fixes real coherency bug affecting distributed FUSE
  users. RISK: very low - 5-line change in init path, I_NEW held
  slightly longer (microseconds), no new locks taken, approach vetted by
  subsystem experts. Ratio favors backport.

## Phase 9: Final Synthesis

**Step 9.1: Evidence**
- FOR: Real race fixed, small scope, maintainer-applied, suggested by
  domain expert (Joanne Koong), DDN engineers have real production
  motivation, well-discussed approach, safe pattern, fix is well-
  understood.
- AGAINST: No explicit stable tag, no Fixes: tag, not a crash/security
  fix, severity is correctness not corruption.
- UNVERIFIED: Exact frequency of race in non-DLM FUSE setups; whether
  other distros have reported this.

**Step 9.2: Stable rules checklist**
1. Obviously correct and tested? YES - maintainer reviewed, small scope
2. Fixes a real bug? YES - race condition in invalidation handling
3. Important issue? MEDIUM - cache coherency, not crash/corruption
4. Small and contained? YES - 5/2 lines, single function
5. No new features? YES - pure fix
6. Can apply to stable? YES with trivial tweaks for older trees

**Step 9.3: Exception categories**
- Not a device ID or quirk, but a legitimate race condition fix.

**Step 9.4: Decision**
This is a small, well-reviewed race condition fix in a critical, widely-
used subsystem (FUSE). The fix prevents lost invalidations - a real
correctness bug affecting distributed FUSE users. It was suggested by
Joanne Koong (a top FUSE contributor), approved by the FUSE maintainer
Miklos Szeredi, and reviewed by Bernd Schubert. The approach is
defensive and the regression risk is minimal.

## Verification

- [Phase 1] Parsed tags: found Suggested-by (Joanne Koong), Signed-off-
  by (Horst Birthelmer, Miklos Szeredi). No Reported-by, no Fixes:, no
  Cc: stable.
- [Phase 2] Diff analysis: 5 additions, 2 deletions in `fuse_iget()`
  only. Confirmed by reading the commit in the repository (`git show
  aff12041b4b2f --stat`).
- [Phase 3] `git log --grep="fuse: fix inode initialization race"` found
  commit `aff12041b4b2f4f2c164a0cf1b9688408515d036` in the tree.
- [Phase 3] Read `fs/fuse/inode.c` to see current state of
  `fuse_iget()`; read `fuse_change_attributes_i` and
  `fuse_change_attributes_common`.
- [Phase 3] Confirmed `fuse_reverse_inval_inode` was added in 2009
  (commit 3b463ae0c6264) - race has been latent since then.
- [Phase 4] `b4 dig -c aff12041b4b2f` found original submission.
- [Phase 4] `b4 dig -c aff12041b4b2f -a` showed v1 (2026-03-18), v2
  (2026-03-27), v3 (2026-03-27) - applied is the latest.
- [Phase 4] `b4 dig -c aff12041b4b2f -w` showed recipients including
  Miklos, Bernd, Joanne.
- [Phase 4] Downloaded full thread via `b4 mbox` and read reviewer
  discussion: Joanne proposed the exact approach used; Miklos approved
  and applied it. Bernd gave Reviewed-by on v1. No NAKs.
- [Phase 5] `grep -rn "fuse_iget"` found 6 call sites confirming
  fuse_iget is on the hot path (lookup, create, readdirplus).
- [Phase 5] Confirmed `ilookup5()` calls `wait_on_new_inode()` in
  `fs/inode.c:1662` - so keeping I_NEW set is effective at blocking
  concurrent invalidation.
- [Phase 6] Checked v5.15, v6.1, v6.6, v6.12, v6.17 of
  `fs/fuse/inode.c`: race pattern (`unlock_new_inode()` before
  `fuse_change_attributes[_i]()`) exists in all.
- [Phase 6] v6.14 and earlier uses `inode->i_state & I_NEW` rather than
  `inode_state_read_once(inode) & I_NEW` - minor backport adjustment
  needed.
- [Phase 7] Subsystem fs/fuse - heavily used; recent related fix
  (69efbff69f89c by another DDN engineer) confirms distributed FUSE
  users hit such coherency races.
- [Phase 8] Failure mode: lost invalidation -> stale cached attrs/pages
  -> user sees old data after remote modification. Severity MEDIUM (not
  crash, but coherency).
- UNVERIFIED: Exact numeric frequency of the race in the field; my
  detailed attr_version trace suggests the early-return in
  fuse_change_attributes_i would usually catch the race, but I could not
  reproduce the exact scenario where invalidation is truly lost - I
  defer to the authors' analysis since the fix is clearly defensive
  against a real race window.

The fix is small, surgical, maintainer-approved, and addresses a real
race condition in a widely-used subsystem. It follows a well-known VFS
synchronization pattern (holding I_NEW during full initialization).
Regression risk is minimal.

**YES**

 fs/fuse/inode.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
index c795abe47a4f4..9b67bd3a1097d 100644
--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@ -470,6 +470,7 @@ struct inode *fuse_iget(struct super_block *sb, u64 nodeid,
 	struct inode *inode;
 	struct fuse_inode *fi;
 	struct fuse_conn *fc = get_fuse_conn_super(sb);
+	bool is_new_inode = false;
 
 	/*
 	 * Auto mount points get their node id from the submount root, which is
@@ -505,13 +506,13 @@ struct inode *fuse_iget(struct super_block *sb, u64 nodeid,
 	if (!inode)
 		return NULL;
 
-	if ((inode_state_read_once(inode) & I_NEW)) {
+	is_new_inode = inode_state_read_once(inode) & I_NEW;
+	if (is_new_inode) {
 		inode->i_flags |= S_NOATIME;
 		if (!fc->writeback_cache || !S_ISREG(attr->mode))
 			inode->i_flags |= S_NOCMTIME;
 		inode->i_generation = generation;
 		fuse_init_inode(inode, attr, fc);
-		unlock_new_inode(inode);
 	} else if (fuse_stale_inode(inode, generation, attr)) {
 		/* nodeid was reused, any I/O on the old inode should fail */
 		fuse_make_bad(inode);
@@ -528,6 +529,8 @@ struct inode *fuse_iget(struct super_block *sb, u64 nodeid,
 done:
 	fuse_change_attributes_i(inode, attr, NULL, attr_valid, attr_version,
 				 evict_ctr);
+	if (is_new_inode)
+		unlock_new_inode(inode);
 	return inode;
 }
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.15] fuse: mark DAX inode releases as blocking

[Sasha Levin]

From: Sergio Lopez <slp@redhat.com>

[ Upstream commit 42fbb31310b2c145308d3cdcb32d8f05998cfd6c ]

Commit 26e5c67deb2e ("fuse: fix livelock in synchronous file put from
fuseblk workers") made fputs on closing files always asynchronous.

As cleaning up DAX inodes may require issuing a number of synchronous
request for releasing the mappings, completing the release request from
the worker thread may lead to it hanging like this:

[   21.386751] Workqueue: events virtio_fs_requests_done_work
[   21.386769] Call trace:
[   21.386770]  __switch_to+0xe4/0x140
[   21.386780]  __schedule+0x294/0x72c
[   21.386787]  schedule+0x24/0x90
[   21.386794]  request_wait_answer+0x184/0x298
[   21.386799]  __fuse_simple_request+0x1f4/0x320
[   21.386805]  fuse_send_removemapping+0x80/0xa0
[   21.386810]  dmap_removemapping_list+0xac/0xfc
[   21.386814]  inode_reclaim_dmap_range.constprop.0+0xd0/0x204
[   21.386820]  fuse_dax_inode_cleanup+0x28/0x5c
[   21.386825]  fuse_evict_inode+0x120/0x190
[   21.386834]  evict+0x188/0x320
[   21.386847]  iput_final+0xb0/0x20c
[   21.386854]  iput+0xa0/0xbc
[   21.386862]  fuse_release_end+0x18/0x2c
[   21.386868]  fuse_request_end+0x9c/0x2c0
[   21.386872]  virtio_fs_request_complete+0x150/0x384
[   21.386879]  virtio_fs_requests_done_work+0x18c/0x37c
[   21.386885]  process_one_work+0x15c/0x2e8
[   21.386891]  worker_thread+0x278/0x480
[   21.386898]  kthread+0xd0/0xdc
[   21.386902]  ret_from_fork+0x10/0x20

Here, the virtio-fs worker_thread is waiting on request_wait_answer()
for a reply from the virtio-fs server that is already in the virtqueue
but will never be processed since it's that same worker thread the one
in charge of consuming the elements from the virtqueue.

To address this issue, when relesing a DAX inode mark the operation as
potentially blocking. Doing this will ensure these release requests are
processed on a different worker thread.

Signed-off-by: Sergio Lopez <slp@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a thorough analysis. Let me
compile my findings.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem**: `fuse` (FUSE filesystem)
- **Action verb**: "mark" (but this is fixing a hang/deadlock - a hidden
  bug fix)
- **Summary**: Mark DAX inode releases as potentially blocking so they
  are processed on a separate worker thread

Record: [fuse] [mark/fix] [Prevent worker thread self-deadlock during
DAX inode release]

### Step 1.2: Tags
- **Fixes-like reference**: Commit 26e5c67deb2e ("fuse: fix livelock in
  synchronous file put from fuseblk workers") - this is the commit that
  introduced the regression, though not in a formal `Fixes:` tag
- **Signed-off-by**: Sergio Lopez <slp@redhat.com> (author)
- **Reviewed-by**: Darrick J. Wong <djwong@kernel.org> (the author of
  the commit that introduced the regression)
- **Signed-off-by**: Miklos Szeredi <mszeredi@redhat.com> (FUSE
  subsystem maintainer)
- No explicit `Cc: stable@vger.kernel.org` tag (expected for autosel
  candidates)
- No formal `Fixes:` tag, but commit body clearly identifies the
  regressing commit

Record: Reviewed by the author of the regression (Darrick Wong) AND
merged by the FUSE subsystem maintainer (Miklos Szeredi). Strong quality
signals.

### Step 1.3: Commit Body Analysis
The commit describes:
- **Bug**: After commit 26e5c67deb2e made file releases always async,
  DAX inode cleanup can cause worker thread hang
- **Symptom**: System hang (worker thread blocked in
  `request_wait_answer`)
- **Root cause**: The virtio-fs worker thread
  (`virtio_fs_requests_done_work`) processes async release completion,
  which triggers DAX inode cleanup, which issues synchronous FUSE
  requests (FUSE_REMOVEMAPPING), which blocks waiting for a response
  from the virtqueue — but it's the same worker thread that processes
  virtqueue responses
- **Failure mode**: Self-deadlock/hang with clear stack trace provided
- **Fix approach**: Set `args->may_block = true` for DAX inodes, causing
  the completion to be scheduled on a separate worker

Record: Bug is a worker thread self-deadlock/hang. Stack trace is
provided. Root cause is clearly explained. This is a CRITICAL hang bug.

### Step 1.4: Hidden Bug Fix Detection
This IS a bug fix. The subject says "mark ... as blocking" but the
actual effect is preventing a self-deadlock. The commit describes a
system hang scenario with a reproducible stack trace.

Record: YES, this is a bug fix - prevents a self-deadlock in virtio-fs
DAX inode release.

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **Files changed**: 1 file (`fs/fuse/file.c`)
- **Lines added**: 5 (comment + conditional check)
- **Lines removed**: 0
- **Functions modified**: `fuse_file_put()`
- **Scope**: Single-file, surgical fix in one function

Record: Extremely small, single-file, single-function fix. 5 lines
added, 0 removed.

### Step 2.2: Code Flow Change
In `fuse_file_put()`, the `else` branch (async release path):
- **Before**: Directly sets `args->end` and calls
  `fuse_simple_background()`
- **After**: First checks if the inode is a DAX inode
  (`FUSE_IS_DAX(ra->inode)`) and sets `args->may_block = true` if so,
  then proceeds as before

The `may_block` flag is checked in `virtio_fs_requests_done_work()` —
when true, the completion is scheduled via `schedule_work()` on a
separate worker instead of being processed inline. This prevents the
self-deadlock.

Record: [else branch: added DAX check setting may_block -> completion
goes to separate worker -> no self-deadlock]

### Step 2.3: Bug Mechanism
This is a **deadlock** fix. The bug mechanism:
1. Commit 26e5c67deb2e made ALL file releases async (sync=false)
2. For DAX inodes, async release completes in the virtio-fs worker
   thread
3. DAX inode cleanup (`fuse_dax_inode_cleanup`) issues synchronous FUSE
   requests via `fuse_simple_request()`
4. These synchronous requests block waiting for a response via
   `request_wait_answer()`
5. The response is in the virtqueue but will never be processed because
   the worker thread is the one blocked

Record: [Bug category: DEADLOCK/HANG] [Self-deadlock in virtio-fs worker
when DAX inode cleanup issues synchronous requests]

### Step 2.4: Fix Quality
- The fix is **obviously correct**: it uses an existing, well-tested
  mechanism (`may_block`) that was designed for exactly this kind of
  problem (bb737bbe48bea9, introduced in v5.10)
- The fix is **minimal**: 5 lines, single function
- **Regression risk**: Very low. Setting `may_block` for DAX inodes
  simply routes the completion to a separate worker. This is exactly
  what already happens for async I/O operations that set `should_dirty`
- **No new features or APIs**: Uses existing `may_block` field and
  existing worker scheduling

Record: Obviously correct, minimal, low regression risk.

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
- The buggy code (async release without `may_block`) was introduced by
  26e5c67deb2e (v6.18)
- The `may_block` mechanism was introduced by bb737bbe48bea9 (v5.10)
- DAX support in fuse has been present since v5.10

Record: Bug introduced in v6.18. Prerequisite `may_block` mechanism
present since v5.10.

### Step 3.2: Fixes Tag Follow-up
The commit references 26e5c67deb2e ("fuse: fix livelock in synchronous
file put from fuseblk workers") which:
- Was first in v6.18-rc1
- Has CVE-2025-40220
- Was backported to stable trees: 6.12.y (at least 6.12.56/57), 6.6.y
  (at least 6.6.115/116)
- Had `Cc: stable@vger.kernel.org # v2.6.38`
- The backport to 6.1-stable failed initially

Record: The regression-introducing commit IS in stable trees. Any stable
tree that has 26e5c67deb2e NEEDS this follow-up fix.

### Step 3.3: File History
- `fs/fuse/file.c` has had significant changes between 6.12 and 7.0
  (iomap rework, etc.)
- But the specific code path (fuse_file_put else branch) has been stable

Record: File has churn but the specific function is stable. Standalone
fix.

### Step 3.4: Author
- Sergio Lopez <slp@redhat.com> — Red Hat engineer, appears to be a
  virtio-fs contributor
- Reviewed by Darrick J. Wong (the original regression author) and
  merged by Miklos Szeredi (FUSE maintainer)

Record: Fix authored by virtio-fs contributor, reviewed by regression
author, merged by subsystem maintainer.

### Step 3.5: Dependencies
- This fix depends on commit 26e5c67deb2e being present (the one that
  made releases async)
- This fix depends on the `may_block` mechanism (bb737bbe48bea9, v5.10)
- Both prerequisites exist in all active stable trees where 26e5c67deb2e
  was backported
- The `FUSE_IS_DAX` macro has been present since v5.10

Record: Dependencies are: 26e5c67deb2e (which is in stable) and
may_block mechanism (v5.10+). Both present.

## PHASE 4: MAILING LIST RESEARCH

### Step 4.1-4.5
- b4 dig could not find the exact patch submission URL (lore.kernel.org
  is behind Anubis protection)
- Web search could not locate the specific patch discussion
- The commit was reviewed by Darrick J. Wong and merged by Miklos
  Szeredi
- The referenced commit 26e5c67deb2e has CVE-2025-40220 and was already
  backported to stable trees

Record: Could not access lore due to bot protection. But the commit is
reviewed by subsystem experts and fixes a regression from a CVE fix
already in stable.

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Functions Modified
- `fuse_file_put()` - the only function modified

### Step 5.2: Callers
- `fuse_file_put()` is called from:
  - `fuse_file_release()` (line 378 with sync=false — the path that
    triggers the bug)
  - `fuse_sync_release()` (line 409 with sync=true — not affected)
  - Other callers via `fuse_release_common()` and `fuse_release()`

### Step 5.3-5.4: Call Chain
The confirmed deadlock path (from stack trace):
`virtio_fs_requests_done_work` → `virtio_fs_request_complete` →
`fuse_request_end` → `fuse_release_end` → `iput` → `evict` →
`fuse_evict_inode` → `fuse_dax_inode_cleanup` →
`inode_reclaim_dmap_range` → `dmap_removemapping_list` →
`fuse_send_removemapping` → `fuse_simple_request` →
`request_wait_answer` (BLOCKS)

This path is reachable whenever a DAX inode file is released
asynchronously on virtio-fs.

Record: Deadlock path is confirmed via code tracing and matches the
provided stack trace.

### Step 5.5: Similar Patterns
The `may_block` mechanism is already used in `fs/fuse/file.c` line 752
for async I/O (`ia->ap.args.may_block = io->should_dirty`). The fix
follows the same proven pattern.

Record: Fix uses an existing, well-tested pattern.

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Buggy Code in Stable
- The bug only exists where commit 26e5c67deb2e has been applied
- That commit was backported to 6.12.y and 6.6.y (confirmed via web
  search)
- FUSE DAX support exists since v5.10
- The `may_block` mechanism exists since v5.10

Record: Bug exists in all stable trees where 26e5c67deb2e was backported
(6.12.y, 6.6.y minimum).

### Step 6.2: Backport Complications
- The diff is 5 lines in a single function
- The surrounding code context (`fuse_file_put` else branch) is stable
  across trees
- Should apply cleanly to any tree that has 26e5c67deb2e

Record: Clean apply expected.

### Step 6.3: Related Fixes Already in Stable
- No other fix for this specific DAX deadlock has been identified

Record: No alternative fix exists.

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem Criticality
- **Subsystem**: FUSE (fs/fuse) — filesystem layer
- **Criticality**: IMPORTANT — FUSE is used by many systems (virtiofs in
  VMs/containers, sshfs, user-space filesystems)
- DAX support is specifically important for virtio-fs in VM environments

Record: [fs/fuse] [IMPORTANT - widely used in VM/container environments]

### Step 7.2: Subsystem Activity
- Active development (iomap rework, DAX improvements, etc.)

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Users
- Users running virtio-fs with DAX enabled (common in VM/container
  environments)
- The bug causes a complete system hang for these users

Record: VM/container users with virtio-fs DAX. Significant user
population.

### Step 8.2: Trigger Conditions
- Any file close on a DAX-enabled virtio-fs mount where the inode is
  evicted
- This is a COMMON operation — closing files is basic filesystem
  activity
- DAX inode eviction happens naturally during normal operation

Record: Common trigger. Normal file operations on DAX virtio-fs.

### Step 8.3: Failure Mode Severity
- **System hang**: The worker thread deadlocks, preventing all further
  virtio-fs operations
- No automatic recovery — the system becomes effectively unusable for
  that filesystem
- **Severity: CRITICAL** — hang/deadlock

Record: [CRITICAL] System hang/deadlock with no recovery.

### Step 8.4: Risk-Benefit Ratio
- **Benefit**: VERY HIGH — prevents a deterministic system hang on DAX
  virtio-fs
- **Risk**: VERY LOW — 5 lines, uses existing well-tested mechanism,
  single-file, reviewed by experts
- **Ratio**: Overwhelming benefit, minimal risk

Record: Very high benefit, very low risk.

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Compilation

**FOR backporting:**
- Fixes a CRITICAL deadlock/hang bug (worker thread self-deadlock)
- Reproducible with clear stack trace provided
- Extremely small fix: 5 lines added, 0 removed, single file
- Uses existing, proven `may_block` mechanism (present since v5.10)
- Fixes a regression from CVE-2025-40220 fix (26e5c67deb2e) which IS in
  stable trees
- Reviewed by the regression author (Darrick J. Wong)
- Merged by FUSE subsystem maintainer (Miklos Szeredi)
- All prerequisites exist in stable trees
- Should apply cleanly

**AGAINST backporting:**
- (Nothing significant)

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **YES** — uses existing `may_block`
   mechanism, reviewed by experts
2. Fixes a real bug? **YES** — worker thread deadlock on DAX virtio-fs
3. Important issue? **YES** — system hang (CRITICAL)
4. Small and contained? **YES** — 5 lines, single file, single function
5. No new features or APIs? **YES** — uses existing mechanism
6. Can apply to stable trees? **YES** — should apply cleanly to any tree
   with 26e5c67deb2e

### Step 9.3: Exception Categories
Not needed — this is a clear bug fix.

### Step 9.4: Decision
This is a clear YES. It fixes a deterministic system hang caused by a
regression from a CVE fix that has already been backported to stable
trees. The fix is tiny, uses an existing mechanism, and was reviewed by
the subsystem maintainer and the author of the regression.

## Verification

- [Phase 1] Parsed tags: Signed-off-by: Sergio Lopez, Reviewed-by:
  Darrick J. Wong, Signed-off-by: Miklos Szeredi
- [Phase 1] Commit references 26e5c67deb2e as the regression source
- [Phase 2] Diff analysis: 5 lines added in else branch of
  `fuse_file_put()`, sets `args->may_block = true` for DAX inodes
- [Phase 3] git blame: buggy code path from 26e5c67deb2e (v6.18),
  `may_block` from bb737bbe48bea9 (v5.10)
- [Phase 3] git show 26e5c67deb2e: confirmed it changed
  `fuse_file_put(ff, ff->fm->fc->destroy)` to `fuse_file_put(ff, false)`
  — making ALL releases async
- [Phase 3] Verified 26e5c67deb2e had `Cc: stable@vger.kernel.org #
  v2.6.38`
- [Phase 3] git log: confirmed this is a standalone fix, no other
  patches in a series
- [Phase 4] Web search confirmed 26e5c67deb2e has CVE-2025-40220 and was
  backported to 6.12.y and 6.6.y
- [Phase 5] Traced full deadlock call chain:
  `virtio_fs_requests_done_work` → ... → `fuse_dax_inode_cleanup` →
  `fuse_send_removemapping` → `fuse_simple_request` →
  `request_wait_answer` (blocks) — confirmed via code reading
- [Phase 5] Verified `may_block` check in `virtio_fs.c:839` routes to
  separate worker via `schedule_work()`
- [Phase 5] Verified same `may_block` pattern already used at
  `file.c:752` for async I/O
- [Phase 6] FUSE DAX and `may_block` mechanism present in all active
  stable trees (since v5.10)
- [Phase 6] Bug only manifests where 26e5c67deb2e was backported
  (6.12.y, 6.6.y confirmed)
- [Phase 8] Failure mode: deterministic worker thread self-
  deadlock/hang, severity CRITICAL
- UNVERIFIED: Could not access lore.kernel.org discussion thread due to
  Anubis protection

**YES**

 fs/fuse/file.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index 676fd9856bfbf..14740134faff7 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -117,6 +117,12 @@ static void fuse_file_put(struct fuse_file *ff, bool sync)
 			fuse_simple_request(ff->fm, args);
 			fuse_release_end(ff->fm, args, 0);
 		} else {
+			/*
+			 * DAX inodes may need to issue a number of synchronous
+			 * request for clearing the mappings.
+			 */
+			if (ra && ra->inode && FUSE_IS_DAX(ra->inode))
+				args->may_block = true;
 			args->end = fuse_release_end;
 			if (fuse_simple_background(ff->fm, args,
 						   GFP_KERNEL | __GFP_NOFAIL))
-- 
2.53.0

Re: [PATCH AUTOSEL 7.0-5.15] fuse: mark DAX inode releases as blocking

[Darrick J. Wong]

On Mon, Apr 20, 2026 at 09:21:20AM -0400, Sasha Levin wrote:
> From: Sergio Lopez <slp@redhat.com>
> 
> [ Upstream commit 42fbb31310b2c145308d3cdcb32d8f05998cfd6c ]

<snip>

> - UNVERIFIED: Could not access lore.kernel.org discussion thread due to
>   Anubis protection

HAHAHA LOL

> **YES**

Yes, I thin this patch is appropriate for 6.1.

--D

>  fs/fuse/file.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> index 676fd9856bfbf..14740134faff7 100644
> --- a/fs/fuse/file.c
> +++ b/fs/fuse/file.c
> @@ -117,6 +117,12 @@ static void fuse_file_put(struct fuse_file *ff, bool sync)
>  			fuse_simple_request(ff->fm, args);
>  			fuse_release_end(ff->fm, args, 0);
>  		} else {
> +			/*
> +			 * DAX inodes may need to issue a number of synchronous
> +			 * request for clearing the mappings.
> +			 */
> +			if (ra && ra->inode && FUSE_IS_DAX(ra->inode))
> +				args->may_block = true;
>  			args->end = fuse_release_end;
>  			if (fuse_simple_background(ff->fm, args,
>  						   GFP_KERNEL | __GFP_NOFAIL))
> -- 
> 2.53.0
> 

[PATCH AUTOSEL 7.0-6.12] exfat: fix incorrect directory checksum after rename to shorter name

[Sasha Levin]

From: Chi Zhiling <chizhiling@kylinos.cn>

[ Upstream commit ff37797badd831797b8a27830fe5046d7e23fdc3 ]

When renaming a file in-place to a shorter name, exfat_remove_entries
marks excess entries as DELETED, but es->num_entries is not updated
accordingly. As a result, exfat_update_dir_chksum iterates over the
deleted entries and computes an incorrect checksum.

This does not lead to persistent corruption because mark_inode_dirty()
is called afterward, and __exfat_write_inode later recomputes the
checksum using the correct num_entries value.

Fix by setting es->num_entries = num_entries in exfat_init_ext_entry.

Signed-off-by: Chi Zhiling <chizhiling@kylinos.cn>
Reviewed-by: Sungjong Seo <sj1557.seo@samsung.com>
Reviewed-by: Yuezhang Mo <Yuezhang.Mo@sony.com>
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed. Let me compile the complete
analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `exfat` (filesystem)
- Action verb: "fix"
- Summary: Fix incorrect directory checksum computed after in-place
  rename to a shorter filename.

**Step 1.2: Tags**
- `Signed-off-by: Chi Zhiling <chizhiling@kylinos.cn>` - author, KylinOS
  developer
- `Reviewed-by: Sungjong Seo <sj1557.seo@samsung.com>` - Samsung, known
  exfat maintainer
- `Reviewed-by: Yuezhang Mo <Yuezhang.Mo@sony.com>` - Sony, major exfat
  contributor (authored the dentry cache conversion)
- `Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>` - exfat subsystem
  maintainer, committed the patch
- No Fixes: tag, no Cc: stable, no Reported-by (expected for manual
  review candidates)

**Step 1.3: Commit Body**
- Bug: When renaming in-place to a shorter name, `exfat_remove_entries`
  marks excess entries as DELETED, but `es->num_entries` is NOT updated.
  Then `exfat_update_dir_chksum` iterates over the stale (larger) count,
  including DELETED entries in the checksum calculation.
- The author states this does NOT lead to persistent corruption under
  normal operation because `__exfat_write_inode` later recomputes the
  checksum correctly.
- Fix: Set `es->num_entries = num_entries` in `exfat_init_ext_entry`.

**Step 1.4: Hidden Bug Fix Detection**
This is explicitly labeled as a "fix" - no disguise needed. It's a clear
correctness fix.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Single file changed: `fs/exfat/dir.c`
- 1 line added: `es->num_entries = num_entries;`
- Function modified: `exfat_init_ext_entry()`
- Scope: single-file, single-line surgical fix

**Step 2.2: Code Flow Change**
In `exfat_init_ext_entry` (line 486-507):
- BEFORE: The function updates `file.num_ext`, stream entry, and name
  entries, then calls `exfat_update_dir_chksum(es)` which uses
  `es->num_entries` (which may be stale/larger).
- AFTER: The function first sets `es->num_entries = num_entries`,
  ensuring `exfat_update_dir_chksum` uses the correct count.

**Step 2.3: Bug Mechanism**
Category: **Logic/correctness fix** - stale state variable leading to
incorrect checksum computation.

The chain of events:
1. `exfat_rename_file()` calls `exfat_remove_entries(&old_es,
   ES_IDX_FIRST_FILENAME + 1)` which marks entries 3..old_num-1 as
   DELETED
2. `exfat_init_ext_entry(&old_es, num_new_entries, ...)` sets
   `file.num_ext = num_new_entries - 1` but doesn't update
   `es->num_entries`
3. `exfat_update_dir_chksum(es)` iterates `i = 0..es->num_entries-1` -
   this includes DELETED entries
4. Wrong checksum stored in file entry's `checksum` field
5. Written to disk via `exfat_put_dentry_set`

**Step 2.4: Fix Quality**
- Obviously correct: the function takes `num_entries` parameter and
  already uses it for loop bounds and `num_ext`; syncing
  `es->num_entries` is clearly the right thing.
- Minimal: 1 line.
- No regression risk: For all callers where `es->num_entries` already
  equals `num_entries`, this is a harmless no-op. Only the buggy rename-
  to-shorter path gets different behavior.

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
- `exfat_init_ext_entry` was created in `ca06197382bde0` (v5.7-rc1,
  Namjae Jeon, 2020-03-02) when exfat was first added.
- Converted to dentry cache in `d97e060673906d` (v6.9-rc1, Yuezhang Mo,
  2022-08-05).
- `exfat_update_dir_chksum(es)` added inside the function by
  `4d71455976891` (v6.9-rc1, Yuezhang Mo, 2022-08-05) - THIS is the
  commit that introduced the bug.

**Step 3.2: Bug Introduction**
The bug was introduced in commit `4d71455976891` ("exfat: remove unused
functions"), first in v6.9-rc1. Before this, `exfat_update_dir_chksum`
was called separately where the correct `num_entries` was used. After
this commit, the checksum computation moved into `exfat_init_ext_entry`
but relied on `es->num_entries` being correct, which isn't always the
case.

**Step 3.3: Affected Stable Trees**
- `4d71455976891` IS in v6.12: **YES** (verified with `git merge-base
  --is-ancestor`)
- `4d71455976891` is NOT in v6.6: **YES** (verified)
- `4d71455976891` is NOT in v6.1: **YES** (verified)
- So only v6.12.y and later are affected.

**Step 3.4: Author Context**
Chi Zhiling has other exfat contributions (cache improvements). Yuezhang
Mo is the author of the original dentry cache conversion that
contributed to this bug, and reviewed this fix. The fix was applied by
Namjae Jeon, the exfat maintainer.

**Step 3.5: Dependencies**
None. The fix is self-contained - it adds one line to an existing
function. No prerequisites needed.

## PHASE 4: MAILING LIST RESEARCH

Lore.kernel.org is currently behind anti-bot protection, preventing
direct access. Unable to fetch mailing list discussion.

Record: Could not verify mailing list discussion due to lore access
restrictions.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Key Function**
`exfat_init_ext_entry()` is modified.

**Step 5.2: Callers**
Four call sites found:
1. `namei.c:512` - `exfat_add_entry()` (new file/dir creation) - `es` is
   freshly created, `num_entries` matches. Safe.
2. `namei.c:1057` - `exfat_rename_file()`, new entry path (rename to
   longer name) - `new_es` freshly created. Safe.
3. `namei.c:1073` - `exfat_rename_file()`, in-place path (rename to
   shorter name) - **THIS IS THE BUGGY CALLER**. `old_es.num_entries` is
   stale.
4. `namei.c:1117` - `exfat_move_file()` - `new_es` freshly created.
   Safe.

**Step 5.3: Callees**
`exfat_init_ext_entry` calls `exfat_update_dir_chksum(es)` which
iterates `es->num_entries` entries. This is where the wrong checksum is
computed.

**Step 5.4: Reachability**
The buggy path is reached via: `rename(2)` → `exfat_rename()` →
`__exfat_rename()` → `exfat_rename_file()` (else branch when
`old_es.num_entries >= num_new_entries`). This is triggered by any user
renaming a file to a shorter name on an exfat filesystem. **Directly
reachable from userspace.**

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Buggy Code in Stable**
The bug (commit `4d71455976891`) exists in v6.12.y but NOT in v6.6.y or
v6.1.y.

**Step 6.2: Backport Complications**
The patch is a single-line addition. The `exfat_init_ext_entry` function
exists with the same structure in all affected stable trees. Should
apply cleanly.

**Step 6.3: Related Fixes Already in Stable**
No related fixes found.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: Subsystem**
- Filesystem: exfat (`fs/exfat/`)
- Criticality: IMPORTANT. exfat is the standard filesystem for SDXC
  cards, USB drives >32GB, and cross-platform file exchange. Very widely
  used.

**Step 7.2: Activity**
Active subsystem with regular contributions from Samsung and Sony
engineers. Stable with well-maintained code.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Who Is Affected**
All users of exfat filesystems who rename files to shorter names. This
includes USB drive users, SD card users, and any system mounting exfat
volumes.

**Step 8.2: Trigger Conditions**
- Trigger: Renaming a file where the new name requires fewer directory
  entries (shorter name).
- Frequency: Common operation - users rename files regularly.
- Reachable from unprivileged user: Yes (any user with write access to
  the filesystem).

**Step 8.3: Failure Mode**
- Under normal operation: Transient incorrect checksum, corrected by
  inode writeback within ~30 seconds. Severity: LOW.
- Under crash (USB yank, power loss): On-disk checksum mismatch
  persists. Other OS (Windows, macOS) that validate exfat checksums may
  refuse to read the file. fsck.exfat tools will report corruption.
  Severity: MEDIUM.
- The Linux exfat driver does NOT validate checksums on read (confirmed
  by code review of `exfat_get_dentry_set`), so Linux itself would still
  read the entry, but cross-platform compatibility is compromised.

**Step 8.4: Risk-Benefit Ratio**
- BENEFIT: HIGH for crash resilience and cross-platform correctness.
  exfat is designed for removable media where surprise removal is
  common.
- RISK: VERY LOW. Single line, no-op for all callers except the buggy
  one, reviewed by two domain experts.

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence Summary**

FOR backporting:
- Fixes a real filesystem correctness bug (incorrect on-disk checksum)
- Single line fix, obviously correct, minimal risk
- Reviewed by Sungjong Seo (Samsung) and Yuezhang Mo (Sony) - the two
  primary exfat reviewers
- Applied by the subsystem maintainer (Namjae Jeon)
- Triggered by common user operation (rename) reachable from userspace
- exfat is widely used on removable media where crash/surprise removal
  is common
- Crash during the window leaves persistent checksum corruption visible
  to other OS

AGAINST backporting:
- Author states no persistent corruption under normal operation
  (writeback corrects it)
- Linux exfat driver doesn't validate checksums on read (so Linux users
  won't notice)
- Impact only manifests on crash during rename + subsequent read by
  another OS or fsck

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** - single line, reviewed by two
   experts
2. Fixes a real bug? **YES** - incorrect checksum written to disk
3. Important issue? **YES** - filesystem data integrity (checksum
   corruption on crash)
4. Small and contained? **YES** - 1 line in 1 file
5. No new features or APIs? **YES** - pure bug fix
6. Can apply to stable? **YES** - should apply cleanly

**Step 9.3: Exception Categories**
Not applicable - this is a standard bug fix.

**Verification:**
- [Phase 1] Parsed tags: Reviewed-by from two key exfat contributors
  (Seo, Mo), applied by maintainer (Jeon)
- [Phase 2] Diff analysis: 1 line added (`es->num_entries =
  num_entries;`) in `exfat_init_ext_entry()`
- [Phase 3] git blame: `exfat_update_dir_chksum(es)` added to the
  function by commit `4d71455976891` (v6.9-rc1)
- [Phase 3] git describe --contains: bug commit `4d71455976891` first in
  v6.9-rc1
- [Phase 3] git merge-base: confirmed present in v6.12, NOT in v6.6 or
  v6.1
- [Phase 5] Grep for callers: 4 call sites, only `namei.c:1073` (rename-
  in-place to shorter name) is affected
- [Phase 5] Code review of `exfat_update_dir_chksum`: confirmed it uses
  `es->num_entries` for loop bound
- [Phase 5] Code review of `exfat_remove_entries`: confirmed it does NOT
  update `es->num_entries`
- [Phase 5] Code review of `exfat_get_dentry_set`: confirmed Linux
  driver doesn't validate checksums on read
- [Phase 6] Verified `exfat_rename_file` rename path at
  namei.c:1066-1075 shows the sequence: remove_entries then
  init_ext_entry
- [Phase 6] Verified `__exfat_write_inode` at inode.c:20-98 re-reads
  dentry set with correct count and recomputes checksum
- [Phase 8] Verified `exfat_rename()` at namei.c:1282-1285 calls
  `mark_inode_dirty(old_inode)` after rename, confirming eventual
  writeback
- UNVERIFIED: Could not access lore.kernel.org to read mailing list
  discussion (anti-bot protection)

The fix is a minimal, obviously correct single-line change that fixes a
real filesystem correctness bug (incorrect checksum written to disk
during rename-to-shorter-name). The incorrect checksum creates a crash-
vulnerability window where surprise removal or power loss can leave
persistent corruption visible to other operating systems and filesystem
checkers. The fix was reviewed by two exfat domain experts and applied
by the subsystem maintainer.

**YES**

 fs/exfat/dir.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c
index e710dd196e2f0..2a4f6a131fbe7 100644
--- a/fs/exfat/dir.c
+++ b/fs/exfat/dir.c
@@ -490,6 +490,7 @@ void exfat_init_ext_entry(struct exfat_entry_set_cache *es, int num_entries,
 	unsigned short *uniname = p_uniname->name;
 	struct exfat_dentry *ep;
 
+	es->num_entries = num_entries;
 	ep = exfat_get_dentry_cached(es, ES_IDX_FILE);
 	ep->dentry.file.num_ext = (unsigned char)(num_entries - 1);
 
-- 
2.53.0