[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <11728bc1-7b59-1623-b517-d1a0d57eb275@intel.com>
Date: Mon, 19 Dec 2022 08:22:01 +0000
From: "Wang, Zhi A" <zhi.a.wang@...el.com>
To: Zheng Wang <zyytlz.wz@....com>
CC: "1002992920@...com" <1002992920@...com>,
"airlied@...il.com" <airlied@...il.com>,
"airlied@...ux.ie" <airlied@...ux.ie>,
"alex000young@...il.com" <alex000young@...il.com>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"hackerzheng666@...il.com" <hackerzheng666@...il.com>,
"intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
"intel-gvt-dev@...ts.freedesktop.org"
<intel-gvt-dev@...ts.freedesktop.org>,
"joonas.lahtinen@...ux.intel.com" <joonas.lahtinen@...ux.intel.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"security@...nel.org" <security@...nel.org>,
"tvrtko.ursulin@...ux.intel.com" <tvrtko.ursulin@...ux.intel.com>,
"zhenyuw@...ux.intel.com" <zhenyuw@...ux.intel.com>
Subject: Re: [Intel-gfx] [PATCH v3] drm/i915/gvt: fix double free bug in
split_2MB_gtt_entry
On 12/19/2022 9:57 AM, Zheng Wang wrote:
> Hi Zhi,
>
> Thanks again for your reply and clear explaination about the function.
> I still have some doubt about the fix. Here is a invoke chain :
> ppgtt_populate_spt
> ->ppgtt_populate_shadow_entry
> ->split_2MB_gtt_entry
> As far as I'm concerned, when something error happens in DMA mapping,
> which will make intel_gvt_dma_map_guest_page return none-zero code,
> It will invoke ppgtt_invalidate_spt and call ppgtt_free_spt,which will
> finally free spt by kfree. But the caller doesn't notice that and frees
> spt by calling ppgtt_free_spt again. This is a typical UAF/Double Free
> vulnerability. So I think the key point is about how to handle spt properly.
> The handle newly allocated spt (aka sub_spt) is not the root cause of this
> issue. Could you please give me more advice about how to fix this security
> bug? Besides, I'm not sure if there are more similar problems in othe location.
>
> Best regards,
> Zheng Wang
>
I think it is a case-by-case thing. For example:
The current scenario in this function looks like below:
caller pass spt a
function
alloc spt b
something error
free spt a
return error
The problem is: the function wrongly frees the spt a instead free what
it allocates.
A proper fix should be:
caller pass spt a
function
alloc spt b
something error
*free spt b*
return error
Thanks,
Zhi.
Powered by blists - more mailing lists