Received: by 10.192.165.148 with SMTP id m20csp574541imm; Fri, 27 Apr 2018 04:08:17 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrFxOfukA0H1V/YyhVdMAYSjKRM1veHFHGf/YXR1TaCR06FWEycDojTBR4Cy4wOWczig/uc X-Received: by 2002:a63:43c6:: with SMTP id q189-v6mr1802751pga.123.1524827297631; Fri, 27 Apr 2018 04:08:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524827297; cv=none; d=google.com; s=arc-20160816; b=cVBaSen67pIzThy5Ojp0xzcs80OcJgAiBfEXXKPdvmMtyIQizgdoqcoQJb28JBSoqb HUHmnnMRGzymp/mezaA533ppC/2/oIGTakClpPJh+vDQk+NssIxymvuoHd6yB8iJDK+B ULoTnSGT5cJLeKKu94Q4xHKSY3PbWmQsSr3bNR0pSX27t32wiMDKmKUKvFDRy9XpNAUS rw0FzcggJ5INe2jTup+3LjTC5WY0DnFWoqQyeavjNT3resAny/LCx+RwKfhNYsa0nPmE o+KwYaFgLBOmCmAWPhXYdAVqNIInCI3O7UVufi52e3KaTxf6lprzD/1U86lrulzrkd4y BCoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=AcnGdVVCSx9wINn+kIjIeSfZMLsVTcJEDo56RBY/iiY=; b=z2m8DQ4QPTPviQpcwElRaiRsOEziIzi462gP1NSN8IhmVHCsSqo8k7hy03RT+XSkJI Eb50ogHgMXiom7YrxQU8ELxgHQxhniihXk1ha62RBe82GbD9REENCJDP4iVlgbwLIRi0 85PAhd04OsSBqN9mktnDz3axTtS6iOSi9jjO86LsVGxmvPsEnkJ9SMtErV+CJaSry6b0 InHDgPnQEip4heDh5UoDrkb7gT/88rj1P7VKB4Od2IbUjODOFc1p0l56hJA4wNiE1XYk zNGTapB22n5oqpYU5GesY1BlUJgwOe532tTjE7FdIcycDfZwyqcAzjqmacD/rM0/6ADg DFbg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=M+Sww6cc; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p13-v6si1030657plo.150.2018.04.27.04.08.03; Fri, 27 Apr 2018 04:08:17 -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; dkim=fail header.i=@gmail.com header.s=20161025 header.b=M+Sww6cc; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932809AbeD0LFq (ORCPT + 99 others); Fri, 27 Apr 2018 07:05:46 -0400 Received: from mail-ot0-f194.google.com ([74.125.82.194]:37520 "EHLO mail-ot0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932700AbeD0LFo (ORCPT ); Fri, 27 Apr 2018 07:05:44 -0400 Received: by mail-ot0-f194.google.com with SMTP id 77-v6so1566850otd.4; Fri, 27 Apr 2018 04:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AcnGdVVCSx9wINn+kIjIeSfZMLsVTcJEDo56RBY/iiY=; b=M+Sww6ccbObfkpil4ZQQLEony3hPdyuixw6q8+ZUmPPskODb0AjP+XVR7MXAJ7huMM zzESBf5m1BT5EvFdgUa1QDDg0LKbxvI0xX8cCeHkgH6dDoBC0urQAJ+mpk7a5lDBRkfL WT5r9CU0A13/fhqaJQfLTD0DmM/e8d/P89AIKg808SVildMexJS+RnHjvpogJxe/uUJa tB/0BMDSSHPJ3Dw3N6ZFIzWrdwzhGR2QZ9ITRKg7XpI85pQWAtvWqpJ3Wa60lJw6MYvH kUmC4DQYfp9xs4KBge32VCk8N7ZDpnmyrqImKAo64pr6Fu7roGKWvvPgwnlIfsw7cOsT fY4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AcnGdVVCSx9wINn+kIjIeSfZMLsVTcJEDo56RBY/iiY=; b=thiNwiipNeUsss8MJ+zAbS6abg4MR9rIeul3ftnyqzXWh3TQnIQPiMywDgb2wQDj7U q0VcXExJ4CBPy7bEjfjVk07VZxlG4upqoI2UnwWTioto6IQBsQlSS51Pq+bOwPZxcpgr zrg+TNtxIR8H4NkdAADXKfQcqdoItmQ8M/Y/9TtOBg+wjo+io4guGJZyphXcVc6a0iBz ISMTtVCW5GXLpwXzx1QspfSJGU+xaSMMb7oaqeCLApSSZSqWIYzhzeJmxghH8ZtBs6yn yZQ4cxtWYMIIxnDBKp03MVBE9fSAIBZ+1ikS1QuB/zxZNSOm9PIQ0BYUhYTNuLFOKJtI 86Ew== X-Gm-Message-State: ALQs6tDQUAWVI3Vkqzr45Nck/2BbVZqhKQfTaZ5ziGOxLM7R5bUkalyS 6B9ohxZBtw+9zCdJ3Od3dViw1a6FEOilX/LyZ7c= X-Received: by 2002:a9d:5990:: with SMTP id u16-v6mr1015846oth.370.1524827144188; Fri, 27 Apr 2018 04:05:44 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:1468:0:0:0:0:0 with HTTP; Fri, 27 Apr 2018 04:05:43 -0700 (PDT) In-Reply-To: <20180424193505.6934-3-ahs3@redhat.com> References: <20180424193505.6934-1-ahs3@redhat.com> <20180424193505.6934-3-ahs3@redhat.com> From: "Rafael J. Wysocki" Date: Fri, 27 Apr 2018 13:05:43 +0200 X-Google-Sender-Auth: yY_zEUa5fURow4yzVZQs-D8kRqU Message-ID: Subject: Re: [PATCH v2 2/3] ACPI: ensure acpi_parse_entries_array() does not access non-existent table data To: Al Stone Cc: ACPI Devel Maling List , Linux Kernel Mailing List , "Rafael J . Wysocki" , Len Brown Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > if (max_entries && count >= max_entries) > break; > > --