From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Lukas Wunner <lukas@wunner.de>
Cc: Bjorn Helgaas <helgaas@kernel.org>, <linux-pci@vger.kernel.org>,
"Gregory Price" <gregory.price@memverge.com>,
Ira Weiny <ira.weiny@intel.com>,
"Dan Williams" <dan.j.williams@intel.com>,
Alison Schofield <alison.schofield@intel.com>,
Vishal Verma <vishal.l.verma@intel.com>,
Dave Jiang <dave.jiang@intel.com>,
"Li, Ming" <ming4.li@intel.com>,
"Hillf Danton" <hdanton@sina.com>,
Ben Widawsky <bwidawsk@kernel.org>, <linuxarm@huawei.com>,
<linux-cxl@vger.kernel.org>
Subject: Re: [PATCH v3 03/16] cxl/pci: Handle truncated CDAT entries
Date: Tue, 14 Feb 2023 11:30:54 +0000 [thread overview]
Message-ID: <20230214113054.00004cb4@Huawei.com> (raw)
In-Reply-To: <5b4e23f256b3705360d84eccb9652e4b558a77b5.1676043318.git.lukas@wunner.de>
On Fri, 10 Feb 2023 21:25:03 +0100
Lukas Wunner <lukas@wunner.de> wrote:
> If truncated CDAT entries are received from a device, the concatenation
> of those entries constitutes a corrupt CDAT, yet is happily exposed to
> user space.
>
> Avoid by verifying response lengths and erroring out if truncation is
> detected.
>
> The last CDAT entry may still be truncated despite the checks introduced
> herein if the length in the CDAT header is too small. However, that is
> easily detectable by user space because it reaches EOF prematurely.
> A subsequent commit which rightsizes the CDAT response allocation closes
> that remaining loophole.
>
> The two lines introduced here which exceed 80 chars are shortened to
> less than 80 chars by a subsequent commit which migrates to a
> synchronous DOE API and replaces "t.task.rv" by "rc".
>
> The existing acpi_cdat_header and acpi_table_cdat struct definitions
> provided by ACPICA cannot be used because they do not employ __le16 or
> __le32 types. I believe that cannot be changed because those types are
> Linux-specific and ACPI is specified for little endian platforms only,
> hence doesn't care about endianness. So duplicate the structs.
>
> Fixes: c97006046c79 ("cxl/port: Read CDAT table")
> Tested-by: Ira Weiny <ira.weiny@intel.com>
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> Cc: stable@vger.kernel.org # v6.0+
One trivial suggestion.
Glad to see this tightened up.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---
> Changes v2 -> v3:
> * Newly added patch in v3
>
> drivers/cxl/core/pci.c | 13 +++++++++----
> drivers/cxl/cxlpci.h | 14 ++++++++++++++
> 2 files changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/cxl/core/pci.c b/drivers/cxl/core/pci.c
> index 11a85b3a9a0b..a3fb6bd68d17 100644
> --- a/drivers/cxl/core/pci.c
> +++ b/drivers/cxl/core/pci.c
> @@ -547,8 +547,8 @@ static int cxl_cdat_read_table(struct device *dev,
>
> do {
> DECLARE_CDAT_DOE_TASK(CDAT_DOE_REQ(entry_handle), t);
> + struct cdat_entry_header *entry;
> size_t entry_dw;
> - __le32 *entry;
> int rc;
>
> rc = pci_doe_submit_task(cdat_doe, &t.task);
> @@ -557,14 +557,19 @@ static int cxl_cdat_read_table(struct device *dev,
> return rc;
> }
> wait_for_completion(&t.c);
> - /* 1 DW header + 1 DW data min */
> - if (t.task.rv < (2 * sizeof(u32)))
> +
> + /* 1 DW Table Access Response Header + CDAT entry */
> + entry = (struct cdat_entry_header *)(t.response_pl + 1);
> + if ((entry_handle == 0 &&
> + t.task.rv != sizeof(u32) + sizeof(struct cdat_header)) ||
> + (entry_handle > 0 &&
> + (t.task.rv < sizeof(u32) + sizeof(struct cdat_entry_header) ||
Slight preference for sizeof(*entry)
so that it is clear that we are checking we can do the next check without
getting garbage.
> + t.task.rv != sizeof(u32) + le16_to_cpu(entry->length))))
> return -EIO;
>
> /* Get the CXL table access header entry handle */
> entry_handle = FIELD_GET(CXL_DOE_TABLE_ACCESS_ENTRY_HANDLE,
> le32_to_cpu(t.response_pl[0]));
> - entry = t.response_pl + 1;
> entry_dw = t.task.rv / sizeof(u32);
> /* Skip Header */
> entry_dw -= 1;
> diff --git a/drivers/cxl/cxlpci.h b/drivers/cxl/cxlpci.h
> index 920909791bb9..104ad2b72516 100644
> --- a/drivers/cxl/cxlpci.h
> +++ b/drivers/cxl/cxlpci.h
> @@ -62,6 +62,20 @@ enum cxl_regloc_type {
> CXL_REGLOC_RBI_TYPES
> };
>
> +struct cdat_header {
> + __le32 length;
> + u8 revision;
> + u8 checksum;
> + u8 reserved[6];
> + __le32 sequence;
> +} __packed;
> +
> +struct cdat_entry_header {
> + u8 type;
> + u8 reserved;
> + __le16 length;
> +} __packed;
> +
> int devm_cxl_port_enumerate_dports(struct cxl_port *port);
> struct cxl_dev_state;
> int cxl_hdm_decode_init(struct cxl_dev_state *cxlds, struct cxl_hdm *cxlhdm);
next prev parent reply other threads:[~2023-02-14 11:31 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-10 20:25 [PATCH v3 00/16] Collection of DOE material Lukas Wunner
2023-02-10 20:25 ` [PATCH v3 01/16] cxl/pci: Fix CDAT retrieval on big endian Lukas Wunner
2023-02-11 0:22 ` Dan Williams
2023-02-19 13:03 ` Lukas Wunner
2023-02-14 11:15 ` Jonathan Cameron
2023-02-14 13:51 ` Lukas Wunner
2023-02-14 15:45 ` Jonathan Cameron
2023-02-28 2:53 ` Alexey Kardashevskiy
2023-02-28 8:24 ` Lukas Wunner
2023-02-28 12:08 ` Alexey Kardashevskiy
2023-02-10 20:25 ` [PATCH v3 02/16] cxl/pci: Handle truncated CDAT header Lukas Wunner
2023-02-11 0:40 ` Dan Williams
2023-02-11 9:34 ` Lukas Wunner
2023-02-14 11:16 ` Jonathan Cameron
2023-02-15 1:41 ` Li, Ming
2023-02-10 20:25 ` [PATCH v3 03/16] cxl/pci: Handle truncated CDAT entries Lukas Wunner
2023-02-11 0:50 ` Dan Williams
2023-02-11 10:56 ` Lukas Wunner
2023-02-14 11:30 ` Jonathan Cameron [this message]
2023-02-10 20:25 ` [PATCH v3 04/16] cxl/pci: Handle excessive CDAT length Lukas Wunner
2023-02-11 1:04 ` Dan Williams
2023-02-14 11:33 ` Jonathan Cameron
2023-02-16 10:26 ` Lukas Wunner
2023-02-17 10:01 ` Jonathan Cameron
2023-02-10 20:25 ` [PATCH v3 05/16] PCI/DOE: Silence WARN splat with CONFIG_DEBUG_OBJECTS=y Lukas Wunner
2023-02-10 20:25 ` [PATCH v3 06/16] PCI/DOE: Fix memory leak " Lukas Wunner
2023-02-11 1:06 ` Dan Williams
2023-03-01 1:51 ` Davidlohr Bueso
2023-02-10 20:25 ` [PATCH v3 07/16] PCI/DOE: Provide synchronous API and use it internally Lukas Wunner
2023-02-15 1:45 ` Li, Ming
2023-02-28 18:58 ` Davidlohr Bueso
2023-02-10 20:25 ` [PATCH v3 08/16] cxl/pci: Use synchronous API for DOE Lukas Wunner
2023-02-10 20:25 ` [PATCH v3 09/16] PCI/DOE: Make asynchronous API private Lukas Wunner
2023-02-15 1:48 ` Li, Ming
2023-02-10 20:25 ` [PATCH v3 10/16] PCI/DOE: Deduplicate mailbox flushing Lukas Wunner
2023-02-14 11:36 ` Jonathan Cameron
2023-02-15 5:07 ` Li, Ming
2023-02-10 20:25 ` [PATCH v3 11/16] PCI/DOE: Allow mailbox creation without devres management Lukas Wunner
2023-02-14 11:51 ` Jonathan Cameron
2023-02-15 5:17 ` Li, Ming
2023-02-10 20:25 ` [PATCH v3 12/16] PCI/DOE: Create mailboxes on device enumeration Lukas Wunner
2023-02-15 2:07 ` Li, Ming
2023-02-28 1:18 ` Alexey Kardashevskiy
2023-02-28 1:39 ` Dan Williams
2023-02-28 5:43 ` Lukas Wunner
2023-02-28 7:24 ` Alexey Kardashevskiy
2023-02-28 10:42 ` Jonathan Cameron
2023-03-02 20:22 ` Lukas Wunner
2023-03-07 1:55 ` Alexey Kardashevskiy
2023-04-03 0:55 ` Alexey Kardashevskiy
2023-02-10 20:25 ` [PATCH v3 13/16] cxl/pci: Use CDAT DOE mailbox created by PCI core Lukas Wunner
2023-02-10 20:25 ` [PATCH v3 14/16] PCI/DOE: Make mailbox creation API private Lukas Wunner
2023-02-15 2:13 ` Li, Ming
2023-02-10 20:25 ` [PATCH v3 15/16] PCI/DOE: Relax restrictions on request and response size Lukas Wunner
2023-02-15 5:05 ` Li, Ming
2023-02-15 11:49 ` Lukas Wunner
2023-02-10 20:25 ` [PATCH v3 16/16] cxl/pci: Rightsize CDAT response allocation Lukas Wunner
2023-02-14 13:05 ` Jonathan Cameron
2023-02-16 0:56 ` Ira Weiny
2023-02-16 8:03 ` Lukas Wunner
2023-02-28 1:45 ` Alexey Kardashevskiy
2023-02-28 5:55 ` Lukas Wunner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230214113054.00004cb4@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=alison.schofield@intel.com \
--cc=bwidawsk@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=gregory.price@memverge.com \
--cc=hdanton@sina.com \
--cc=helgaas@kernel.org \
--cc=ira.weiny@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=lukas@wunner.de \
--cc=ming4.li@intel.com \
--cc=vishal.l.verma@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.