linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	linux-pci@vger.kernel.org,
	Gregory Price <gregory.price@memverge.com>,
	Ira Weiny <ira.weiny@intel.com>,
	Jonathan Cameron <Jonathan.Cameron@huawei.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: Sat, 11 Feb 2023 11:56:30 +0100	[thread overview]
Message-ID: <20230211105630.GA28226@wunner.de> (raw)
In-Reply-To: <63e6e65e5e1f3_1e494329496@dwillia2-xfh.jf.intel.com.notmuch>

On Fri, Feb 10, 2023 at 04:50:38PM -0800, Dan Williams wrote:
> Lukas Wunner 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.
[...]
> > @@ -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)))
> 
> Ah, I guess that's why the previous check can not be pushed down
> further, its obviated by this more comprehensive check.

The check in the previous patch ("cxl/pci: Handle truncated CDAT header")
fixes response size verification for cxl_cdat_get_length().

The check here however is in a different function, cxl_cdat_read_table().
Previously the function only checked whether the DOE response contained
two dwords.  That's one dword for the Table Access Response header
(CXL r3.0 sec 8.1.11.1) plus one dword for the common header shared
by all CDAT structures.

What can happen is we receive a truncated entry with, say, just
two dwords, and we copy that to the cached CDAT exposed in sysfs.
Obviously that's a corrupt CDAT.  The consumer of the CDAT doesn't
know that the data was truncated and will try to parse the entry
even though the data may actually be a portion of the next entry.

The improved verification here ensures that the received amount of
data corresponds to the length in the entry header.

It is up to the parsing function of each entry to verify whether
that length is correct for that specific entry.  E.g. a DSMAS entry
should contain 24 bytes, so the parsing function needs to verify
that the length in the entry header is actually 24.  (See the e-mail
I sent to Dave a few minutes ago.)

Thanks,

Lukas

> > +		/* 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) ||
> > +		      t.task.rv != sizeof(u32) + le16_to_cpu(entry->length))))
> >  			return -EIO;

  reply	other threads:[~2023-02-11 10:56 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 [this message]
2023-02-14 11:30   ` Jonathan Cameron
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=20230211105630.GA28226@wunner.de \
    --to=lukas@wunner.de \
    --cc=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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).