[PATCH AUTOSEL 6.16-5.4] pNFS: Fix disk addr range check in block/scsi layout

[Sasha Levin <sashal@kernel.org>]

From: Sergey Bashirov <sergeybashirov@gmail.com>

[ Upstream commit 7db6e66663681abda54f81d5916db3a3b8b1a13d ]

At the end of the isect translation, disc_addr represents the physical
disk offset. Thus, end calculated from disk_addr is also a physical disk
offset. Therefore, range checking should be done using map->disk_offset,
not map->start.

Signed-off-by: Sergey Bashirov <sergeybashirov@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20250702133226.212537-1-sergeybashirov@gmail.com
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

This commit is a clear bugfix that should be backported to stable kernel
trees. Here's my detailed analysis:

## Bug Analysis

The commit fixes an incorrect range check in the pNFS block/SCSI layout
code. Looking at the code flow:

1. **Variable Transformations** (lines 140-148):
   - `disk_addr` starts as a physical disk offset (line 141)
   - It gets adjusted by `map->disk_offset` (line 147)
   - Then it's adjusted by subtracting `map->start` (line 148)
   - After these operations, `disk_addr` represents the **relative
     offset within the mapped region**

2. **The Bug** (lines 151-153):
   - `end = disk_addr + *len` calculates the end position using the
     **transformed** disk_addr
   - The buggy check `if (end >= map->start + map->len)` incorrectly
     compares this relative end position against `map->start + map->len`
   - This is wrong because `end` is now relative to the mapping, not an
     absolute address

3. **The Fix**:
   - Changes the comparison to `if (end >= map->disk_offset + map->len)`
   - This correctly uses `map->disk_offset` which corresponds to the
     physical disk space after the transformations

## Why This Should Be Backported

1. **Clear Bug Fix**: This fixes a logical error in range checking that
   could lead to:
   - Incorrect I/O length calculations
   - Potential data corruption if writes go beyond intended boundaries
   - Read errors or incomplete data transfers

2. **Small and Contained**: The fix changes only 2 lines in a single
   function, making it low-risk for regression

3. **Critical Subsystem**: pNFS block layout is used in production NFS
   environments for high-performance storage access

4. **No New Features**: This is purely a bugfix - no new functionality
   or architectural changes

5. **Stable Impact**: The bug could cause silent data corruption or I/O
   errors in stable kernels using pNFS block layouts

6. **Related History**: The codebase shows previous fixes for similar
   range checking issues (commit f34462c3c8a2), indicating this is a
   sensitive area that needs correct boundary validation

The incorrect range check could allow I/O operations to proceed with
incorrect length limits, potentially accessing memory beyond the
intended device mapping boundaries. This is exactly the type of bug that
stable kernels need fixed - a subtle logic error with potentially
serious consequences in production systems.

 fs/nfs/blocklayout/blocklayout.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/nfs/blocklayout/blocklayout.c b/fs/nfs/blocklayout/blocklayout.c
index 47189476b553..5d6edafbed20 100644
--- a/fs/nfs/blocklayout/blocklayout.c
+++ b/fs/nfs/blocklayout/blocklayout.c
@@ -149,8 +149,8 @@ do_add_page_to_bio(struct bio *bio, int npg, enum req_op op, sector_t isect,
 
 	/* limit length to what the device mapping allows */
 	end = disk_addr + *len;
-	if (end >= map->start + map->len)
-		*len = map->start + map->len - disk_addr;
+	if (end >= map->disk_offset + map->len)
+		*len = map->disk_offset + map->len - disk_addr;
 
 retry:
 	if (!bio) {
-- 
2.39.5