Received: by 10.192.165.148 with SMTP id m20csp4325895imm; Mon, 30 Apr 2018 16:28:51 -0700 (PDT) X-Google-Smtp-Source: AB8JxZryKVmkbnViD0eGvOhKxWktulK45IIUbOhMemEYU9hgnPt/irmOLwXkrg8nUDM7MOBs1/Fr X-Received: by 10.98.135.133 with SMTP id i127mr13767926pfe.201.1525130931628; Mon, 30 Apr 2018 16:28:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525130931; cv=none; d=google.com; s=arc-20160816; b=i+jiCkD/2VLIrk13cdgkQVB4xPfFGYnEMP/1HtuSrBCUJX3jOh4RkVvJ++FEhtcojS PP13ag5VNJ0fU7SBILE2BlC5wqQsHZKJ23UVV3SXGwziCSpXHcdFdUpSpAtTninVRleu a0OThUSyfFEv08TYWLcO96yuVu1Oa6TE6Wx2vryn3TANFy2bbuG2LxAJb6ZmVeJa7cfh bxj1TIqJQUCDO3QhcYD3O+oldZI7TAa+rYaLLy7M+qrG/ou21gSlb0x5yhd475aa8PZo dt7qOIhY5w8l9CAwkA4ZssiebENVjNxEff7k7+HL7r1LHll2HF3m9TON10AKrZ3pu9Nq kTRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject:reply-to :arc-authentication-results; bh=Nw/2S79fTmjZXXO2OHwggAn/OhuntNMz3qvLDmrSfLM=; b=n9dlvR/g3zxtJONSoDd1ww6W1sgj3x3DG6dqYq5Vx5acqkIpAIIlXZfCtl/dhhOigS TMt5LeS8PZM8oYjBgtUuBgP+BLC3FtFocpALWpKqk1A17XgKPciqoSXKpKH7/0V2ZM8w UEqEjZY3GOIC8qDMQ2oWJxSto3XGnLGq23gbvH39+CzwFctBJu+mX5/XyVUvJZj9sKgI yW3sl+FA5b5hhubGhKCATEbis07vZskQ5+ExRhnuO7tynE0s4+oVOFrAHUExt+tpV0G8 Bd/9l2QTgF0gWGQ5LEnPK7TEwRGtjnvHmA7iAK3YdwJ76zjG+vP/MOfI4niIVl3Ff3gW r2Kg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g3-v6si6873613pgr.635.2018.04.30.16.28.37; Mon, 30 Apr 2018 16:28:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755558AbeD3X2W (ORCPT + 99 others); Mon, 30 Apr 2018 19:28:22 -0400 Received: from mail-io0-f196.google.com ([209.85.223.196]:34068 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752614AbeD3X2U (ORCPT ); Mon, 30 Apr 2018 19:28:20 -0400 Received: by mail-io0-f196.google.com with SMTP id p124-v6so12130531iod.1 for ; Mon, 30 Apr 2018 16:28:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:cc:references:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Nw/2S79fTmjZXXO2OHwggAn/OhuntNMz3qvLDmrSfLM=; b=Zdb0hLitKd5EeJPt+ZK+KHvJZxR5UUjTafonq70j2xtRzl6Efw2RvFtky0fWyixwku GlYmf4hesuzYBd6GzboqDPS5aI7qpW6mZwhSu+AYt0aGeJlzX1PNGmgOQ2JpSzEeeDKf x1MB715TSxxHdUVlI5tPg53WjEN7KipDqPTwnjkF+klXCZD3FHN5YNQLkWnOToSzFT5G SK1NFqRv33Usb7GCWmEPkmsFEQ/dF4PIqQE3YJWRhGkiXv+yOjMf07Ayg5KXcx2BMtVk Rs5ujP+Yq4NI8BflwH4K6p6QNQvYbO5q3YwWYcZg8pMMTI0AJRVLwUQP7Wb5SgQWmDwy F6FA== X-Gm-Message-State: ALQs6tDuoVSL+VK8CbPWMMpXFMYfGR/+tl/fqOZ8GwW1NpZrM4w+RlBI 8RBtBlVcgP08fGNR9vSOeYCEsQ== X-Received: by 2002:a6b:3a1:: with SMTP id e33-v6mr15036521ioi.51.1525130899901; Mon, 30 Apr 2018 16:28:19 -0700 (PDT) Received: from fidelio.ahs3 (c-67-165-232-89.hsd1.co.comcast.net. [67.165.232.89]) by smtp.gmail.com with ESMTPSA id n67-v6sm4251022ioe.20.2018.04.30.16.28.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Apr 2018 16:28:18 -0700 (PDT) Reply-To: ahs3@redhat.com Subject: Re: [PATCH v2 2/3] ACPI: ensure acpi_parse_entries_array() does not access non-existent table data To: "Rafael J. Wysocki" Cc: ACPI Devel Maling List , Linux Kernel Mailing List , "Rafael J . Wysocki" , Len Brown References: <20180424193505.6934-1-ahs3@redhat.com> <20180424193505.6934-3-ahs3@redhat.com> From: Al Stone Organization: Red Hat, Inc. Message-ID: Date: Mon, 30 Apr 2018 17:28:18 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/27/2018 05:05 AM, Rafael J. Wysocki wrote: > On Tue, Apr 24, 2018 at 9:35 PM, Al Stone wrote: >> For ACPI tables that have subtables, acpi_parse_entries_array() gets used >> to step through each of the subtables in memory. The primary loop for this >> was checking that the beginning location of the subtable being examined >> plus the length of struct acpi_subtable_header was not beyond the end of >> the complete ACPI table; if it wasn't, the subtable could be examined, but >> if it was the loop would terminate as it should. >> >> In the middle of this subtable loop, a callback is used to examine the >> subtable in detail. >> >> Should the callback function try to examine elements of the subtable that >> are located past the subtable header, and the ACPI table containing this >> subtable has an incorrect length, it is possible to access either invalid >> or protected memory and cause a fault. And, the length of struct >> acpi_subtable_header will always be smaller than the length of the actual >> subtable. >> >> To fix this, we make the main loop check that the beginning of the >> subtable being examined plus the actual length of the subtable does >> not go past the end of the enclosing ACPI table. While this cannot >> protect us from malicious callback functions, it can prevent us from >> failing because of some poorly constructed ACPI tables. >> >> Found by inspection. There is no functional change to existing code >> that is known to work when calling acpi_parse_entries_array(). >> >> Signed-off-by: Al Stone >> Cc: Rafael J. Wysocki >> Cc: Len Brown >> --- >> drivers/acpi/tables.c | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c >> index 21535762b890..c7b028f231a6 100644 >> --- a/drivers/acpi/tables.c >> +++ b/drivers/acpi/tables.c >> @@ -271,8 +271,7 @@ acpi_parse_entries_array(char *id, unsigned long table_size, >> entry = (struct acpi_subtable_header *) >> ((unsigned long)table_header + table_size); >> >> - while (((unsigned long)entry) + sizeof(struct acpi_subtable_header) < >> - table_end) { >> + while (((unsigned long)entry + entry->length) <= table_end) { > > The inner parens are not needed. Pure paranoia on my part. Will fix. >> if (max_entries && count >= max_entries) >> break; >> >> -- -- ciao, al ----------------------------------- Al Stone Software Engineer Red Hat, Inc. ahs3@redhat.com -----------------------------------