The QMI message encoder has up until recently read a single byte (as
elem_size == 1), but with the introduction of big endian support it's
become apparent that this field is expected to be a full u32 -
regardless of the size of the length in the encoded message (which is
what elem_size specifies).
The result is that the encoder now reads past the length byte and
rejects the unreasonably large length formed when including the
following 3 bytes from the subsys_name array.
Fix this by changing to the expected type.
Fixes: 1fb82ee806d1 ("remoteproc: qcom: Introduce sysmon")
Signed-off-by: Bjorn Andersson <[email protected]>
---
I believe I've checked all the other users now, and this is the only
case I found that needs fixing.
Changes in v2:
- Fix the sysmon driver instead of the encoder/decoder
- Link to v1:
https://lore.kernel.org/r/20260214-qmi-encode-invalid-length-v1-0-780cb4e98...@oss.qualcomm.com
---
drivers/remoteproc/qcom_sysmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/remoteproc/qcom_sysmon.c b/drivers/remoteproc/qcom_sysmon.c
index
660ac6fc408213073942f20a2c4e43a0c9b9b37e..c6cc6e519fe566a92505dc57c30e8b3e0a697179
100644
--- a/drivers/remoteproc/qcom_sysmon.c
+++ b/drivers/remoteproc/qcom_sysmon.c
@@ -203,7 +203,7 @@ static const struct qmi_elem_info ssctl_shutdown_resp_ei[]
= {
};
struct ssctl_subsys_event_req {
- u8 subsys_name_len;
+ u32 subsys_name_len;
char subsys_name[SSCTL_SUBSYS_NAME_LENGTH];
u32 event;
u8 evt_driven_valid;
---
base-commit: fd9678829d6dd0c10fde080b536abf4b1121c346
change-id: 20260214-qmi-encode-invalid-length-310dd551a186
Best regards,
--
Bjorn Andersson <[email protected]>
