[PATCH] x86/mpx: pass 'mm' to kernel_managing_mpx_tables() in mpx_notify_unmap()

[PATCH] x86/mpx: pass 'mm' to kernel_managing_mpx_tables() in mpx_notify_unmap()

[Jarkko Sakkinen]

If mm is not the same as current->mm, mpx_notify_unmap() will yield
invalid results and at worst will lead to a crash if it gets called by
a kthread.

Cc: Dave Hansen <dave.hansen@intel.com>
Fixes: 1de4fa14ee25 ("x86, mpx: Cleanup unused bound tables")
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 arch/x86/mm/mpx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c
index 2385538e8065..15fb62657ee9 100644
--- a/arch/x86/mm/mpx.c
+++ b/arch/x86/mm/mpx.c
@@ -882,7 +882,7 @@ static int mpx_unmap_tables(struct mm_struct *mm,
  * necessary, and the 'vma' is the first vma in this range (start -> end).
  */
 void mpx_notify_unmap(struct mm_struct *mm, struct vm_area_struct *vma,
-		unsigned long start, unsigned long end)
+		      unsigned long start, unsigned long end)
 {
 	int ret;
 
@@ -890,7 +890,7 @@ void mpx_notify_unmap(struct mm_struct *mm, struct vm_area_struct *vma,
 	 * Refuse to do anything unless userspace has asked
 	 * the kernel to help manage the bounds tables,
 	 */
-	if (!kernel_managing_mpx_tables(current->mm))
+	if (!kernel_managing_mpx_tables(mm))
 		return;
 	/*
 	 * This will look across the entire 'start -> end' range,
-- 
2.19.1

Re: [PATCH] x86/mpx: pass 'mm' to kernel_managing_mpx_tables() in mpx_notify_unmap()

[Dave Hansen]

On 12/3/18 12:43 PM, Jarkko Sakkinen wrote:
> If mm is not the same as current->mm, mpx_notify_unmap() will yield
> invalid results and at worst will lead to a crash if it gets called by
> a kthread.

It's also worth noting that this does not fix any actual,
end-user-visible bug today.  It really only prepares the code for the
case where it is called for a different mm than current->mm.

> --- a/arch/x86/mm/mpx.c
> +++ b/arch/x86/mm/mpx.c
> @@ -882,7 +882,7 @@ static int mpx_unmap_tables(struct mm_struct *mm,
>   * necessary, and the 'vma' is the first vma in this range (start -> end).
>   */
>  void mpx_notify_unmap(struct mm_struct *mm, struct vm_area_struct *vma,
> -		unsigned long start, unsigned long end)
> +		      unsigned long start, unsigned long end)
>  {
>  	int ret;

Please leave superfluous whitespace changes out of these things.

But, otherwise, this looks fine.

> Fixes: 1de4fa14ee25 ("x86, mpx: Cleanup unused bound tables")

FWIW, I'm not sure you should be submitting this separately from your
SGX series.  The deferred unmapping is really the thing that requires
the code to be changed.

Re: [PATCH] x86/mpx: pass 'mm' to kernel_managing_mpx_tables() in mpx_notify_unmap()

[Jarkko Sakkinen]

On Mon, Dec 03, 2018 at 12:49:44PM -0800, Dave Hansen wrote:
> On 12/3/18 12:43 PM, Jarkko Sakkinen wrote:
> > If mm is not the same as current->mm, mpx_notify_unmap() will yield
> > invalid results and at worst will lead to a crash if it gets called by
> > a kthread.
> 
> It's also worth noting that this does not fix any actual,
> end-user-visible bug today.  It really only prepares the code for the
> case where it is called for a different mm than current->mm.
> 
> > --- a/arch/x86/mm/mpx.c
> > +++ b/arch/x86/mm/mpx.c
> > @@ -882,7 +882,7 @@ static int mpx_unmap_tables(struct mm_struct *mm,
> >   * necessary, and the 'vma' is the first vma in this range (start -> end).
> >   */
> >  void mpx_notify_unmap(struct mm_struct *mm, struct vm_area_struct *vma,
> > -		unsigned long start, unsigned long end)
> > +		      unsigned long start, unsigned long end)
> >  {
> >  	int ret;
> 
> Please leave superfluous whitespace changes out of these things.
> 
> But, otherwise, this looks fine.
> 
> > Fixes: 1de4fa14ee25 ("x86, mpx: Cleanup unused bound tables")
> 
> FWIW, I'm not sure you should be submitting this separately from your
> SGX series.  The deferred unmapping is really the thing that requires
> the code to be changed.

Thank you for the feedback. I'll include this to the next revision of the
SGX patch set and explain why the change is needed.

/Jarkko