All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Marek Vasut" <marek.vasut+renesas@mailbox.org>
Cc: wsa+renesas@sang-engineering.com, linux-pci@vger.kernel.org
Subject: Re: [PATCH v3] PCI: rcar-gen4: Limit Max_Read_Request_Size and Max_Payload_Size to 256 Bytes
Date: Fri, 21 Aug 2026 02:19:51 +0000	[thread overview]
Message-ID: <20260821021952.697B91F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260821020636.111719-1-marek.vasut+renesas@mailbox.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] System denial of service via kernel panic. Untrusted hardware input maps directly into a `WARN_ON` assertion.
--

--- Patch [1]: [PATCH v3] PCI: rcar-gen4: Limit Max_Read_Request_Size and Max_Payload_Size to 256 Bytes ---
commit 79fc893274978b76ee056f33053d2211fce68461
Author: Marek Vasut <marek.vasut+renesas@mailbox.org>

PCI: rcar-gen4: Limit Max_Read_Request_Size and Max_Payload_Size to 256 Bytes

This commit forces the Max_Payload_Size and Max_Read_Request_Size to at most
256 bytes for devices connected to the R-Car Gen4 PCIe controller. This works
around a hardware limitation where longer reads wrap around at the 256-byte
boundary.

Fixes: 0d0c551011df ("PCI: rcar-gen4: Add R-Car Gen4 PCIe controller support for host mode")

> diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> --- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> +++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
[ ... ]
> @@ -411,6 +411,54 @@ static int rcar_gen4_pcie_host_msi_init(struct dw_pcie_rp *pp)
>  	return ret;
>  }
>  
> +static int rcar_gen4_pcie_enable_device(struct pci_host_bridge *bridge,
> +					struct pci_dev *dev)
> +{
> +	/*
> +	 * R-Car Gen4 PCIe controller has a hardware limitation of 256 Bytes
> +	 * Max_Payload_Size (MPS). PCIe specification indicates that the MPS
> +	 * must not exceed minimum MPS of any element along the packet path.
> +	 * The controller reports Max_Payload_Size_Supported (MPSS) 256 Bytes
> +	 * for header type 0 and 128 Bytes for header type 1. The PCIe core
> +	 * will not allow MPS to be set higher than MPSS, warn here in case
> +	 * something went very wrong in the core.
> +	 *
> +	 * For details, refer to chapter "104.1.1 Features" in either of:
> +	 * R-Car S4 R19UH0161EJ0140 Rev.1.40 Jul. 31, 2026 or
> +	 * R-Car V4H R19UH0186EJ0140 Rev.1.40 Aug. 7, 2026 or
> +	 * R-Car V4M R19UH0217EJ0110 Rev.1.10 Jun. 30, 2026.
> +	 */
> +	WARN_ON(pcie_get_mps(dev) > 256);

[Severity: Medium]
Is it safe to use WARN_ON() with values read directly from the device's
configuration space?

A malfunctioning or malicious PCIe endpoint could spoof its configuration
space and return a value for PCI_EXP_DEVCTL where the payload field is
greater than 256 bytes. When rcar_gen4_pcie_enable_device() calls
pcie_get_mps(dev), it issues a configuration space read directly to the
endpoint device.

If a system has panic_on_warn enabled, feeding this untrusted hardware input
into WARN_ON() could allow a connected PCIe device to intentionally trigger a
kernel panic, resulting in a system-wide denial of service.

Would it be safer to handle this unexpected condition by using pci_warn()
and dynamically adjusting the payload size, rather than risking a system
panic?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260821020636.111719-1-marek.vasut+renesas@mailbox.org?part=1

      reply	other threads:[~2026-08-21  2:19 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-21  2:05 [PATCH v3] PCI: rcar-gen4: Limit Max_Read_Request_Size and Max_Payload_Size to 256 Bytes Marek Vasut
2026-08-21  2:19 ` sashiko-bot [this message]

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=20260821021952.697B91F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=marek.vasut+renesas@mailbox.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=wsa+renesas@sang-engineering.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.