From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=216.205.24.131; helo=us-smtp-delivery-131.mimecast.com; envelope-from=herbie.robinson@stratus.com; receiver=edk2-devel@lists.01.org Received: from us-smtp-delivery-131.mimecast.com (us-smtp-delivery-131.mimecast.com [216.205.24.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id D7C0D21123860 for ; Thu, 6 Sep 2018 17:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=StratusTechnologies.onmicrosoft.com; s=selector1-stratus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GOTIFjVS5vqemIsvrlWrfE51vpv2O5ePLeBBaHjTcW8=; b=rlOywAhOCEeDgwMUIfALZMZp+vh449N1Z0FV3IeseE69K8X8VusUxM8VHV79UAOLDdKFSEVFYYCy8pKL65tgrfqlrIegoSNdUAuxkg9XSxF0cGJCn0wxkMhcEEODPvCwtlsp+IPEJcBgQAJB1N5ML/hYBjzwCIATrLvrGm9RTM8= Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-co1nam05lp0081.outbound.protection.outlook.com [216.32.181.81]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-23-51gQulPrPgWvppWnGn2AzA-1; Thu, 06 Sep 2018 20:07:11 -0400 Received: from DM6PR08MB5436.namprd08.prod.outlook.com (20.176.113.89) by DM6PR08MB5033.namprd08.prod.outlook.com (20.176.117.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1101.13; Fri, 7 Sep 2018 00:07:09 +0000 Received: from DM6PR08MB5436.namprd08.prod.outlook.com ([fe80::a0d4:6dab:e8e5:f042]) by DM6PR08MB5436.namprd08.prod.outlook.com ([fe80::a0d4:6dab:e8e5:f042%4]) with mapi id 15.20.1122.009; Fri, 7 Sep 2018 00:07:09 +0000 From: "Robinson, Herbie" To: "edk2-devel@lists.01.org" Thread-Topic: [PATCH 1/1] FatPkg/EnhancedFatDxe Fix Double Cluster Allocation Thread-Index: AdRGNugzdHiNHJwCSQCZ7Ap4/Z5afQ== Date: Fri, 7 Sep 2018 00:07:09 +0000 Message-ID: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.97.42.5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM6PR08MB5033; 20:6Z0KJMVXxkG1mgi2/h7TUZm/Ui28gIrLZxvbSdjkRUcr0b3GBRYQeOCB612dYWiDcef1qwW2BynQK0Glj0L/Qe3HezL2t1IcvZFPOUBkCkmN+tstNSEh2P7xlYkaMxc/QglaVcdhPXv9IWSA5HFn9B2L2KPVfidHIur5VCk5csM= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 9e5a81d4-1ddf-422c-fd37-08d61455daae x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:DM6PR08MB5033; x-ms-traffictypediagnostic: DM6PR08MB5033: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(17755550239193); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(3231311)(944501410)(52105095)(10201501046)(93006095)(93001095)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699016); SRVR:DM6PR08MB5033; BCL:0; PCL:0; RULEID:; SRVR:DM6PR08MB5033; x-forefront-prvs: 07880C4932 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(396003)(366004)(376002)(346002)(136003)(199004)(189003)(2501003)(2900100001)(316002)(5250100002)(81166006)(6116002)(3846002)(25786009)(66066001)(256004)(68736007)(6916009)(14454004)(97736004)(8936002)(106356001)(55016002)(14444005)(26005)(102836004)(186003)(2906002)(305945005)(7736002)(476003)(99286004)(6506007)(8676002)(74316002)(5640700003)(6436002)(478600001)(86362001)(33656002)(81156014)(53936002)(7696005)(2351001)(9686003)(105586002)(486006)(72206003)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR08MB5033; H:DM6PR08MB5436.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-microsoft-antispam-message-info: 4m764lMbuuoVeu6vpykEMNKjnJ9hKopieg13wai9OfuQ6dnHPyepsrZphi09pkoVT5p5AH+bghBllKrU41R/3FP2Gtrlr+uLRYUdrc8tVVF1eRM2VINWAq4YzUixjvm64t7FCS6/WmPsTJwGNRT9fWWjveURvz5Y4k630qlbDTNtAYywp96Lu+YMJ+EIfMOiCSgwaIO50insLMbGc/059aHZyYcWb1lkz/y+GQhOFFSOlKHGWdoUJCmgpYniqtpQArBsxDyxMCZhRSNvmcWoy5PcHERpy+ebUp73R1z6Zzn0FndkLB6kJOWqVNcLWjfJhUXka+1BItWMvCn174pWXKipu/jcJIAy/oyHnXNSpso= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: stratus.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9e5a81d4-1ddf-422c-fd37-08d61455daae X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2018 00:07:09.1149 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: de36b473-b8ad-46ff-837f-9da16b8d1b77 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB5033 X-MC-Unique: 51gQulPrPgWvppWnGn2AzA-1 Subject: [PATCH 1/1] FatPkg/EnhancedFatDxe Fix Double Cluster Allocation X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 00:07:18 -0000 Content-Language: en-US Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable This is a fix for a double cluster allocation when the disk is full. The d= ouble allocation happens because FatGrowEof calls FatAllocateCluster withou= t immediately marking the each returned cluster as allocated. The fix is t= o move the FatSetFatEntry call inside the loop. I've also include some imp= rovements to the sanity checks that I added while tracking this down. They= are optional. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by:Herbie Robinson --- diff --git a/FatPkg/EnhancedFatDxe/FileSpace.c b/FatPkg/EnhancedFatDxe/File= Space.c index 1254cd6..e17d3b6 100644 --- a/FatPkg/EnhancedFatDxe/FileSpace.c +++ b/FatPkg/EnhancedFatDxe/FileSpace.c @@ -467,7 +467,7 @@ FatGrowEof ( ClusterCount =3D 0; while (!FAT_END_OF_FAT_CHAIN (Cluster)) { - if (Cluster =3D=3D FAT_CLUSTER_FREE || Cluster >=3D FAT_CLUSTER_SP= ECIAL) { + if (Cluster < FAT_MIN_CLUSTER || Cluster > Volume->MaxCluster + 1)= { DEBUG ( (EFI_D_INIT | EFI_D_ERROR, @@ -509,6 +509,11 @@ FatGrowEof ( goto Done; } + if (NewCluster < FAT_MIN_CLUSTER || NewCluster > Volume->MaxCluster = + 1) { + Status =3D EFI_VOLUME_CORRUPTED; + goto Done; + } + if (LastCluster !=3D 0) { FatSetFatEntry (Volume, LastCluster, NewCluster); } else { @@ -518,12 +523,21 @@ FatGrowEof ( LastCluster =3D NewCluster; CurSize +=3D 1; + + // + // Terminate the cluster list + // + // Note that we must do this EVERY time we allocate a cluster, becau= se + // FatAllocateCluster scans the FAT looking for a free cluster and + // "LastCluster" is no longer free! Usually, FatAllocateCluster wil= l + // start looking with the cluster after "LastCluster"; however, when + // there is only one free cluster left, it will find "LastCluster" + // a second time. There are other, less predictable scenarios + // where this could happen, as well. + // + FatSetFatEntry (Volume, LastCluster, (UINTN) FAT_CLUSTER_LAST); + OFile->FileLastCluster =3D LastCluster; } - // - // Terminate the cluster list - // - FatSetFatEntry (Volume, LastCluster, (UINTN) FAT_CLUSTER_LAST); - OFile->FileLastCluster =3D LastCluster; } OFile->FileSize =3D (UINTN) NewSizeInBytes; @@ -603,7 +617,7 @@ FatOFilePosition ( Cluster =3D FatGetFatEntry (Volume, Cluster); } - if (Cluster < FAT_MIN_CLUSTER) { + if (Cluster < FAT_MIN_CLUSTER || Cluster > Volume->MaxCluster + 1) { return EFI_VOLUME_CORRUPTED; }