2022-11-09 09:14:33

by Zheng Wang

[permalink] [raw]
Subject: [PATCH v6 RESEND] misc: sgi-gru: fix use-after-free error in gru_set_context_option, gru_fault and gru_handle_user_call_os

Gts may be freed in gru_check_chiplet_assignment.
The caller still use it after that, UAF happens.

Fix it by introducing a return value to see if it's in error path or not.
Free the gts in caller if gru_check_chiplet_assignment check failed.

Fixes: 55484c45dbec ("gru: allow users to specify gru chiplet 2")
Reported-by: Zheng Wang <[email protected]>
Reported-by: kernel test robot <[email protected]>

Signed-off-by: Zheng Wang <[email protected]>
Acked-by: Dimitri Sivanich <[email protected]>
---
v6:
- remove unused var checked by kernel test robot

v5:
- fix logical issue and remove unnecessary variable suggested by Dimitri Sivanich

v4:
- use VM_FAULT_NOPAGE as failure code in gru_fault and -EINVAL in other functions suggested by Yejian

v3:
- add preempt_enable and use VM_FAULT_NOPAGE as failure code suggested by Yejian

v2:
- commit message changes suggested by Greg

v1: https://lore.kernel.org/lkml/CAJedcCzY72jqgF-pCPtx66vXXwdPn-KMagZnqrxcpWw1NxTLaA@mail.gmail.com/
---
drivers/misc/sgi-gru/grufault.c | 14 ++++++++++++--
drivers/misc/sgi-gru/grumain.c | 16 ++++++++++++----
drivers/misc/sgi-gru/grutables.h | 2 +-
3 files changed, 25 insertions(+), 7 deletions(-)

diff --git a/drivers/misc/sgi-gru/grufault.c b/drivers/misc/sgi-gru/grufault.c
index d7ef61e602ed..bdd515d33225 100644
--- a/drivers/misc/sgi-gru/grufault.c
+++ b/drivers/misc/sgi-gru/grufault.c
@@ -656,7 +656,9 @@ int gru_handle_user_call_os(unsigned long cb)
if (ucbnum >= gts->ts_cbr_au_count * GRU_CBR_AU_SIZE)
goto exit;

- gru_check_context_placement(gts);
+ ret = gru_check_context_placement(gts);
+ if (ret)
+ goto err;

/*
* CCH may contain stale data if ts_force_cch_reload is set.
@@ -677,6 +679,10 @@ int gru_handle_user_call_os(unsigned long cb)
exit:
gru_unlock_gts(gts);
return ret;
+err:
+ gru_unlock_gts(gts);
+ gru_unload_context(gts, 1);
+ return -EINVAL;
}

/*
@@ -874,7 +880,11 @@ int gru_set_context_option(unsigned long arg)
} else {
gts->ts_user_blade_id = req.val1;
gts->ts_user_chiplet_id = req.val0;
- gru_check_context_placement(gts);
+ if (gru_check_context_placement(gts)) {
+ gru_unlock_gts(gts);
+ gru_unload_context(gts, 1);
+ return -EINVAL;
+ }
}
break;
case sco_gseg_owner:
diff --git a/drivers/misc/sgi-gru/grumain.c b/drivers/misc/sgi-gru/grumain.c
index 9afda47efbf2..beba69fc3cd7 100644
--- a/drivers/misc/sgi-gru/grumain.c
+++ b/drivers/misc/sgi-gru/grumain.c
@@ -716,9 +716,10 @@ static int gru_check_chiplet_assignment(struct gru_state *gru,
* chiplet. Misassignment can occur if the process migrates to a different
* blade or if the user changes the selected blade/chiplet.
*/
-void gru_check_context_placement(struct gru_thread_state *gts)
+int gru_check_context_placement(struct gru_thread_state *gts)
{
struct gru_state *gru;
+ int ret = 0;

/*
* If the current task is the context owner, verify that the
@@ -727,14 +728,16 @@ void gru_check_context_placement(struct gru_thread_state *gts)
*/
gru = gts->ts_gru;
if (!gru || gts->ts_tgid_owner != current->tgid)
- return;
+ return ret;

if (!gru_check_chiplet_assignment(gru, gts)) {
STAT(check_context_unload);
- gru_unload_context(gts, 1);
+ ret = -EINVAL;
} else if (gru_retarget_intr(gts)) {
STAT(check_context_retarget_intr);
}
+
+ return ret;
}


@@ -934,7 +937,12 @@ vm_fault_t gru_fault(struct vm_fault *vmf)
mutex_lock(&gts->ts_ctxlock);
preempt_disable();

- gru_check_context_placement(gts);
+ if (gru_check_context_placement(gts)) {
+ preempt_enable();
+ mutex_unlock(&gts->ts_ctxlock);
+ gru_unload_context(gts, 1);
+ return VM_FAULT_NOPAGE;
+ }

