Received: by 10.192.165.148 with SMTP id m20csp5040437imm; Tue, 24 Apr 2018 12:37:27 -0700 (PDT) X-Google-Smtp-Source: AIpwx49xTyQCfS0PcpfxTleCGLcv1RLHwxCJgvX9OPYWngfSZCKqMCpOkEg3KDCh1JZU14fCFCed X-Received: by 10.98.160.150 with SMTP id p22mr17346620pfl.9.1524598647762; Tue, 24 Apr 2018 12:37:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524598647; cv=none; d=google.com; s=arc-20160816; b=0sICqUYZpGxUDxzAyPZhYNXWcktnI7XzwBPd1TdgD6KxFdT9aVKPcNzPqAcEjLvLhm +TFNfaqPEoaEtmmCcx3ZZi19IZOo/STetatkGKgxaVgFSvRjopLrm/F6baz/lRFfCp1J WXqNVEMq31O/YHJomLVp/n9CvtRduU//3u9CTqyNCr7dNjKm/7Cr7aZvNQQ6Df5AqxCT Z4Xhqz8dEroLJp1ZbpmzjM3uTwTVs8hP1yAlb0lzYQmxQk5U6bnO/nYodE5smLEAs3xD hQWvMK1ByubouKo7hAmb/xLJBJddWcmVnEHBkbEhYDhKDn6lZSHSpc0UOJySVDbHu/B3 cWTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=l5S6bU6q32h4CSqtPNwYztWK5dcHp01TRqRht4p44Wg=; b=jcKMi7nhkLyPXJtZWSCGZxs5lNR0ExbKMlDqXPEFhtaN1e7eJ/amorHe58z7ihGxaa StVaGVR/Wgxnd0uzqfTUZRhHgD72WUiQaag+3FeUTWYprJyKNwaH/1L+zmlAmGaRx8eI O1VLuxsKctlpBO8yz+BvKIryuFTaDXTDJudfjz7dsKVc8snmufVcJU/jQeHJawDSg6O3 Ui04fx0HnM7ytTd3WsBWiFF1RxREnsxFg57O9gGWgud474q2fbO1oT3noC8FEtLP8qSn xTiAQRsPx7I2l5bTc0mNjVmfq+H6yRiti0CJaw2gUl9bEH798Wyhm+R6aTigYM+Ohim4 3UQA== 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 v19si12284629pgc.694.2018.04.24.12.37.13; Tue, 24 Apr 2018 12:37:27 -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 S1752844AbeDXTfl (ORCPT + 99 others); Tue, 24 Apr 2018 15:35:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41922 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752187AbeDXTfQ (ORCPT ); Tue, 24 Apr 2018 15:35:16 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3BFF930BB7C9; Tue, 24 Apr 2018 19:35:16 +0000 (UTC) Received: from fidelio.ahs3.com (ovpn-117-94.phx2.redhat.com [10.3.117.94]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7A38483B3B; Tue, 24 Apr 2018 19:35:15 +0000 (UTC) From: Al Stone To: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Al Stone , "Rafael J . Wysocki" , Len Brown Subject: [PATCH v2 2/3] ACPI: ensure acpi_parse_entries_array() does not access non-existent table data Date: Tue, 24 Apr 2018 13:35:04 -0600 Message-Id: <20180424193505.6934-3-ahs3@redhat.com> In-Reply-To: <20180424193505.6934-1-ahs3@redhat.com> References: <20180424193505.6934-1-ahs3@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.47]); Tue, 24 Apr 2018 19:35:16 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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) { if (max_entries && count >= max_entries) break; -- 2.14.3