Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1161558imm; Tue, 15 May 2018 14:54:28 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqwMA2pwhfxM4TCSqVTBnwFgt2jKTIVn7r/bvP0mUQv1yKaTONLvTfnhKpOnAkKJ+X49aXX X-Received: by 2002:a65:5008:: with SMTP id f8-v6mr9853460pgo.349.1526421268636; Tue, 15 May 2018 14:54:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526421268; cv=none; d=google.com; s=arc-20160816; b=DdWrw7RMx6nsnjBEzIvDfW/9AVZhV7XylTHuchnF8nb7JgVzCyMOUwzKZ4CbLNmTdy Nt52zZ1Z862vhXlU6ZTwfzMVCeuKOe/wuCrfAAKmaBdDQ5GQlBNBOWP0RlDVTLTdYEv9 JxvQixOClOhRCfMvUi7mNCHGLpFkphM0FwyaIUmVpvVtQtlMArcdHJfHzsaViV8NPDwO Y+BUZUSwzkDFGDKWFt8FDF1eUuo2A1tn1E2L6pWUJHSj65RO2ytw05FOYGKSbCP6FicE +cZqOXtntkCf3BDUOcXwFaiy0ZYuup7+hCkdnQ9es5INR6XxPC+XDo1BOWsaMVWETymV yMrw== 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=oD9faeROBWi9vDTPRC4K9DSCU9E4pL3iun38UXvWx9Q=; b=J2HxKzYbRtfsehfmYnvbXWCNwb7k6cKbFQK7AGhcUauVzrUAoksCSOM95KxQ2y14oP Jis8ifz4x0KaBnjsDLF1tAqbXy//A5nmyfWKoJN4QD+bze6kUrSxHg4HpFk7IWKB5VZ+ o6t7kKSnAZuN2cg7MH6+VERObUruwPMAbDtN0oOQTK6htFP0ButYPf54xlz7WTzBHMTR 83lJQQda2k5/nTa/N+sz6YtYNRLYwSQaI/9QqDbGGuGRcHFGOQc0E4ASAbaUg6SeIVTe b5XDf2C2vf2nxCMojpXFvj+ZQ57GH30DpELhU20GsZz0fFA8yMeqrH8I75/4Hz46QJIW 9aNw== 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 q62-v6si815110pgq.297.2018.05.15.14.54.14; Tue, 15 May 2018 14:54:28 -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 S1752237AbeEOVxp (ORCPT + 99 others); Tue, 15 May 2018 17:53:45 -0400 Received: from mail-it0-f65.google.com ([209.85.214.65]:35679 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751868AbeEOVxn (ORCPT ); Tue, 15 May 2018 17:53:43 -0400 Received: by mail-it0-f65.google.com with SMTP id q72-v6so5818740itc.0 for ; Tue, 15 May 2018 14:53:43 -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=oD9faeROBWi9vDTPRC4K9DSCU9E4pL3iun38UXvWx9Q=; b=rGQvR0uK9MzRdPG+pTqu1yLoiINArTBVWderQPyIfKoy17jEwE+JQIHzsbsYVmYeVk 9obnGILZEnkEOk/iHeBjzW4B1PKdhdkZcbls4D7IzfVoddCiI9Ak8egFY+lBoQIKPtYE imWLV+poCS8CGf2oKEaPuMlAEw72U4A/5bsosnnUSWIZ0CJa7wKoKMZOnrpk0QmjJfsr OdWNaDf6/7fGpJRvKnw7HdX3b+40/WH16s9iWp2D9ugsGBAkvvOz3sO3oIUrdwqOuS4j xbWh6mVoteDhYOW2tNvI03IjeHEk4LFIRSBODsfogXMxj3NuSoFhC0+aTsYEa7OOmDjo X+RA== X-Gm-Message-State: ALKqPwd8FhGzfdzBQp25J50b2NSED3T6RBU8XWCFOXbrHvlknQ/R6lgh TzdfojQwpJf9dqAxJtSHaWl4nQ== X-Received: by 2002:a24:8d85:: with SMTP id w127-v6mr15640960itd.22.1526421223075; Tue, 15 May 2018 14:53:43 -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 k17-v6sm1401183ioo.42.2018.05.15.14.53.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 May 2018 14:53:42 -0700 (PDT) Reply-To: ahs3@redhat.com Subject: Re: [PATCH v3 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: <20180501003907.4322-1-ahs3@redhat.com> <20180501003907.4322-3-ahs3@redhat.com> From: Al Stone Organization: Red Hat, Inc. Message-ID: <04afae30-7012-ebb9-cd0e-3ec39bfd955c@redhat.com> Date: Tue, 15 May 2018 15:53:41 -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 05/15/2018 11:19 AM, Rafael J. Wysocki wrote: > On Tue, May 1, 2018 at 2:39 AM, 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 4a3410aa6540..82c3e2c52dd9 100644 >> --- a/drivers/acpi/tables.c >> +++ b/drivers/acpi/tables.c >> @@ -274,8 +274,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; >> >> -- > > This breaks the CPU enumeration on my Dell XPS13 9360 (possibly among > other things), so I'm dropping it. I can send you acpidump output > from that machine if need be. > > Thanks, > Rafael > Yes, please. My fear is that there are a bunch of MADT tables in the real world that aren't quite right so that while this may be theoretically correct, it may be wrong as a practical matter. -- ciao, al ----------------------------------- Al Stone Software Engineer Red Hat, Inc. ahs3@redhat.com -----------------------------------