* [PATCH v2] platform/chrome: cros_ec_typec: reject out-of-bounds PD cap count
@ 2026-06-25 13:00 Maoyi Xie
2026-06-26 7:45 ` Andrei Kuchynski
2026-06-26 18:32 ` Benson Leung
0 siblings, 2 replies; 3+ messages in thread
From: Maoyi Xie @ 2026-06-25 13:00 UTC (permalink / raw)
To: Benson Leung, Tzung-Bi Shih, Abhishek Pandit-Subedi,
Jameson Thies, Andrei Kuchynski, Guenter Roeck
Cc: Maoyi Xie, Kaixuan Li, chrome-platform, linux-kernel
cros_typec_register_partner_pdos() copies the partner PDOs from the EC
TYPEC_STATUS response into the fixed caps_desc.pdo[PDO_MAX_OBJECTS] array.
memcpy(caps_desc.pdo, resp->source_cap_pdos,
sizeof(u32) * resp->source_cap_count);
...
memcpy(caps_desc.pdo, resp->sink_cap_pdos,
sizeof(u32) * resp->sink_cap_count);
PDO_MAX_OBJECTS is 7. source_cap_count and sink_cap_count are u8 fields
from the EC. The only check is that they are not both zero. If either is
larger than 7, the memcpy writes past the end of the array on the stack.
A count of 255 overflows it by about 1 KB. The EC source arrays are only
seven entries wide. A larger count reads past them too.
The ChromeOS EC firmware caps these counts today, so a compliant setup
does not hit this. The kernel should still validate these values rather
than trust them.
Validate the counts in cros_typec_register_partner_pdos() next to the
memcpy. Skip the PDO registration if either count is above PDO_MAX_OBJECTS.
The rest of cros_typec_handle_status() still runs so events are handled
and cleared.
Fixes: 348a2e8c93d3 ("platform/chrome: cros_ec_typec: Register partner PDOs")
Suggested-by: Tzung-Bi Shih <tzungbi@kernel.org>
Suggested-by: Andrei Kuchynski <akuchynski@chromium.org>
Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
---
v2: Move the check into cros_typec_register_partner_pdos() next to the
memcpy it guards. v1 put it at the top of cros_typec_handle_status()
and returned early. That skipped the rest of the status handling and
left events uncleared.
v1: https://lore.kernel.org/r/178229037114.3009621.14045345257767446805@maoyixie.com
drivers/platform/chrome/cros_ec_typec.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c
index c0806c562bb9..50a68819ceb7 100644
--- a/drivers/platform/chrome/cros_ec_typec.c
+++ b/drivers/platform/chrome/cros_ec_typec.c
@@ -1119,6 +1119,12 @@ static void cros_typec_register_partner_pdos(struct cros_typec_data *typec,
if (!resp->source_cap_count && !resp->sink_cap_count)
return;
+ if (resp->source_cap_count > PDO_MAX_OBJECTS ||
+ resp->sink_cap_count > PDO_MAX_OBJECTS) {
+ dev_warn(typec->dev, "Invalid PDO count from EC, port: %d\n", port_num);
+ return;
+ }
+
port->partner_pd = typec_partner_usb_power_delivery_register(port->partner, &desc);
if (IS_ERR(port->partner_pd)) {
dev_warn(typec->dev, "Failed to register partner PD device, port: %d\n", port_num);
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH v2] platform/chrome: cros_ec_typec: reject out-of-bounds PD cap count
2026-06-25 13:00 [PATCH v2] platform/chrome: cros_ec_typec: reject out-of-bounds PD cap count Maoyi Xie
@ 2026-06-26 7:45 ` Andrei Kuchynski
2026-06-26 18:32 ` Benson Leung
1 sibling, 0 replies; 3+ messages in thread
From: Andrei Kuchynski @ 2026-06-26 7:45 UTC (permalink / raw)
To: Maoyi Xie
Cc: Benson Leung, Tzung-Bi Shih, Abhishek Pandit-Subedi,
Jameson Thies, Guenter Roeck, Kaixuan Li, chrome-platform,
linux-kernel
On Thu, Jun 25, 2026 at 3:01 PM Maoyi Xie <maoyixie.tju@gmail.com> wrote:
>
> cros_typec_register_partner_pdos() copies the partner PDOs from the EC
> TYPEC_STATUS response into the fixed caps_desc.pdo[PDO_MAX_OBJECTS] array.
>
> memcpy(caps_desc.pdo, resp->source_cap_pdos,
> sizeof(u32) * resp->source_cap_count);
> ...
> memcpy(caps_desc.pdo, resp->sink_cap_pdos,
> sizeof(u32) * resp->sink_cap_count);
>
> PDO_MAX_OBJECTS is 7. source_cap_count and sink_cap_count are u8 fields
> from the EC. The only check is that they are not both zero. If either is
> larger than 7, the memcpy writes past the end of the array on the stack.
> A count of 255 overflows it by about 1 KB. The EC source arrays are only
> seven entries wide. A larger count reads past them too.
>
> The ChromeOS EC firmware caps these counts today, so a compliant setup
> does not hit this. The kernel should still validate these values rather
> than trust them.
>
> Validate the counts in cros_typec_register_partner_pdos() next to the
> memcpy. Skip the PDO registration if either count is above PDO_MAX_OBJECTS.
> The rest of cros_typec_handle_status() still runs so events are handled
> and cleared.
>
> Fixes: 348a2e8c93d3 ("platform/chrome: cros_ec_typec: Register partner PDOs")
> Suggested-by: Tzung-Bi Shih <tzungbi@kernel.org>
> Suggested-by: Andrei Kuchynski <akuchynski@chromium.org>
> Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
> Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
> Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
Reviewed-by: Andrei Kuchynski <akuchynski@chromium.org>
> ---
> v2: Move the check into cros_typec_register_partner_pdos() next to the
> memcpy it guards. v1 put it at the top of cros_typec_handle_status()
> and returned early. That skipped the rest of the status handling and
> left events uncleared.
>
> v1: https://lore.kernel.org/r/178229037114.3009621.14045345257767446805@maoyixie.com
>
> drivers/platform/chrome/cros_ec_typec.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c
> index c0806c562bb9..50a68819ceb7 100644
> --- a/drivers/platform/chrome/cros_ec_typec.c
> +++ b/drivers/platform/chrome/cros_ec_typec.c
> @@ -1119,6 +1119,12 @@ static void cros_typec_register_partner_pdos(struct cros_typec_data *typec,
> if (!resp->source_cap_count && !resp->sink_cap_count)
> return;
>
> + if (resp->source_cap_count > PDO_MAX_OBJECTS ||
> + resp->sink_cap_count > PDO_MAX_OBJECTS) {
> + dev_warn(typec->dev, "Invalid PDO count from EC, port: %d\n", port_num);
> + return;
> + }
> +
> port->partner_pd = typec_partner_usb_power_delivery_register(port->partner, &desc);
> if (IS_ERR(port->partner_pd)) {
> dev_warn(typec->dev, "Failed to register partner PD device, port: %d\n", port_num);
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v2] platform/chrome: cros_ec_typec: reject out-of-bounds PD cap count
2026-06-25 13:00 [PATCH v2] platform/chrome: cros_ec_typec: reject out-of-bounds PD cap count Maoyi Xie
2026-06-26 7:45 ` Andrei Kuchynski
@ 2026-06-26 18:32 ` Benson Leung
1 sibling, 0 replies; 3+ messages in thread
From: Benson Leung @ 2026-06-26 18:32 UTC (permalink / raw)
To: Maoyi Xie
Cc: Benson Leung, Tzung-Bi Shih, Abhishek Pandit-Subedi,
Jameson Thies, Andrei Kuchynski, Guenter Roeck, Kaixuan Li,
chrome-platform, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2914 bytes --]
On Thu, Jun 25, 2026 at 09:00:56PM +0800, Maoyi Xie wrote:
> cros_typec_register_partner_pdos() copies the partner PDOs from the EC
> TYPEC_STATUS response into the fixed caps_desc.pdo[PDO_MAX_OBJECTS] array.
>
> memcpy(caps_desc.pdo, resp->source_cap_pdos,
> sizeof(u32) * resp->source_cap_count);
> ...
> memcpy(caps_desc.pdo, resp->sink_cap_pdos,
> sizeof(u32) * resp->sink_cap_count);
>
> PDO_MAX_OBJECTS is 7. source_cap_count and sink_cap_count are u8 fields
> from the EC. The only check is that they are not both zero. If either is
> larger than 7, the memcpy writes past the end of the array on the stack.
> A count of 255 overflows it by about 1 KB. The EC source arrays are only
> seven entries wide. A larger count reads past them too.
>
> The ChromeOS EC firmware caps these counts today, so a compliant setup
> does not hit this. The kernel should still validate these values rather
> than trust them.
>
> Validate the counts in cros_typec_register_partner_pdos() next to the
> memcpy. Skip the PDO registration if either count is above PDO_MAX_OBJECTS.
> The rest of cros_typec_handle_status() still runs so events are handled
> and cleared.
>
> Fixes: 348a2e8c93d3 ("platform/chrome: cros_ec_typec: Register partner PDOs")
> Suggested-by: Tzung-Bi Shih <tzungbi@kernel.org>
> Suggested-by: Andrei Kuchynski <akuchynski@chromium.org>
> Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
> Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
> Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
> ---
> v2: Move the check into cros_typec_register_partner_pdos() next to the
> memcpy it guards. v1 put it at the top of cros_typec_handle_status()
> and returned early. That skipped the rest of the status handling and
> left events uncleared.
>
> v1: https://lore.kernel.org/r/178229037114.3009621.14045345257767446805@maoyixie.com
>
> drivers/platform/chrome/cros_ec_typec.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c
> index c0806c562bb9..50a68819ceb7 100644
> --- a/drivers/platform/chrome/cros_ec_typec.c
> +++ b/drivers/platform/chrome/cros_ec_typec.c
> @@ -1119,6 +1119,12 @@ static void cros_typec_register_partner_pdos(struct cros_typec_data *typec,
> if (!resp->source_cap_count && !resp->sink_cap_count)
> return;
>
> + if (resp->source_cap_count > PDO_MAX_OBJECTS ||
> + resp->sink_cap_count > PDO_MAX_OBJECTS) {
> + dev_warn(typec->dev, "Invalid PDO count from EC, port: %d\n", port_num);
> + return;
> + }
> +
> port->partner_pd = typec_partner_usb_power_delivery_register(port->partner, &desc);
> if (IS_ERR(port->partner_pd)) {
> dev_warn(typec->dev, "Failed to register partner PD device, port: %d\n", port_num);
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-06-26 18:32 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-25 13:00 [PATCH v2] platform/chrome: cros_ec_typec: reject out-of-bounds PD cap count Maoyi Xie
2026-06-26 7:45 ` Andrei Kuchynski
2026-06-26 18:32 ` Benson Leung
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox