From: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
To: Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>,
Alexander Wilhelm <alexander.wilhelm@westermo.com>,
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Subject: [PATCH 2/2] soc: qcom: qmi: Avoid splatting the "length" destination field
Date: Sat, 14 Feb 2026 15:16:56 -0600 [thread overview]
Message-ID: <20260214-qmi-encode-invalid-length-v1-2-780cb4e98b0f@oss.qualcomm.com> (raw)
In-Reply-To: <20260214-qmi-encode-invalid-length-v1-0-780cb4e98b0f@oss.qualcomm.com>
When decoding a variable-length element from a QMI message the length is
either a u8 or u16 field in the destination C-struct, but the current
implementation prepares the value on the stack and then writes out a
whole word.
In a little endian system, this results in the following 2 or 3 bytes
being zeroed out, and then presumably overwritten by the actual payload.
So unless the length field is followed by an unreasonably short array,
the splat is contained - but unnecessary.
While not verified, in a big endian system, the length should end up
beyond the length field, resulting in a 0-length value with "garbage" in
the payload.
Given the expectation that the QMI message is decoded into the naturally
aligned byte or short-sized length, we can simply read the
endian-correct length back from the destination buffer and use this for
further processing.
Fixes: fe099c387e06 ("soc: qcom: preserve CPU endianness for QMI_DATA_LEN")
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
---
drivers/soc/qcom/qmi_encdec.c | 26 ++++++++++----------------
1 file changed, 10 insertions(+), 16 deletions(-)
diff --git a/drivers/soc/qcom/qmi_encdec.c b/drivers/soc/qcom/qmi_encdec.c
index 45bb26d010da77ab8d481897026b718c2290bad7..149af7f7c9833e1f3501f96c989ce9bd58ccb8a0 100644
--- a/drivers/soc/qcom/qmi_encdec.c
+++ b/drivers/soc/qcom/qmi_encdec.c
@@ -712,8 +712,6 @@ static int qmi_decode(const struct qmi_elem_info *ei_array, void *out_c_struct,
u32 decoded_bytes = 0;
const void *buf_src = in_buf;
int rc;
- u8 val8;
- u16 val16;
while (decoded_bytes < in_buf_len) {
if (dec_level >= 2 && temp_ei->data_type == QMI_EOTI)
@@ -752,20 +750,16 @@ static int qmi_decode(const struct qmi_elem_info *ei_array, void *out_c_struct,
if (temp_ei->data_type == QMI_DATA_LEN) {
data_len_sz = temp_ei->elem_size == sizeof(u8) ?
sizeof(u8) : sizeof(u16);
- if (data_len_sz == sizeof(u8)) {
- rc = qmi_decode_basic_elem(&val8, buf_src,
- 1, data_len_sz);
- if (rc < 0)
- return rc;
- data_len_value = (u32)val8;
- } else {
- rc = qmi_decode_basic_elem(&val16, buf_src,
- 1, data_len_sz);
- if (rc < 0)
- return rc;
- data_len_value = (u32)val16;
- }
- memcpy(buf_dst, &data_len_value, sizeof(u32));
+
+ rc = qmi_decode_basic_elem(buf_dst, buf_src, 1, data_len_sz);
+ if (rc < 0)
+ return rc;
+
+ if (data_len_sz == sizeof(u8))
+ data_len_value = *(u8 *)buf_dst;
+ else
+ data_len_value = *(u16 *)buf_dst;
+
temp_ei = temp_ei + 1;
buf_dst = out_c_struct + temp_ei->offset;
tlv_len -= data_len_sz;
--
2.51.0
prev parent reply other threads:[~2026-02-14 21:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-14 21:16 [PATCH 0/2] soc: qcom: qmi: Fix endianess-related issues in encdec Bjorn Andersson
2026-02-14 21:16 ` [PATCH 1/2] soc: qcom: qmi: Fix "invalid data length" in encoder Bjorn Andersson
2026-02-16 8:58 ` Alexander Wilhelm
2026-02-16 15:25 ` Bjorn Andersson
2026-02-18 18:00 ` Jeff Johnson
2026-02-18 18:53 ` Bjorn Andersson
2026-02-19 19:18 ` Bjorn Andersson
2026-02-19 21:25 ` Jeff Johnson
2026-02-20 3:20 ` Bjorn Andersson
2026-02-14 21:16 ` Bjorn Andersson [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=20260214-qmi-encode-invalid-length-v1-2-780cb4e98b0f@oss.qualcomm.com \
--to=bjorn.andersson@oss.qualcomm.com \
--cc=alexander.wilhelm@westermo.com \
--cc=andersson@kernel.org \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox