[PATCH AUTOSEL 6.18] block: validate pi_offset integrity limit

[Sasha Levin <sashal@kernel.org>]

From: Caleb Sander Mateos <csander@purestorage.com>

[ Upstream commit ccb8a3c08adf8121e2afb8e704f007ce99324d79 ]

The PI tuple must be contained within the metadata value, so validate
that pi_offset + pi_tuple_size <= metadata_size. This guards against
block drivers that report invalid pi_offset values.

Signed-off-by: Caleb Sander Mateos <csander@purestorage.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Summary

### Problem Being Fixed
The commit fixes an **incomplete bounds validation bug** in the block
layer's integrity limit validation code. When the PI (Protection
Information) tuple can be placed at a non-zero offset within the
metadata buffer (a feature added in kernel 6.9), the validation check
only verified that `pi_tuple_size <= metadata_size`, but **completely
ignored the pi_offset**.

This is mathematically incorrect. If:
- `metadata_size = 8` bytes
- `pi_tuple_size = 8` bytes
- `pi_offset = 4` bytes

The old check (`8 > 8`) passes, but the PI tuple would extend 4 bytes
beyond the buffer boundary, potentially causing out-of-bounds memory
access.

### Why It Matters to Stable Users
- **Data Integrity Risk**: Block layer integrity/PI is used in
  enterprise storage environments (NVMe, SAS with T10 PI)
- **Defense Against Buggy Drivers**: The fix prevents the kernel from
  accepting invalid configurations from misbehaving block drivers
- **Potential for Memory Corruption**: Without this validation,
  accessing PI data could read/write beyond buffer bounds

### Stable Kernel Criteria Assessment

| Criterion | Met? | Notes |
|-----------|------|-------|
| Obviously correct | ✅ | Mathematical correctness: offset + size must
fit in buffer |
| Fixes real bug | ✅ | Incomplete bounds check could allow invalid
configurations |
| Small scope | ✅ | 4 lines changed, single file |
| No new features | ✅ | Only strengthens existing validation |
| No API changes | ✅ | No user-visible changes |

### Risk vs Benefit

**Risk**: Extremely low
- The change only makes validation stricter
- Can only reject configurations that were previously (incorrectly)
  accepted
- Any configuration rejected by the new check was already semantically
  invalid and potentially dangerous

**Benefit**: Moderate to high
- Prevents kernel from accepting invalid integrity configurations
- Guards against memory corruption in PI-enabled storage stacks
- Important for enterprise environments using DIF/PI

### Concerns

**Applicability**: The `pi_offset` field was introduced in kernel 6.9
(commit 60d21aac52e2). This fix is only applicable to stable kernels
6.9.y and later.

**Dependencies**: None - this is a standalone validation fix.

### Quality Indicators
- Reviewed-by: Christoph Hellwig (highly respected kernel developer)
- Signed-off-by: Jens Axboe (block layer maintainer)
- Part of a series of validation improvements (similar commit for
  `interval_exp`)
- No follow-up fixes needed

The fix is small, surgical, obviously correct, and addresses a real
validation gap that could lead to memory safety issues. It meets all
stable kernel criteria.

**YES**

 block/blk-settings.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/block/blk-settings.c b/block/blk-settings.c
index d74b13ec8e54..f2c1940fe6f1 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -148,10 +148,9 @@ static int blk_validate_integrity_limits(struct queue_limits *lim)
 		return -EINVAL;
 	}
 
-	if (bi->pi_tuple_size > bi->metadata_size) {
-		pr_warn("pi_tuple_size (%u) exceeds metadata_size (%u)\n",
-			 bi->pi_tuple_size,
-			 bi->metadata_size);
+	if (bi->pi_offset + bi->pi_tuple_size > bi->metadata_size) {
+		pr_warn("pi_offset (%u) + pi_tuple_size (%u) exceeds metadata_size (%u)\n",
+			bi->pi_offset, bi->pi_tuple_size, bi->metadata_size);
 		return -EINVAL;
 	}
 
-- 
2.51.0