On Fri, 10 Feb 2023 21:25:04 +0100
Lukas Wunner <lukas@xxxxxxxxx> wrote:
> If the length in the CDAT header is larger than the concatenation of the
> header and all table entries, then the CDAT exposed to user space
> contains trailing null bytes.
>
> Not every consumer may be able to handle that. Per Postel's robustness
> principle, "be liberal in what you accept" and silently reduce the
> cached length to avoid exposing those null bytes.
>
> Fixes: c97006046c79 ("cxl/port: Read CDAT table")
> Tested-by: Ira Weiny <ira.weiny@xxxxxxxxx>
> Signed-off-by: Lukas Wunner <lukas@xxxxxxxxx>
> Cc: stable@xxxxxxxxxxxxxxx # v6.0+
Fair enough. I'd argue that we are papering over broken hardware if
we hit these conditions, so given we aren't aware of any (I hope)
not sure this is stable material. Argument in favor of stable being
that if we do get broken hardware we don't want an ABI change when
we paper over the garbage... hmm.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
> ---
> Changes v2 -> v3:
> * Newly added patch in v3
>
> drivers/cxl/core/pci.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/cxl/core/pci.c b/drivers/cxl/core/pci.c
> index a3fb6bd68d17..c37c41d7acb6 100644
> --- a/drivers/cxl/core/pci.c
> +++ b/drivers/cxl/core/pci.c
> @@ -582,6 +582,9 @@ static int cxl_cdat_read_table(struct device *dev,
> }
> } while (entry_handle != CXL_DOE_TABLE_ACCESS_LAST_ENTRY);
>
> + /* Length in CDAT header may exceed concatenation of CDAT entries */
> + cdat->length -= length;
> +
> return 0;
> }
>
