Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
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


      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