* [PATCH v2] iommu/sva: Fix PASID use-after-free issue
@ 2022-04-28 18:00 ` Fenghua Yu
0 siblings, 0 replies; 9+ messages in thread
From: Fenghua Yu @ 2022-04-28 18:00 UTC (permalink / raw)
To: Dave Hansen, Thomas Gleixner, Jean-Philippe Brucker,
Borislav Petkov, Ingo Molnar, Zhangfei Gao, Will Deacon,
Robin Murphy, Tony Luck, Jacob Pan, Ravi V Shankar,
Peter Zijlstra, Andy Lutomirski, x86, linux-kernel, iommu
Cc: Fenghua Yu, Zhangfei Gao
The PASID is being freed too early. It needs to stay around until after
device drivers that might be using it have had a chance to clear it out
of the hardware.
As a reminder:
mmget() /mmput() refcount the mm's address space
mmgrab()/mmdrop() refcount the mm itself
The PASID is currently tied to the life of the mm's address space and
freed in __mmput(). This makes logical sense because the PASID can't be
used once the address space is gone.
But, this misses an important point: even after the address space is
gone, the PASID will still be programmed into a device. Device drivers
might, for instance, still need to flush operations that are outstanding
and need to use that PASID. They do this at file->release() time.
Device drivers call the IOMMU driver to hold a reference on the mm itself
and drop it at file->release() time. But, the IOMMU driver holds a
reference on the mm itself, not the address space. The address space
(and the PASID) is long gone by the time the driver tries to clean up.
This is effectively a use-after-free bug on the PASID.
To fix this, move the PASID free operation from __mmput() to __mmdrop().
This ensures that the IOMMU driver's existing mmgrab() keeps the PASID
allocated until it drops its mm reference.
Fixes: 701fac40384f ("iommu/sva: Assign a PASID to mm on PASID allocation and free it on mm exit")
Reported-by: Zhangfei Gao <zhangfei.gao@foxmail.com>
Tested-by: Zhangfei Gao <zhangfei.gao@foxmail.com>
Suggested-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Suggested-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
---
v2:
- Dave Hansen rewrites the change log.
- Add Tested-by: Zhangfei Gao <zhangfei.gao@foxmail.com>
- Add Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
The original patch was posted and discussed in:
https://lore.kernel.org/lkml/YmdzFFx7fN586jcf@fyu1.sc.intel.com/
kernel/fork.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index 9796897560ab..35a3beff140b 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -792,6 +792,7 @@ void __mmdrop(struct mm_struct *mm)
mmu_notifier_subscriptions_destroy(mm);
check_mm(mm);
put_user_ns(mm->user_ns);
+ mm_pasid_drop(mm);
free_mm(mm);
}
EXPORT_SYMBOL_GPL(__mmdrop);
@@ -1190,7 +1191,6 @@ static inline void __mmput(struct mm_struct *mm)
}
if (mm->binfmt)
module_put(mm->binfmt->module);
- mm_pasid_drop(mm);
mmdrop(mm);
}
--
2.32.0
^ permalink raw reply related [flat|nested] 9+ messages in thread* [PATCH v2] iommu/sva: Fix PASID use-after-free issue
@ 2022-04-28 18:00 ` Fenghua Yu
0 siblings, 0 replies; 9+ messages in thread
From: Fenghua Yu @ 2022-04-28 18:00 UTC (permalink / raw)
To: Dave Hansen, Thomas Gleixner, Jean-Philippe Brucker,
Borislav Petkov, Ingo Molnar, Zhangfei Gao, Will Deacon,
Robin Murphy, Tony Luck, Jacob Pan, Ravi V Shankar,
Peter Zijlstra, Andy Lutomirski, x86, linux-kernel, iommu
Cc: Fenghua Yu
The PASID is being freed too early. It needs to stay around until after
device drivers that might be using it have had a chance to clear it out
of the hardware.
As a reminder:
mmget() /mmput() refcount the mm's address space
mmgrab()/mmdrop() refcount the mm itself
The PASID is currently tied to the life of the mm's address space and
freed in __mmput(). This makes logical sense because the PASID can't be
used once the address space is gone.
But, this misses an important point: even after the address space is
gone, the PASID will still be programmed into a device. Device drivers
might, for instance, still need to flush operations that are outstanding
and need to use that PASID. They do this at file->release() time.
Device drivers call the IOMMU driver to hold a reference on the mm itself
and drop it at file->release() time. But, the IOMMU driver holds a
reference on the mm itself, not the address space. The address space
(and the PASID) is long gone by the time the driver tries to clean up.
This is effectively a use-after-free bug on the PASID.
To fix this, move the PASID free operation from __mmput() to __mmdrop().
This ensures that the IOMMU driver's existing mmgrab() keeps the PASID
allocated until it drops its mm reference.
Fixes: 701fac40384f ("iommu/sva: Assign a PASID to mm on PASID allocation and free it on mm exit")
Reported-by: Zhangfei Gao <zhangfei.gao@foxmail.com>
Tested-by: Zhangfei Gao <zhangfei.gao@foxmail.com>
Suggested-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Suggested-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
---
v2:
- Dave Hansen rewrites the change log.
- Add Tested-by: Zhangfei Gao <zhangfei.gao@foxmail.com>
- Add Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
The original patch was posted and discussed in:
https://lore.kernel.org/lkml/YmdzFFx7fN586jcf@fyu1.sc.intel.com/
kernel/fork.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index 9796897560ab..35a3beff140b 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -792,6 +792,7 @@ void __mmdrop(struct mm_struct *mm)
mmu_notifier_subscriptions_destroy(mm);
check_mm(mm);
put_user_ns(mm->user_ns);
+ mm_pasid_drop(mm);
free_mm(mm);
}
EXPORT_SYMBOL_GPL(__mmdrop);
@@ -1190,7 +1191,6 @@ static inline void __mmput(struct mm_struct *mm)
}
if (mm->binfmt)
module_put(mm->binfmt->module);
- mm_pasid_drop(mm);
mmdrop(mm);
}
--
2.32.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH v2] iommu/sva: Fix PASID use-after-free issue
2022-04-28 18:00 ` Fenghua Yu
@ 2022-04-29 1:39 ` Zhangfei Gao
-1 siblings, 0 replies; 9+ messages in thread
From: Zhangfei Gao @ 2022-04-29 1:39 UTC (permalink / raw)
To: Fenghua Yu, Dave Hansen, Thomas Gleixner, Jean-Philippe Brucker,
Borislav Petkov, Ingo Molnar, Zhangfei Gao, Will Deacon,
Robin Murphy, Tony Luck, Jacob Pan, Ravi V Shankar,
Peter Zijlstra, Andy Lutomirski, x86, linux-kernel, iommu
On 2022/4/29 上午2:00, Fenghua Yu wrote:
> The PASID is being freed too early. It needs to stay around until after
> device drivers that might be using it have had a chance to clear it out
> of the hardware.
>
> As a reminder:
>
> mmget() /mmput() refcount the mm's address space
> mmgrab()/mmdrop() refcount the mm itself
>
> The PASID is currently tied to the life of the mm's address space and
> freed in __mmput(). This makes logical sense because the PASID can't be
> used once the address space is gone.
>
> But, this misses an important point: even after the address space is
> gone, the PASID will still be programmed into a device. Device drivers
> might, for instance, still need to flush operations that are outstanding
> and need to use that PASID. They do this at file->release() time.
>
> Device drivers call the IOMMU driver to hold a reference on the mm itself
> and drop it at file->release() time. But, the IOMMU driver holds a
> reference on the mm itself, not the address space. The address space
> (and the PASID) is long gone by the time the driver tries to clean up.
> This is effectively a use-after-free bug on the PASID.
>
> To fix this, move the PASID free operation from __mmput() to __mmdrop().
> This ensures that the IOMMU driver's existing mmgrab() keeps the PASID
> allocated until it drops its mm reference.
>
> Fixes: 701fac40384f ("iommu/sva: Assign a PASID to mm on PASID allocation and free it on mm exit")
>
> Reported-by: Zhangfei Gao <zhangfei.gao@foxmail.com>
> Tested-by: Zhangfei Gao <zhangfei.gao@foxmail.com>
Tested-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Use the formal email, thanks
> Suggested-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> Suggested-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> ---
>
> v2:
> - Dave Hansen rewrites the change log.
> - Add Tested-by: Zhangfei Gao <zhangfei.gao@foxmail.com>
> - Add Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
>
> The original patch was posted and discussed in:
> https://lore.kernel.org/lkml/YmdzFFx7fN586jcf@fyu1.sc.intel.com/
>
> kernel/fork.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 9796897560ab..35a3beff140b 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -792,6 +792,7 @@ void __mmdrop(struct mm_struct *mm)
> mmu_notifier_subscriptions_destroy(mm);
> check_mm(mm);
> put_user_ns(mm->user_ns);
> + mm_pasid_drop(mm);
> free_mm(mm);
> }
> EXPORT_SYMBOL_GPL(__mmdrop);
> @@ -1190,7 +1191,6 @@ static inline void __mmput(struct mm_struct *mm)
> }
> if (mm->binfmt)
> module_put(mm->binfmt->module);
> - mm_pasid_drop(mm);
> mmdrop(mm);
> }
>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH v2] iommu/sva: Fix PASID use-after-free issue
@ 2022-04-29 1:39 ` Zhangfei Gao
0 siblings, 0 replies; 9+ messages in thread
From: Zhangfei Gao @ 2022-04-29 1:39 UTC (permalink / raw)
To: Fenghua Yu, Dave Hansen, Thomas Gleixner, Jean-Philippe Brucker,
Borislav Petkov, Ingo Molnar, Zhangfei Gao, Will Deacon,
Robin Murphy, Tony Luck, Jacob Pan, Ravi V Shankar,
Peter Zijlstra, Andy Lutomirski, x86, linux-kernel, iommu
On 2022/4/29 上午2:00, Fenghua Yu wrote:
> The PASID is being freed too early. It needs to stay around until after
> device drivers that might be using it have had a chance to clear it out
> of the hardware.
>
> As a reminder:
>
> mmget() /mmput() refcount the mm's address space
> mmgrab()/mmdrop() refcount the mm itself
>
> The PASID is currently tied to the life of the mm's address space and
> freed in __mmput(). This makes logical sense because the PASID can't be
> used once the address space is gone.
>
> But, this misses an important point: even after the address space is
> gone, the PASID will still be programmed into a device. Device drivers
> might, for instance, still need to flush operations that are outstanding
> and need to use that PASID. They do this at file->release() time.
>
> Device drivers call the IOMMU driver to hold a reference on the mm itself
> and drop it at file->release() time. But, the IOMMU driver holds a
> reference on the mm itself, not the address space. The address space
> (and the PASID) is long gone by the time the driver tries to clean up.
> This is effectively a use-after-free bug on the PASID.
>
> To fix this, move the PASID free operation from __mmput() to __mmdrop().
> This ensures that the IOMMU driver's existing mmgrab() keeps the PASID
> allocated until it drops its mm reference.
>
> Fixes: 701fac40384f ("iommu/sva: Assign a PASID to mm on PASID allocation and free it on mm exit")
>
> Reported-by: Zhangfei Gao <zhangfei.gao@foxmail.com>
> Tested-by: Zhangfei Gao <zhangfei.gao@foxmail.com>
Tested-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Use the formal email, thanks
> Suggested-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> Suggested-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> ---
>
> v2:
> - Dave Hansen rewrites the change log.
> - Add Tested-by: Zhangfei Gao <zhangfei.gao@foxmail.com>
> - Add Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
>
> The original patch was posted and discussed in:
> https://lore.kernel.org/lkml/YmdzFFx7fN586jcf@fyu1.sc.intel.com/
>
> kernel/fork.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 9796897560ab..35a3beff140b 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -792,6 +792,7 @@ void __mmdrop(struct mm_struct *mm)
> mmu_notifier_subscriptions_destroy(mm);
> check_mm(mm);
> put_user_ns(mm->user_ns);
> + mm_pasid_drop(mm);
> free_mm(mm);
> }
> EXPORT_SYMBOL_GPL(__mmdrop);
> @@ -1190,7 +1191,6 @@ static inline void __mmput(struct mm_struct *mm)
> }
> if (mm->binfmt)
> module_put(mm->binfmt->module);
> - mm_pasid_drop(mm);
> mmdrop(mm);
> }
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH v2] iommu/sva: Fix PASID use-after-free issue
2022-04-29 1:39 ` Zhangfei Gao
@ 2022-05-06 1:49 ` Zhangfei Gao
-1 siblings, 0 replies; 9+ messages in thread
From: Zhangfei Gao @ 2022-05-06 1:49 UTC (permalink / raw)
To: Fenghua Yu, Dave Hansen, Thomas Gleixner, Jean-Philippe Brucker,
Borislav Petkov, Ingo Molnar, Will Deacon, Robin Murphy,
Tony Luck, Jacob Pan, Ravi V Shankar, Peter Zijlstra,
Andy Lutomirski, x86, linux-kernel, iommu
On 2022/4/29 上午9:39, Zhangfei Gao wrote:
>
>
> On 2022/4/29 上午2:00, Fenghua Yu wrote:
>> The PASID is being freed too early. It needs to stay around until after
>> device drivers that might be using it have had a chance to clear it out
>> of the hardware.
>>
>> As a reminder:
>>
>> mmget() /mmput() refcount the mm's address space
>> mmgrab()/mmdrop() refcount the mm itself
>>
>> The PASID is currently tied to the life of the mm's address space and
>> freed in __mmput(). This makes logical sense because the PASID can't be
>> used once the address space is gone.
>>
>> But, this misses an important point: even after the address space is
>> gone, the PASID will still be programmed into a device. Device drivers
>> might, for instance, still need to flush operations that are outstanding
>> and need to use that PASID. They do this at file->release() time.
>>
>> Device drivers call the IOMMU driver to hold a reference on the mm
>> itself
>> and drop it at file->release() time. But, the IOMMU driver holds a
>> reference on the mm itself, not the address space. The address space
>> (and the PASID) is long gone by the time the driver tries to clean up.
>> This is effectively a use-after-free bug on the PASID.
>>
>> To fix this, move the PASID free operation from __mmput() to __mmdrop().
>> This ensures that the IOMMU driver's existing mmgrab() keeps the PASID
>> allocated until it drops its mm reference.
>>
>> Fixes: 701fac40384f ("iommu/sva: Assign a PASID to mm on PASID
>> allocation and free it on mm exit")
>>
>> Reported-by: Zhangfei Gao <zhangfei.gao@foxmail.com>
>> Tested-by: Zhangfei Gao <zhangfei.gao@foxmail.com>
>
> Tested-by: Zhangfei Gao <zhangfei.gao@linaro.org>
>
> Use the formal email, thanks
>
>> Suggested-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
>> Suggested-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
>> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
>> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Hi,
Will this be taken for 5.18?
Thanks
>> ---
>>
>> v2:
>> - Dave Hansen rewrites the change log.
>> - Add Tested-by: Zhangfei Gao <zhangfei.gao@foxmail.com>
>> - Add Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
>>
>> The original patch was posted and discussed in:
>> https://lore.kernel.org/lkml/YmdzFFx7fN586jcf@fyu1.sc.intel.com/
>>
>> kernel/fork.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/fork.c b/kernel/fork.c
>> index 9796897560ab..35a3beff140b 100644
>> --- a/kernel/fork.c
>> +++ b/kernel/fork.c
>> @@ -792,6 +792,7 @@ void __mmdrop(struct mm_struct *mm)
>> mmu_notifier_subscriptions_destroy(mm);
>> check_mm(mm);
>> put_user_ns(mm->user_ns);
>> + mm_pasid_drop(mm);
>> free_mm(mm);
>> }
>> EXPORT_SYMBOL_GPL(__mmdrop);
>> @@ -1190,7 +1191,6 @@ static inline void __mmput(struct mm_struct *mm)
>> }
>> if (mm->binfmt)
>> module_put(mm->binfmt->module);
>> - mm_pasid_drop(mm);
>> mmdrop(mm);
>> }
>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH v2] iommu/sva: Fix PASID use-after-free issue
@ 2022-05-06 1:49 ` Zhangfei Gao
0 siblings, 0 replies; 9+ messages in thread
From: Zhangfei Gao @ 2022-05-06 1:49 UTC (permalink / raw)
To: Fenghua Yu, Dave Hansen, Thomas Gleixner, Jean-Philippe Brucker,
Borislav Petkov, Ingo Molnar, Will Deacon, Robin Murphy,
Tony Luck, Jacob Pan, Ravi V Shankar, Peter Zijlstra,
Andy Lutomirski, x86, linux-kernel, iommu
On 2022/4/29 上午9:39, Zhangfei Gao wrote:
>
>
> On 2022/4/29 上午2:00, Fenghua Yu wrote:
>> The PASID is being freed too early. It needs to stay around until after
>> device drivers that might be using it have had a chance to clear it out
>> of the hardware.
>>
>> As a reminder:
>>
>> mmget() /mmput() refcount the mm's address space
>> mmgrab()/mmdrop() refcount the mm itself
>>
>> The PASID is currently tied to the life of the mm's address space and
>> freed in __mmput(). This makes logical sense because the PASID can't be
>> used once the address space is gone.
>>
>> But, this misses an important point: even after the address space is
>> gone, the PASID will still be programmed into a device. Device drivers
>> might, for instance, still need to flush operations that are outstanding
>> and need to use that PASID. They do this at file->release() time.
>>
>> Device drivers call the IOMMU driver to hold a reference on the mm
>> itself
>> and drop it at file->release() time. But, the IOMMU driver holds a
>> reference on the mm itself, not the address space. The address space
>> (and the PASID) is long gone by the time the driver tries to clean up.
>> This is effectively a use-after-free bug on the PASID.
>>
>> To fix this, move the PASID free operation from __mmput() to __mmdrop().
>> This ensures that the IOMMU driver's existing mmgrab() keeps the PASID
>> allocated until it drops its mm reference.
>>
>> Fixes: 701fac40384f ("iommu/sva: Assign a PASID to mm on PASID
>> allocation and free it on mm exit")
>>
>> Reported-by: Zhangfei Gao <zhangfei.gao@foxmail.com>
>> Tested-by: Zhangfei Gao <zhangfei.gao@foxmail.com>
>
> Tested-by: Zhangfei Gao <zhangfei.gao@linaro.org>
>
> Use the formal email, thanks
>
>> Suggested-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
>> Suggested-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
>> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
>> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Hi,
Will this be taken for 5.18?
Thanks
>> ---
>>
>> v2:
>> - Dave Hansen rewrites the change log.
>> - Add Tested-by: Zhangfei Gao <zhangfei.gao@foxmail.com>
>> - Add Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
>>
>> The original patch was posted and discussed in:
>> https://lore.kernel.org/lkml/YmdzFFx7fN586jcf@fyu1.sc.intel.com/
>>
>> kernel/fork.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/fork.c b/kernel/fork.c
>> index 9796897560ab..35a3beff140b 100644
>> --- a/kernel/fork.c
>> +++ b/kernel/fork.c
>> @@ -792,6 +792,7 @@ void __mmdrop(struct mm_struct *mm)
>> mmu_notifier_subscriptions_destroy(mm);
>> check_mm(mm);
>> put_user_ns(mm->user_ns);
>> + mm_pasid_drop(mm);
>> free_mm(mm);
>> }
>> EXPORT_SYMBOL_GPL(__mmdrop);
>> @@ -1190,7 +1191,6 @@ static inline void __mmput(struct mm_struct *mm)
>> }
>> if (mm->binfmt)
>> module_put(mm->binfmt->module);
>> - mm_pasid_drop(mm);
>> mmdrop(mm);
>> }
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH v2] iommu/sva: Fix PASID use-after-free issue
2022-05-06 1:49 ` Zhangfei Gao
@ 2022-05-06 7:27 ` Thomas Gleixner
-1 siblings, 0 replies; 9+ messages in thread
From: Thomas Gleixner @ 2022-05-06 7:27 UTC (permalink / raw)
To: Zhangfei Gao, Fenghua Yu, Dave Hansen, Jean-Philippe Brucker,
Borislav Petkov, Ingo Molnar, Will Deacon, Robin Murphy,
Tony Luck, Jacob Pan, Ravi V Shankar, Peter Zijlstra,
Andy Lutomirski, x86, linux-kernel, iommu
On Fri, May 06 2022 at 09:49, Zhangfei Gao wrote:
> Will this be taken for 5.18?
It's queued in tip core/urgent and will go to Linus this week.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2] iommu/sva: Fix PASID use-after-free issue
@ 2022-05-06 7:27 ` Thomas Gleixner
0 siblings, 0 replies; 9+ messages in thread
From: Thomas Gleixner @ 2022-05-06 7:27 UTC (permalink / raw)
To: Zhangfei Gao, Fenghua Yu, Dave Hansen, Jean-Philippe Brucker,
Borislav Petkov, Ingo Molnar, Will Deacon, Robin Murphy,
Tony Luck, Jacob Pan, Ravi V Shankar, Peter Zijlstra,
Andy Lutomirski, x86, linux-kernel, iommu
On Fri, May 06 2022 at 09:49, Zhangfei Gao wrote:
> Will this be taken for 5.18?
It's queued in tip core/urgent and will go to Linus this week.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 9+ messages in thread
* [tip: core/urgent] mm: Fix PASID use-after-free issue
2022-04-28 18:00 ` Fenghua Yu
(?)
(?)
@ 2022-05-01 8:25 ` tip-bot2 for Fenghua Yu
-1 siblings, 0 replies; 9+ messages in thread
From: tip-bot2 for Fenghua Yu @ 2022-05-01 8:25 UTC (permalink / raw)
To: linux-tip-commits
Cc: Zhangfei Gao, Jean-Philippe Brucker, Jacob Pan, Fenghua Yu,
Thomas Gleixner, x86, linux-kernel
The following commit has been merged into the core/urgent branch of tip:
Commit-ID: 2667ed10d9f01e250ba806276740782c89d77fda
Gitweb: https://git.kernel.org/tip/2667ed10d9f01e250ba806276740782c89d77fda
Author: Fenghua Yu <fenghua.yu@intel.com>
AuthorDate: Thu, 28 Apr 2022 11:00:41 -07:00
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitterDate: Sun, 01 May 2022 10:17:17 +02:00
mm: Fix PASID use-after-free issue
The PASID is being freed too early. It needs to stay around until after
device drivers that might be using it have had a chance to clear it out
of the hardware.
The relevant refcounts are:
mmget() /mmput() refcount the mm's address space
mmgrab()/mmdrop() refcount the mm itself
The PASID is currently tied to the life of the mm's address space and freed
in __mmput(). This makes logical sense because the PASID can't be used
once the address space is gone.
But, this misses an important point: even after the address space is gone,
the PASID will still be programmed into a device. Device drivers might,
for instance, still need to flush operations that are outstanding and need
to use that PASID. They do this at file->release() time.
Device drivers call the IOMMU driver to hold a reference on the mm itself
and drop it at file->release() time. But, the IOMMU driver holds a
reference on the mm itself, not the address space. The address space (and
the PASID) is long gone by the time the driver tries to clean up. This is
effectively a use-after-free bug on the PASID.
To fix this, move the PASID free operation from __mmput() to __mmdrop().
This ensures that the IOMMU driver's existing mmgrab() keeps the PASID
allocated until it drops its mm reference.
Fixes: 701fac40384f ("iommu/sva: Assign a PASID to mm on PASID allocation and free it on mm exit")
Reported-by: Zhangfei Gao <zhangfei.gao@foxmail.com>
Suggested-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Suggested-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Zhangfei Gao <zhangfei.gao@foxmail.com>
Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Link: https://lore.kernel.org/r/20220428180041.806809-1-fenghua.yu@intel.com
---
kernel/fork.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index 9796897..35a3bef 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -792,6 +792,7 @@ void __mmdrop(struct mm_struct *mm)
mmu_notifier_subscriptions_destroy(mm);
check_mm(mm);
put_user_ns(mm->user_ns);
+ mm_pasid_drop(mm);
free_mm(mm);
}
EXPORT_SYMBOL_GPL(__mmdrop);
@@ -1190,7 +1191,6 @@ static inline void __mmput(struct mm_struct *mm)
}
if (mm->binfmt)
module_put(mm->binfmt->module);
- mm_pasid_drop(mm);
mmdrop(mm);
}
^ permalink raw reply related [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-05-06 7:27 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-28 18:00 [PATCH v2] iommu/sva: Fix PASID use-after-free issue Fenghua Yu
2022-04-28 18:00 ` Fenghua Yu
2022-04-29 1:39 ` Zhangfei Gao
2022-04-29 1:39 ` Zhangfei Gao
2022-05-06 1:49 ` Zhangfei Gao
2022-05-06 1:49 ` Zhangfei Gao
2022-05-06 7:27 ` Thomas Gleixner
2022-05-06 7:27 ` Thomas Gleixner
2022-05-01 8:25 ` [tip: core/urgent] mm: " tip-bot2 for Fenghua Yu
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.