swiotlb: fix swiotlb_bounce() to do partial sync's correctly

jira LE-1907
cve CVE-2024-35814
Rebuild_History Non-Buildable kernel-4.18.0-553.16.1.el8_10
commit-author Michael Kelley <[email protected]>
commit e8068f2
Empty-Commit: Cherry-Pick Conflicts during history rebuild.
Will be included in final tarball splat. Ref for failed cherry-pick at:
ciq/ciq_backports/kernel-4.18.0-553.16.1.el8_10/e8068f2d.failed

In current code, swiotlb_bounce() may do partial sync's correctly in
some circumstances, but may incorrectly fail in other circumstances.
The failure cases require both of these to be true:

1) swiotlb_align_offset() returns a non-zero "offset" value
2) the tlb_addr of the partial sync area points into the first
"offset" bytes of the _second_ or subsequent swiotlb slot allocated
for the mapping

Code added in commit 868c9dd ("swiotlb: add overflow checks
to swiotlb_bounce") attempts to WARN on the invalid case where
tlb_addr points into the first "offset" bytes of the _first_
allocated slot. But there's no way for swiotlb_bounce() to distinguish
the first slot from the second and subsequent slots, so the WARN
can be triggered incorrectly when #2 above is true.

Related, current code calculates an adjustment to the orig_addr stored
in the swiotlb slot. The adjustment compensates for the difference
in the tlb_addr used for the partial sync vs. the tlb_addr for the full
mapping. The adjustment is stored in the local variable tlb_offset.
But when #1 and #2 above are true, it's valid for this adjustment to
be negative. In such case the arithmetic to adjust orig_addr produces
the wrong result due to tlb_offset being declared as unsigned.

Fix these problems by removing the over-constraining validations added
in 868c9dd. Change the declaration of tlb_offset to be signed
instead of unsigned so the adjustment arithmetic works correctly.

Tested with a test-only hack to how swiotlb_tbl_map_single() calls
swiotlb_bounce(). Instead of calling swiotlb_bounce() just once
for the entire mapped area, do a loop with each iteration doing
only a 128 byte partial sync until the entire mapped area is
sync'ed. Then with swiotlb=force on the kernel boot line, run a
variety of raw disk writes followed by read and verification of
all bytes of the written data. The storage device has DMA
min_align_mask set, and the writes are done with a variety of
original buffer memory address alignments and overall buffer
sizes. For many of the combinations, current code triggers the
WARN statements, or the data verification fails. With the fixes,
no WARNs occur and all verifications pass.

Fixes: 5f89468 ("swiotlb: manipulate orig_addr when tlb_addr has offset")
Fixes: 868c9dd ("swiotlb: add overflow checks to swiotlb_bounce")
	Signed-off-by: Michael Kelley <[email protected]>
Dominique Martinet <[email protected]>
	Signed-off-by: Christoph Hellwig <[email protected]>
(cherry picked from commit e8068f2)
	Signed-off-by: Jonathan Maple <[email protected]>

# Conflicts:
#	kernel/dma/swiotlb.c

Author: PlaidCat

ciq/ciq_backports/kernel-4.18.0-553.16.1.el8_10/e8068f2d.failed

@@ -0,0 +1,105 @@
+swiotlb: fix swiotlb_bounce() to do partial sync's correctly
+
+jira LE-1907
+cve CVE-2024-35814
+Rebuild_History Non-Buildable kernel-4.18.0-553.16.1.el8_10
+commit-author Michael Kelley <[email protected]>
+commit e8068f2d756d57a5206fa3180ade365a8c12ed85
+Empty-Commit: Cherry-Pick Conflicts during history rebuild.
+Will be included in final tarball splat. Ref for failed cherry-pick at:
+ciq/ciq_backports/kernel-4.18.0-553.16.1.el8_10/e8068f2d.failed
+
+In current code, swiotlb_bounce() may do partial sync's correctly in
+some circumstances, but may incorrectly fail in other circumstances.
+The failure cases require both of these to be true:
+
+1) swiotlb_align_offset() returns a non-zero "offset" value
+2) the tlb_addr of the partial sync area points into the first
+"offset" bytes of the _second_ or subsequent swiotlb slot allocated
+for the mapping
+
+Code added in commit 868c9ddc182b ("swiotlb: add overflow checks
+to swiotlb_bounce") attempts to WARN on the invalid case where
+tlb_addr points into the first "offset" bytes of the _first_
+allocated slot. But there's no way for swiotlb_bounce() to distinguish
+the first slot from the second and subsequent slots, so the WARN
+can be triggered incorrectly when #2 above is true.
+
+Related, current code calculates an adjustment to the orig_addr stored
+in the swiotlb slot. The adjustment compensates for the difference
+in the tlb_addr used for the partial sync vs. the tlb_addr for the full
+mapping. The adjustment is stored in the local variable tlb_offset.
+But when #1 and #2 above are true, it's valid for this adjustment to
+be negative. In such case the arithmetic to adjust orig_addr produces
+the wrong result due to tlb_offset being declared as unsigned.
+
+Fix these problems by removing the over-constraining validations added
+in 868c9ddc182b. Change the declaration of tlb_offset to be signed
+instead of unsigned so the adjustment arithmetic works correctly.
+
+Tested with a test-only hack to how swiotlb_tbl_map_single() calls
+swiotlb_bounce(). Instead of calling swiotlb_bounce() just once
+for the entire mapped area, do a loop with each iteration doing
+only a 128 byte partial sync until the entire mapped area is
+sync'ed. Then with swiotlb=force on the kernel boot line, run a
+variety of raw disk writes followed by read and verification of
+all bytes of the written data. The storage device has DMA
+min_align_mask set, and the writes are done with a variety of
+original buffer memory address alignments and overall buffer
+sizes. For many of the combinations, current code triggers the
+WARN statements, or the data verification fails. With the fixes,
+no WARNs occur and all verifications pass.
+
+Fixes: 5f89468e2f06 ("swiotlb: manipulate orig_addr when tlb_addr has offset")
+Fixes: 868c9ddc182b ("swiotlb: add overflow checks to swiotlb_bounce")
+	Signed-off-by: Michael Kelley <[email protected]>
+Dominique Martinet <[email protected]>
+	Signed-off-by: Christoph Hellwig <[email protected]>
+(cherry picked from commit e8068f2d756d57a5206fa3180ade365a8c12ed85)
+	Signed-off-by: Jonathan Maple <[email protected]>
+
+# Conflicts:
+#	kernel/dma/swiotlb.c
+diff --cc kernel/dma/swiotlb.c
+index c0e227dcb45e,d57c8837c813..000000000000
+--- a/kernel/dma/swiotlb.c
++++ b/kernel/dma/swiotlb.c
+@@@ -509,22 -868,18 +509,37 @@@ static void swiotlb_bounce(struct devic
+  	if (orig_addr == INVALID_PHYS_ADDR)
+  		return;
+  
+++<<<<<<< HEAD
+ +	tlb_offset = tlb_addr & (IO_TLB_SIZE - 1);
+ +	orig_addr_offset = swiotlb_align_offset(dev, orig_addr);
+ +	if (tlb_offset < orig_addr_offset) {
+ +		dev_WARN_ONCE(dev, 1,
+ +			"Access before mapping start detected. orig offset %u, requested offset %u.\n",
+ +			orig_addr_offset, tlb_offset);
+ +		return;
+ +	}
+ +
+ +	tlb_offset -= orig_addr_offset;
+ +	if (tlb_offset > alloc_size) {
+ +		dev_WARN_ONCE(dev, 1,
+ +			"Buffer overflow detected. Allocation size: %zu. Mapping size: %zu+%u.\n",
+ +			alloc_size, size, tlb_offset);
+ +		return;
+ +	}
+++=======
++ 	/*
++ 	 * It's valid for tlb_offset to be negative. This can happen when the
++ 	 * "offset" returned by swiotlb_align_offset() is non-zero, and the
++ 	 * tlb_addr is pointing within the first "offset" bytes of the second
++ 	 * or subsequent slots of the allocated swiotlb area. While it's not
++ 	 * valid for tlb_addr to be pointing within the first "offset" bytes
++ 	 * of the first slot, there's no way to check for such an error since
++ 	 * this function can't distinguish the first slot from the second and
++ 	 * subsequent slots.
++ 	 */
++ 	tlb_offset = (tlb_addr & (IO_TLB_SIZE - 1)) -
++ 		     swiotlb_align_offset(dev, 0, orig_addr);
+++>>>>>>> e8068f2d756d (swiotlb: fix swiotlb_bounce() to do partial sync's correctly)
+  
+  	orig_addr += tlb_offset;
+  	alloc_size -= tlb_offset;
+* Unmerged path kernel/dma/swiotlb.c