From: Alexis Savery <asavery@google.com>
To: tzungbi@kernel.org
Cc: chrome-platform@lists.linux.dev, asavery@google.com
Subject: [PATCH v4] platform/chrome: lightbar: Limit payload to max packet size
Date: Thu, 30 Jul 2026 13:42:40 -0700 [thread overview]
Message-ID: <20260730204240.2227178-1-asavery@google.com> (raw)
In-Reply-To: <20260729221459.1006-1-asavery@google.com>
The LIGHTBAR_CMD_SET_PROGRAM_EX command encapsulates its payload data
with an 8-bit size field `uint8_t size` and is natively capped by the V3
packet bounds limit array `EC_LPC_HOST_PACKET_SIZE`. However, the driver
currently allows the payload chunk to bypass this protocol limit if the
SPI transmission layer negotiates a larger physical `max_request`.
When this occurs, large payloads (e.g., >255 bytes) integer wrap the
8-bit size variable when assigning `param->set_program_ex.size`, causing
truncation and parse failures downstream in the EC firmware stack.
This change clamps max_size systematically using the maximum structural
type boundary of the size variable, bringing chunking in sync with the
hardware limitations without artificially binding to a specific protocol.
Link: https://lore.kernel.org/r/20260730005956.559287-1-asavery@google.com
Signed-off-by: Alexis Savery <asavery@google.com>
---
drivers/platform/chrome/cros_ec_lightbar.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/chrome/cros_ec_lightbar.c b/drivers/platform/chrome/cros_ec_lightbar.c
index 02a6c34e68e6..c9740a3bb5a1 100644
--- a/drivers/platform/chrome/cros_ec_lightbar.c
+++ b/drivers/platform/chrome/cros_ec_lightbar.c
@@ -496,9 +496,14 @@ static ssize_t program_store(struct device *dev, struct device_attribute *attr,
return -EINVAL;
}
} else {
+ /*
+ * Bound the payload strictly by the maximum value the structural
+ * size field can natively support.
+ */
extra_bytes = offsetof(typeof(*param), set_program_ex) +
sizeof(param->set_program_ex);
- max_size = ec->ec_dev->max_request - extra_bytes;
+ max_size = min_t(size_t, ec->ec_dev->max_request - extra_bytes,
+ type_max(typeof(param->set_program_ex.size)));
}
msg = alloc_lightbar_cmd_msg(ec);
--
2.55.0.508.g3f0d502094-goog
next prev parent reply other threads:[~2026-07-30 20:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 22:14 [PATCH] platform/chrome: lightbar: Enforce 8-bit payload limit Alexis Savery
2026-07-29 23:54 ` Benson Leung
2026-07-30 0:59 ` [PATCH v2] platform/chrome: lightbar: Limit payload size to EC bounding macro Alexis Savery
2026-07-30 0:59 ` [PATCH v3] platform/chrome: lightbar: Limit payload size to EC packet limit Alexis Savery
2026-07-30 3:32 ` Tzung-Bi Shih
2026-07-30 20:42 ` Alexis Savery [this message]
2026-07-31 2:24 ` [PATCH v4] platform/chrome: lightbar: Limit payload to max packet size Tzung-Bi Shih
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=20260730204240.2227178-1-asavery@google.com \
--to=asavery@google.com \
--cc=chrome-platform@lists.linux.dev \
--cc=tzungbi@kernel.org \
/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.