Skip to contentSkip to conversation

Patch "iommu/iova: Fix underflow bug in __alloc_and_insert_iova_range" has been added to the 4.9-stable tree

PATCH [email protected] 1 participant 1 message Mar 18, 2018

Subsystems (3)
lore
Share & tools
lore

[email protected]

author maintainer Applied
#0 lore raw

This is a note to let you know that I've just added the patch titled

iommu/iova: Fix underflow bug in __alloc_and_insert_iova_range

to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
iommu-iova-fix-underflow-bug-in-__alloc_and_insert_iova_range.patch
and it can be found in the queue-4.9 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

Quoted 1 line

From foo@baz Sun Mar 18 16:55:33 CET 2018

From: Nate Watterson <[email protected]>
Date: Fri, 7 Apr 2017 01:36:20 -0400
Subject: iommu/iova: Fix underflow bug in __alloc_and_insert_iova_range

From: Nate Watterson <[email protected]>

[ Upstream commit 5016bdb796b3726eec043ca0ce3be981f712c756 ]

Normally, calling alloc_iova() using an iova_domain with insufficient pfns remaining between start_pfn and dma_limit will fail and return a NULL pointer. Unexpectedly, if such a "full" iova_domain contains an iova with pfn_lo == 0, the alloc_iova() call will instead succeed and return an iova containing invalid pfns.

This is caused by an underflow bug in __alloc_and_insert_iova_range() that occurs after walking the "full" iova tree when the search ends at the iova with pfn_lo == 0 and limit_pfn is then adjusted to be just below that (-1). This (now huge) limit_pfn gives the impression that a vast amount of space is available between it and start_pfn and thus a new iova is allocated with the invalid pfn_hi value, 0xFFF.... .

To rememdy this, a check is introduced to ensure that adjustments to limit_pfn will not underflow.

This issue has been observed in the wild, and is easily reproduced with the following sample code.

	struct iova_domain *iovad = kzalloc(sizeof(*iovad), GFP_KERNEL);
	struct iova *rsvd_iova, *good_iova, *bad_iova;
	unsigned long limit_pfn = 3;
	unsigned long start_pfn = 1;
	unsigned long va_size = 2;

	init_iova_domain(iovad, SZ_4K, start_pfn, limit_pfn);
	rsvd_iova = reserve_iova(iovad, 0, 0);
	good_iova = alloc_iova(iovad, va_size, limit_pfn, true);
	bad_iova = alloc_iova(iovad, va_size, limit_pfn, true);

Prior to the patch, this yielded:

	*rsvd_iova == {0, 0}   /* Expected */
	*good_iova == {2, 3}   /* Expected */
	*bad_iova  == {-2, -1} /* Oh no... */

After the patch, bad_iova is NULL as expected since inadequate space remains between limit_pfn and start_pfn after allocating good_iova.

---
 drivers/iommu/iova.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iommu/iova.c +1 -1
@@ -138,7 +138,7 @@ static int __alloc_and_insert_iova_range
 				break;	/* found a free slot */
 		}
 adjust_limit_pfn:
-		limit_pfn = curr_iova->pfn_lo - 1;
+		limit_pfn = curr_iova->pfn_lo ? (curr_iova->pfn_lo - 1) : 0;
 move_left:
 		prev = curr;
 		curr = rb_prev(curr);

Patches currently in stable-queue which might be from [email protected] are

queue-4.9/iommu-iova-fix-underflow-bug-in-__alloc_and_insert_iova_range.patch