| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAJedcCxGkz6i2LeCGWcHgU7P2n1TeB9gKVZCzmjPPJK=hhsfLA@mail.gmail.com>
Date: Tue, 27 Sep 2022 22:12:58 +0800
From: Zheng Hacker <hackerzheng666@...il.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Zheng Wang <zyytlz.wz@....com>, dimitri.sivanich@....com,
arnd@...db.de, linux-kernel@...r.kernel.org,
alex000young@...il.com, security@...nel.org
Subject: Re: [PATCH] misc: sgi-gru: fix use-after-free error in
gru_set_context_option, gru_fault and gru_handle_user_call_os
Hi Greg,
I've resent the patch. Could you please review it and apply if there
is no more problem?
Thanks,
Zheng Wang
Greg KH <gregkh@...uxfoundation.org> 于2022年9月26日周一 16:36写道：
>
> On Mon, Sep 26, 2022 at 12:36:18PM +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.
> >
> > Reported-by: Zheng Wang <hackerzheng666@...il.com>
> >
> > Signed-off-by: Zheng Wang <zyytlz.wz@....com>
> >
> > ---
> > drivers/misc/sgi-gru/grufault.c | 14 ++++++++++++--
> > drivers/misc/sgi-gru/grumain.c | 17 +++++++++++++----
> > drivers/misc/sgi-gru/grutables.h | 2 +-
> > 3 files changed, 26 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/misc/sgi-gru/grufault.c b/drivers/misc/sgi-gru/grufault.c
> > index d7ef61e602ed..2b5b049fbd38 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,7 @@ 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);
> > + ret = gru_check_context_placement(gts);
> > }
> > break;
> > case sco_gseg_owner:
> > @@ -889,6 +895,10 @@ int gru_set_context_option(unsigned long arg)
> > ret = -EINVAL;
> > }
> > gru_unlock_gts(gts);
> > + if (ret) {
> > + gru_unload_context(gts, 1);
> > + ret = -EINVAL;
> > + }
> >
> > return ret;
> > }
> > diff --git a/drivers/misc/sgi-gru/grumain.c b/drivers/misc/sgi-gru/grumain.c
> > index 9afda47efbf2..79903cf7e706 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;
> > }
> >
> >
> > @@ -919,6 +922,7 @@ vm_fault_t gru_fault(struct vm_fault *vmf)
> > struct gru_thread_state *gts;
> > unsigned long paddr, vaddr;
> > unsigned long expires;
> > + int ret;
> >
> > vaddr = vmf->address;
> > gru_dbg(grudev, "vma %p, vaddr 0x%lx (0x%lx)\n",
> > @@ -934,7 +938,12 @@ vm_fault_t gru_fault(struct vm_fault *vmf)
> > mutex_lock(>s->ts_ctxlock);
> > preempt_disable();
> >
> > - gru_check_context_placement(gts);
> > + ret = gru_check_context_placement(gts);
> > + if (ret) {
> > + mutex_unlock(>s->ts_ctxlock);
> > + gru_unload_context(gts, 1);
> > + return ret;
> > + }
> >
> > 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
> >
> >
>
> Hi,
>
> This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
> a patch that has triggered this response. He used to manually respond
> to these common problems, but in order to save his sanity (he kept
> writing the same thing over and over, yet to different people), I was
> created. Hopefully you will not take offence and will fix the problem
> in your patch and resubmit it so that it can be accepted into the Linux
> kernel tree.
>
> You are receiving this message because of the following common error(s)
> as indicated below:
>
> - This looks like a new version of a previously submitted patch, but you
> did not list below the --- line any changes from the previous version.
> Please read the section entitled "The canonical patch format" in the
> kernel file, Documentation/SubmittingPatches for what needs to be done
> here to properly describe this.
>
> If you wish to discuss this problem further, or you have questions about
> how to resolve this issue, please feel free to respond to this email and
> Greg will reply once he has dug out from the pending patches received
> from other developers.
>
> thanks,
>
> greg k-h's patch email bot
Powered by blists - more mailing lists