From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) by mx.groups.io with SMTP id smtpd.web09.2012.1610409834355721487 for ; Mon, 11 Jan 2021 16:03:54 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=tALa+INX; spf=pass (domain: apple.com, ip: 17.171.2.68, mailfrom: afish@apple.com) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 10BNx5b8031578 for ; Mon, 11 Jan 2021 16:03:53 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : message-id : date : to; s=20180706; bh=IbNoPDJ3tE6067TV9Lb6UFrxwPq8vI/MuWUoo+GoxYE=; b=tALa+INXSpmpNWa4h2qwd1lR3sYekMtuHr4LEIoEFLLaTqeaTK5mLHe1aI+4PmOfFWHe wzVeweUIHohWbxJg31rrSaq/eUVRSB7koyuT3F8OD1Y0PZYfV8zwy4kr/qOK4kWqbcvf nWxQRAt6yZCk0rjpcUDHZru+PQWNCrHSmDG9rUYCEa/LexeJm/c86zK94aSmZcXo3tCe ngH5mLqR7srwFoR5MPGKKE+cJrbLzpHOFmp0B3wuy+Qy2MuE8zsNutn/zHtRAW/LB1SG BJeT1oO5aDlf3IL5bX7hGB/Amx0Fmp7SLthC2kN3Uk2DEb8hZX5+IdHOdP9lqNfh/BZY Qg== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 35ya1w7tap-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 11 Jan 2021 16:03:53 -0800 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QMS00V9OO6G7EG0@rn-mailsvcp-mta-lapp02.rno.apple.com> for devel@edk2.groups.io; Mon, 11 Jan 2021 16:03:52 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QMS00500NY2B500@rn-mailsvcp-mmp-lapp02.rno.apple.com> for devel@edk2.groups.io; Mon, 11 Jan 2021 16:03:52 -0800 (PST) X-Va-A: X-Va-T-CD: 5975dd1eaec8696b379f33739df9e0a8 X-Va-E-CD: cb16b0ed9dace877c70a5f85247a6b65 X-Va-R-CD: e7ebf5ae7ab7769fe8ffba77b2018b0b X-Va-CD: 0 X-Va-ID: 9d68a3b8-973c-4dd3-9358-7d96e7f35b23 X-V-A: X-V-T-CD: 5975dd1eaec8696b379f33739df9e0a8 X-V-E-CD: cb16b0ed9dace877c70a5f85247a6b65 X-V-R-CD: e7ebf5ae7ab7769fe8ffba77b2018b0b X-V-CD: 0 X-V-ID: 8f9c9c61-42fd-4b13-93cf-07f6bb5252d4 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343,18.0.737 definitions=2021-01-11_34:2021-01-11,2021-01-11 signatures=0 Received: from [17.235.18.245] (unknown [17.235.18.245]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QMS00QIIO6GBW00@rn-mailsvcp-mmp-lapp02.rno.apple.com> for devel@edk2.groups.io; Mon, 11 Jan 2021 16:03:52 -0800 (PST) From: "Andrew Fish" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) Subject: Is CoreValidateHandle() safe? Message-id: <3BAF6AE3-F864-453D-8442-779442E9E342@apple.com> Date: Mon, 11 Jan 2021 16:03:51 -0800 To: edk2-devel-groups-io X-Mailer: Apple Mail (2.3654.20.0.2.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343,18.0.737 definitions=2021-01-11_34:2021-01-11,2021-01-11 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_90B3B2FC-4A2A-41D6-8ABC-47B861E1C718" --Apple-Mail=_90B3B2FC-4A2A-41D6-8ABC-47B861E1C718 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I just hit the CR ASSERT [1] in CoreValidateHandle(). It looks like the = IHANDLE was a use after free as it was a Pool buffer that was to small = to be an IHANDLE and it did not have a valid handle.=20 I=E2=80=99m trying to understand why it is safe to walk the gHandleList = without a lock? Seems like a local could cache a pointer and an event = could remove a handle and Link would point to a stale handle? Kind of feels like I=E2=80=99m missing something? [1] = https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Hand/H= andle.c#L64 EFI_STATUS CoreValidateHandle ( IN EFI_HANDLE UserHandle ) { IHANDLE *Handle; LIST_ENTRY *Link; if (UserHandle =3D=3D NULL) { return EFI_INVALID_PARAMETER; } for (Link =3D gHandleList.BackLink; Link !=3D &gHandleList; Link =3D = Link->BackLink) { Handle =3D CR (Link, IHANDLE, AllHandles, EFI_HANDLE_SIGNATURE); if (Handle =3D=3D (IHANDLE *) UserHandle) { return EFI_SUCCESS; } } return EFI_INVALID_PARAMETER; } Thanks, Andrew Fish= --Apple-Mail=_90B3B2FC-4A2A-41D6-8ABC-47B861E1C718 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I just hit the CR ASSERT [1] in CoreValidateHandle(). It = looks like the IHANDLE was a use after free as it was a Pool buffer that = was to small to be an IHANDLE and it did not have a valid = handle. 

I=E2=80=99m trying to understand why it is safe to walk the = gHandleList without a lock? Seems like a local could cache a pointer and = an event could remove a handle and Link would point to a stale = handle?

Kind = of feels like I=E2=80=99m missing something?

[1] https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core= /Dxe/Hand/Handle.c#L64
EFI_STATUS
CoreValidateHandle = (
IN EFI_HANDLE = UserHandle
)
{
IHANDLE *Handle;
LIST_ENTRY = *Link;
if (UserHandle =3D=3D = NULL) {
return = EFI_INVALID_PARAMETER;
}
for (Link =3D gHandleList.BackLink= ; Link !=3D &gHandleList; Link =3D Link->BackLink= ) {
Handle =3D CR (Link, IHANDLE, = AllHandles, EFI_HANDLE_SIGNATURE);
if (Handle =3D=3D = (IHANDLE *) UserHandle) {
return = EFI_SUCCESS;
}
}
return = EFI_INVALID_PARAMETER;
}

Thanks,

Andrew Fish
= --Apple-Mail=_90B3B2FC-4A2A-41D6-8ABC-47B861E1C718--