if (!gts->ts_gru) {
STAT(load_user_context);
diff --git a/drivers/misc/sgi-gru/grutables.h b/drivers/misc/sgi-gru/grutables.h
index 5efc869fe59a..f4a5a787685f 100644
--- a/drivers/misc/sgi-gru/grutables.h
+++ b/drivers/misc/sgi-gru/grutables.h
@@ -632,7 +632,7 @@ extern int gru_user_flush_tlb(unsigned long arg);
extern int gru_user_unload_context(unsigned long arg);
extern int gru_get_exception_detail(unsigned long arg);
extern int gru_set_context_option(unsigned long address);
-extern void gru_check_context_placement(struct gru_thread_state *gts);
+extern int gru_check_context_placement(struct gru_thread_state *gts);
extern int gru_cpu_fault_map_id(void);
extern struct vm_area_struct *gru_find_vma(unsigned long vaddr);
extern void gru_flush_all_tlb(struct gru_state *gru);
--
2.25.1



2022-11-09 09:41:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH v6 RESEND] misc: sgi-gru: fix use-after-free error in gru_set_context_option, gru_fault and gru_handle_user_call_os

On Wed, Nov 09, 2022 at 04:41:42PM +0800, Zheng Wang wrote:
> Gts may be freed in gru_check_chiplet_assignment.
> The caller still use it after that, UAF happens.
>
> Fix it by introducing a return value to see if it's in error path or not.
> Free the gts in caller if gru_check_chiplet_assignment check failed.
>
> Fixes: 55484c45dbec ("gru: allow users to specify gru chiplet 2")
> Reported-by: Zheng Wang <[email protected]>
> Reported-by: kernel test robot <[email protected]>
>

Why the blank line?

And the kernel test robot didn't find this issue, right?

> Signed-off-by: Zheng Wang <[email protected]>
> Acked-by: Dimitri Sivanich <[email protected]>

You can not have a reported-by and a signed-off-by for the same person
with different email addresses. You do not need both if it is you, just
use the signed-off-by line.

thanks,

greg k-h

2022-11-09 10:01:00

by Zheng Hacker

[permalink] [raw]
Subject: Re: [PATCH v6 RESEND] misc: sgi-gru: fix use-after-free error in gru_set_context_option, gru_fault and gru_handle_user_call_os

Greg KH <[email protected]> 于2022年11月9日周三 16:46写道:
>
> On Wed, Nov 09, 2022 at 04:41:42PM +0800, Zheng Wang wrote:
> > Gts may be freed in gru_check_chiplet_assignment.
> > The caller still use it after that, UAF happens.
> >
> > Fix it by introducing a return value to see if it's in error path or not.
> > Free the gts in caller if gru_check_chiplet_assignment check failed.
> >
> > Fixes: 55484c45dbec ("gru: allow users to specify gru chiplet 2")
> > Reported-by: Zheng Wang <[email protected]>
> > Reported-by: kernel test robot <[email protected]>
> >
>
> Why the blank line?

> Sorry for the spelling problem, fixed it next version

> And the kernel test robot didn't find this issue, right?
>

Yes, it helped with the test and found an unused variable. I added
this line as the mail suggested
("If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <[email protected]>").

Should I remove it?

> > Signed-off-by: Zheng Wang <[email protected]>
> > Acked-by: Dimitri Sivanich <[email protected]>
>
> You can not have a reported-by and a signed-off-by for the same person
> with different email addresses. You do not need both if it is you, just
> use the signed-off-by line.
>

Thanks very much for your explaination. I'll send another patch as
soon as possible.

Best Regards,
Zheng Wang

2022-11-09 11:08:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH v6 RESEND] misc: sgi-gru: fix use-after-free error in gru_set_context_option, gru_fault and gru_handle_user_call_os

On Wed, Nov 09, 2022 at 05:24:05PM +0800, Zheng Hacker wrote:
> Greg KH <[email protected]> 于2022年11月9日周三 16:46写道:
> >
> > On Wed, Nov 09, 2022 at 04:41:42PM +0800, Zheng Wang wrote:
> > > Gts may be freed in gru_check_chiplet_assignment.
> > > The caller still use it after that, UAF happens.
> > >
> > > Fix it by introducing a return value to see if it's in error path or not.
> > > Free the gts in caller if gru_check_chiplet_assignment check failed.
> > >
> > > Fixes: 55484c45dbec ("gru: allow users to specify gru chiplet 2")
> > > Reported-by: Zheng Wang <[email protected]>
> > > Reported-by: kernel test robot <[email protected]>
> > >
> >
> > Why the blank line?
>
> > Sorry for the spelling problem, fixed it next version
>
> > And the kernel test robot didn't find this issue, right?
> >
>
> Yes, it helped with the test and found an unused variable. I added
> this line as the mail suggested
> ("If you fix the issue, kindly add following tag where applicable
> | Reported-by: kernel test robot <[email protected]>").
>
> Should I remove it?

If you submit a patch that just fixes the issue that the test robot
finds, yes, that needs to be there. If you are fixing up a patch that
you submit based on the report, no, you do not.

thanks,

greg k-h