linux-kernel - Re: [PATCH] drm/i915/gvt: fix double-free bug in split_2MB_gtt

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220907030754.GU1089@zhen-hp.sh.intel.com>
Date:   Wed, 7 Sep 2022 11:07:54 +0800
From:   Zhenyu Wang <zhenyuw@...ux.intel.com>
To:     Zheng Hacker <hackerzheng666@...il.com>
Cc:     Greg KH <gregkh@...uxfoundation.org>, alex000young@...il.com,
        security@...nel.org, dri-devel@...ts.freedesktop.org,
        tvrtko.ursulin@...ux.intel.com, airlied@...ux.ie,
        intel-gfx@...ts.freedesktop.org, joonas.lahtinen@...ux.intel.com,
        linux-kernel@...r.kernel.org, zhenyuw@...ux.intel.com,
        xmzyshypnc <1002992920@...com>, jani.nikula@...ux.intel.com,
        daniel@...ll.ch, rodrigo.vivi@...el.com,
        intel-gvt-dev@...ts.freedesktop.org, zhi.a.wang@...el.com
Subject: Re: [PATCH] drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry.

On 2022.09.06 19:36:56 +0800, Zheng Hacker wrote:
> Hi Greg,
> 
> Alex has explained how we figured out the patch. We did analyze the
> code and found it possible to reach the vulnerability code. But we
> have no physical device in hand to test the driver. So we'd like to
> discuss with developers to see if the issue exists or not.
> 
> Best regards,
> Zheng Wang.
> 
> Greg KH <gregkh@...uxfoundation.org> ???2022???9???5????????? 16:04?????????
> >
> > On Mon, Sep 05, 2022 at 03:46:09PM +0800, Zheng Hacker wrote:
> > > I rewrote the letter. Hope it works.
> > >
> > > There is a double-free security bug in split_2MB_gtt_entry.
> > >
> > > Here is a calling chain :
> > > ppgtt_populate_spt->ppgtt_populate_shadow_entry->split_2MB_gtt_entry.
> > > If intel_gvt_dma_map_guest_page failed, it will call
> > > ppgtt_invalidate_spt, which will finally call ppgtt_free_spt and
> > > kfree(spt). But the caller does not notice that, and it will call
> > > ppgtt_free_spt again in error path.
> > >

It's a little mess in code so in theory it might be possible but
intel_gvt_dma_map_guest_page won't fail in practise...

> > > Fix this by returning the result of ppgtt_invalidate_spt to split_2MB_gtt_entry.
> > >

I don't see why changing ret value can fix this issue, as it doesn't change
any behavior e.g caller of ppgtt_populate_spt to handle possible different error return.

As current code looks assuming that ppgtt_invalidate_spt would free spt in good case,
I think the real cleanup should split that assumption and handle free in error case properly.

> > > Signed-off-by: Zheng Wang

This misses proper email address.

thanks

> > >
> > > ---
> > >  drivers/gpu/drm/i915/gvt/gtt.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
> > > index ce0eb03709c3..9f14fded8c0c 100644
> > > --- a/drivers/gpu/drm/i915/gvt/gtt.c
> > > +++ b/drivers/gpu/drm/i915/gvt/gtt.c
> > > @@ -1215,7 +1215,7 @@ static int split_2MB_gtt_entry(struct intel_vgpu *vgpu,
> > >                 ret = intel_gvt_dma_map_guest_page(vgpu, start_gfn + sub_index,
> > >                                                    PAGE_SIZE, &dma_addr);
> > >                 if (ret) {
> > > -                       ppgtt_invalidate_spt(spt);
> > > +                       ret = ppgtt_invalidate_spt(spt);
> > >                         return ret;
> >
> > But now you just lost the original error, shouldn't this succeed even if
> > intel_gvt_dma_map_guest_page() failed?
> >
> > And how are you causing intel_gvt_dma_map_guest_page() to fail in a real
> > system?
> >
> > thanks,
> >
> > greg k-h

Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)