From owner-freebsd-bugs@FreeBSD.ORG Sat Feb 21 16:51:33 2015 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91718BB4 for ; Sat, 21 Feb 2015 16:51:33 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 731AABF9 for ; Sat, 21 Feb 2015 16:51:33 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t1LGpXVI040493 for ; Sat, 21 Feb 2015 16:51:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 197881] boot1.efi UEFI system table corruption Date: Sat, 21 Feb 2015 16:51:33 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: cmruffin@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 16:51:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197881 Bug ID: 197881 Summary: boot1.efi UEFI system table corruption Product: Base System Version: 10.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: cmruffin@gmail.com boot1.efi from 10.1-RELEASE can cause data corruption of its own UEFI system table pointer in memory. The EfiBlockIoProtocol instance associated with a CDROM parition typically has a block size of 2048. boot1.efi assumes a block size of 512 in the call to dskread() to read the superblock, yet the dskread() function in boot1.efi uses the block size from the BlockIoProtocol instance. This causes the call to BlkIoProtocol->ReadBlocks() in dskread() to expose a larger-than-actual buffer size to UEFI FW, which will cause the ReadBlocks() call to overrun the dmadat buffer. So if a partition is present in the system with a block size of 2048 (such as cdrom media partitions), boot1.efi can overrun its dmadat structure and cause corruption of other global data including a global pointe r to the UEFI system table. Failure sequence: 1) dmadat.sbbuf is allocated 8192 bytes at build time (SBLOCKSIZE) 2) Boot1.efi retrieves handles with all instances of BlockIoProtocol. 3) If cdrom partition is present in the system, UEFI FW will return a BlockIoProtocol of the CDROM partition which has a BlockIoProtocol->Media->BlockSize = 2048. 4) domount() is called for this BlockIoProtocol instance. 5) fsread() is called to read the superblock 6) Boot1.efi dskread() is called with nblk=16 (fixed SBLOCKSIZE (8192) / fixed DEV_BSIZE (512)). This is assuming a block size of 512. 7) dskread() in boot1.efi calls status = bootdev->ReadBlocks(bootdev, bootdev->Media->MediaId, lba, nblk * bootdev->Media->BlockSize, buf); Here nblk=16 but bootdev->Media->BlockSize is 2048 which results in passing a Buffer Size argument of 16 * 2048 = 32768 which overruns the dmadat->sbbuf fixed allocation. 8) UEFI ReaadBlocks() overruns dmadat and overwrites the global pointer to the UEFI system table (sets it to zero) 9) A subsequent call to systab->BootServices->HandleProtocol() causes path of exeution at physical address 0x98 which does not contain valid code. 10) Processor eventually raises an invalid opcode exception. -- You are receiving this mail because: You are the assignee for the bug.