Message ID | 20230925214046.1051350-1-anarsoul@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:cae8:0:b0:403:3b70:6f57 with SMTP id r8csp1612780vqu; Mon, 25 Sep 2023 18:55:34 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGjH8aShUfCabTnq/mI/7Wf1MNno4VBeaaxv6CSsuoamqdGzLJ1kBKAt8wUxjD0bKF+3ma2 X-Received: by 2002:a05:6a21:33a7:b0:13c:ca8b:7e29 with SMTP id yy39-20020a056a2133a700b0013cca8b7e29mr10448721pzb.12.1695693334184; Mon, 25 Sep 2023 18:55:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695693334; cv=none; d=google.com; s=arc-20160816; b=ML6HFSQpOjaHK6PvXQaoVg1TkJw7rP7xkzNQAzm3tnKDslAttCvDEWfyzDjyMYn/ny zM6Y61w+aW9bquZU1CAREyX2olWrHnI0x1rUMqTM0wVenqniqB1WVuI+kibO75vtjr0R eGVMZOJiD+OBX2BtsObV3fL5018pYw9LdIrvuZ/bwvqVpqbg+Z79vuLQzSd7Ts4YOc5b mXQm10qVGoXR43MQXMrviKocjo51BW5w9X6Rv+7ecT4TefTx270zJzvlsUfqmvgcaaun TuvJDNO2+UIlxfQsPYmqNpb5nNUgQeYfaU1mCcSnQ8K2NFQsmNujqbDD2+QCsKKCPd9S I6HA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=j+7R1ZC1LpCIsd5QhAKbQCzI8a0TBew1Yl2b+K+Z1Aw=; fh=niIOB5d+VqhXCpy0pHEyywxlBhvrDaPcOG2iJvtDqxE=; b=I8x3lBJ9gxMUuH0fPca99JJHUXboGQ2VidWLiZO06qokUSsh0e/lNjiBJs4pp/Dx4y Vf84s28jWXFOjoYGTeK97nn+qJnhCtsbhnqwJP8xIe1Q70zIZ6dTGuFtsIaDrw0jM2dT GdtGj1scBr+R47NxesMpQXgsSY5Rz6CHlxWriO90wvP6fbUf8qx5qYd/SKwz50MCryic k4dKA3H8opzzt1jukVTAmUg/7T9lN/cenf+Duz3gG/JU9fRJShKM58Vd46Yv5WxeoYyv N+q8lIopuruoKzAcxUw6OLt8XTNthSzoS6hl9HYf87cOgpypADmaO05zbyg+euE4Ov+o JPow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="GZ/etxxp"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id e3-20020a656883000000b005641ddd0309si11362328pgt.599.2023.09.25.18.55.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Sep 2023 18:55:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="GZ/etxxp"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 90F3C8083AD6; Mon, 25 Sep 2023 14:41:10 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233444AbjIYVlK (ORCPT <rfc822;chrisfriedt@gmail.com> + 28 others); Mon, 25 Sep 2023 17:41:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34946 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233417AbjIYVlJ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 25 Sep 2023 17:41:09 -0400 Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EFC1EA3; Mon, 25 Sep 2023 14:41:02 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1c5faa2af60so7842655ad.0; Mon, 25 Sep 2023 14:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695678062; x=1696282862; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=j+7R1ZC1LpCIsd5QhAKbQCzI8a0TBew1Yl2b+K+Z1Aw=; b=GZ/etxxprpv/iAoiwItDSFy86IgxJIbnO17JA8T5X7D/YhjvRLNvFNEaPCd6e6HWgM vbkHoyVRhL1BkA7RMbkQ9ZncoMeyjdSrjaX8GEpaxGYu4UCOG4/HlDNJ1kg+fmsfqxKM +88XsqihDYodmSlQt0K0yJ63QgzTa1qb3TBOtrWPQKZauZyLUAPDhBJ2wG/mv+nstpbb Os8TL/WJFI+qVVsOimsY0tDSp4S+1pMIOmJldNPg1X4zI3k/F9Y0VSCTIupHhcXgZgX6 rM+WKSLccTZt6y9m9WRClvdQ2CztNVIuXgICdLWxNVqqV6EytehQ4gIvK6O2tXGK3+Rm S0Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695678062; x=1696282862; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=j+7R1ZC1LpCIsd5QhAKbQCzI8a0TBew1Yl2b+K+Z1Aw=; b=Li2CnU0PUVr9OPNXAH3aPBomgL4awVh+0Ny4LRWnfq5KbUyGXUZBReRpgPlguIlcUZ glsAFRHHJ2I6El+2mDRGOWChl4iYB7I0tZyZihgjiAXPKiKzbIS3xDMQlz3x6nMZGt9e wYldUQXkRHid6WHBOwAjkWckt+/QkQvMsoNlPtSoIFhC05zjNLSyuZWIX8V0HkFvV4hE rVfAF328UK9gVUFRKAcFOrCd7rS599A1Xb8eFfn4E1EZ+OAE0EnxhCTHjA3tJF52/pX9 OqNkklVVsAAmOM+eYaYABH1y6887PSQPqIJBEVBfSxn4S2aIw1arYtmKV9Epzxx9LSNQ KshQ== X-Gm-Message-State: AOJu0YwFSLzk2glapWeRC+X6CMJkX7rt/y6/CS9uuShjoWuenGJQBpRp ynV9iB4efCtgj8uckccTIOg= X-Received: by 2002:a17:903:22cb:b0:1bb:d7d4:e2b with SMTP id y11-20020a17090322cb00b001bbd7d40e2bmr10112393plg.0.1695678062341; Mon, 25 Sep 2023 14:41:02 -0700 (PDT) Received: from anarsoul-xps15.lan ([2604:3d08:7780:c13::398]) by smtp.gmail.com with ESMTPSA id e19-20020a170902f1d300b001c0a4146961sm5582271plc.19.2023.09.25.14.41.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Sep 2023 14:41:01 -0700 (PDT) From: Vasily Khoruzhick <anarsoul@gmail.com> To: "Rafael J. Wysocki" <rafael@kernel.org>, Len Brown <lenb@kernel.org>, Zhang Rui <rui.zhang@intel.com>, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Vasily Khoruzhick <anarsoul@gmail.com>, stable@vger.kernel.org Subject: [PATCH] ACPI: FPDT: break out of the loop if record length is zero Date: Mon, 25 Sep 2023 14:40:21 -0700 Message-ID: <20230925214046.1051350-1-anarsoul@gmail.com> X-Mailer: git-send-email 2.42.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Mon, 25 Sep 2023 14:41:10 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778063333456492414 X-GMAIL-MSGID: 1778063333456492414 |
Series |
ACPI: FPDT: break out of the loop if record length is zero
|
|
Commit Message
Vasily Khoruzhick
Sept. 25, 2023, 9:40 p.m. UTC
Buggy BIOSes may have zero-length records in FPDT, table, as a result
fpdt_process_subtable() spins in eternal loop.
Break out of the loop if record length is zero.
Fixes: d1eb86e59be0 ("ACPI: tables: introduce support for FPDT table")
Cc: stable@vger.kernel.org
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
drivers/acpi/acpi_fpdt.c | 5 +++++
1 file changed, 5 insertions(+)
Comments
On Mon, 2023-09-25 at 14:40 -0700, Vasily Khoruzhick wrote: > Buggy BIOSes may have zero-length records in FPDT, table, as a result s/FPDT, table/FPDT table > fpdt_process_subtable() spins in eternal loop. > > Break out of the loop if record length is zero. > > > Fixes: d1eb86e59be0 ("ACPI: tables: introduce support for FPDT > table") > Cc: stable@vger.kernel.org > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Is there a bugzilla or something where such a buggy BIOS is reported? > --- > drivers/acpi/acpi_fpdt.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/drivers/acpi/acpi_fpdt.c b/drivers/acpi/acpi_fpdt.c > index a2056c4c8cb7..53d8f9601a55 100644 > --- a/drivers/acpi/acpi_fpdt.c > +++ b/drivers/acpi/acpi_fpdt.c > @@ -194,6 +194,11 @@ static int fpdt_process_subtable(u64 address, > u32 subtable_type) > record_header = (void *)subtable_header + offset; > offset += record_header->length; > > + if (!record_header->length) { > + pr_info(FW_BUG "Zero-length record > found.\n"); > + break; For cases like this, it implies the FPDT table is far from usable and we should stop processing on such platforms. So, IMO, it is better to 1. return an error here rather than break and return 0. 2. add the error handling for fpdt_process_subtable() failures. what do you think? thanks, rui > + } > + > switch (record_header->type) { > case RECORD_S3_RESUME: > if (subtable_type != SUBTABLE_S3PT) {
On Mon, Sep 25, 2023 at 10:03 PM Zhang, Rui <rui.zhang@intel.com> wrote: > > On Mon, 2023-09-25 at 14:40 -0700, Vasily Khoruzhick wrote: > > Buggy BIOSes may have zero-length records in FPDT, table, as a result > s/FPDT, table/FPDT table > > > > fpdt_process_subtable() spins in eternal loop. > > > > Break out of the loop if record length is zero. > > > > > > Fixes: d1eb86e59be0 ("ACPI: tables: introduce support for FPDT > > table") > > Cc: stable@vger.kernel.org > > > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> > > Is there a bugzilla or something where such a buggy BIOS is reported? I'm not aware of a bug filed a kernel bugzilla, however I found mentions of the issue online: https://forum.proxmox.com/threads/acpi-fpdt-duplicate-resume-performance-record-found.114530/ > > --- > > drivers/acpi/acpi_fpdt.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/drivers/acpi/acpi_fpdt.c b/drivers/acpi/acpi_fpdt.c > > index a2056c4c8cb7..53d8f9601a55 100644 > > --- a/drivers/acpi/acpi_fpdt.c > > +++ b/drivers/acpi/acpi_fpdt.c > > @@ -194,6 +194,11 @@ static int fpdt_process_subtable(u64 address, > > u32 subtable_type) > > record_header = (void *)subtable_header + offset; > > offset += record_header->length; > > > > + if (!record_header->length) { > > + pr_info(FW_BUG "Zero-length record > > found.\n"); > > + break; > > For cases like this, it implies the FPDT table is far from usable and > we should stop processing on such platforms. Here's FPDT dump: 00000000: 4650 4454 4400 0000 018c 414c 4153 4b41 FPDTD.....ALASKA 00000010: 4120 4d20 4920 0000 0920 0701 414d 4920 A M I ... ..AMI 00000020: 1300 0100 0100 1001 0000 0000 30fe 207f ............0. . 00000030: 0000 0000 0000 1001 0000 0000 54fe 207f ............T. . 00000040: 0000 0000 .... S3PT at 0x7f20fe30: 7F20FE30: 53 33 50 54 24 00 00 00-00 00 00 00 00 00 18 01 *S3PT$...........* 7F20FE40: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 *................* 7F20FE50: 00 00 00 00 FBPT at 0x7f20fe54: 7F20FE50: xx xx xx xx 46 42 50 54-3C 00 00 00 46 42 50 54 *....FBPT<...FBPT* 7F20FE60: 02 00 30 02 00 00 00 00-00 00 00 00 00 00 00 00 *..0.............* 7F20FE70: 2A A6 BC 6E 0B 00 00 00-1A 44 41 70 0B 00 00 00 **..n.....DAp....* 7F20FE80: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 *................* It looks like subtables are not usable. S3PT subtable has the first record with zero len, and FBPT has its signature again instead of the first record header. So yeah, I agree that FPDT is not usabled in this case, and it shouldn't be processed further. > So, IMO, it is better to > 1. return an error here rather than break and return 0. > 2. add the error handling for fpdt_process_subtable() failures. > > what do you think? Agree, I'll implement it in v2. Regards, Vasily
diff --git a/drivers/acpi/acpi_fpdt.c b/drivers/acpi/acpi_fpdt.c index a2056c4c8cb7..53d8f9601a55 100644 --- a/drivers/acpi/acpi_fpdt.c +++ b/drivers/acpi/acpi_fpdt.c @@ -194,6 +194,11 @@ static int fpdt_process_subtable(u64 address, u32 subtable_type) record_header = (void *)subtable_header + offset; offset += record_header->length; + if (!record_header->length) { + pr_info(FW_BUG "Zero-length record found.\n"); + break; + } + switch (record_header->type) { case RECORD_S3_RESUME: if (subtable_type != SUBTABLE_S3PT) {