Add bounds check on values read from shared memory in the tx path. In
cases where the VM is misbehaving, the transport should exit and print a
warning when bogus values may cause out of bounds to be read.
Link: https://git.codelinaro.org/clo/la/kernel/msm-5.10/-/commit/32d9c3a2f2b6a4d1fc48d6871194f3faf3184e8b
Suggested-by: Chris Lew <[email protected]>
Suggested-by: Sarannya S <[email protected]>
Signed-off-by: Michal Koutný <[email protected]>
---
drivers/rpmsg/qcom_glink_smem.c | 9 +++++++++
1 file changed, 9 insertions(+)
Why RFC? The patch is adopted from the link above. It would be good to
asses whether such conditions can also happen with rpmsg glink.
(And if so, whether the zeroed values are the best correction.)
diff --git a/drivers/rpmsg/qcom_glink_smem.c b/drivers/rpmsg/qcom_glink_smem.c
index 7a982c60a8dd..3e786e590c03 100644
--- a/drivers/rpmsg/qcom_glink_smem.c
+++ b/drivers/rpmsg/qcom_glink_smem.c
@@ -146,6 +146,11 @@ static size_t glink_smem_tx_avail(struct qcom_glink_pipe *np)
else
avail -= FIFO_FULL_RESERVE + TX_BLOCKED_CMD_RESERVE;
+ if (avail > pipe->native.length) {
+ pr_warn_once("%s: avail clamped\n", __func__);
+ avail = 0;
+ }
+
return avail;
}
@@ -177,6 +182,10 @@ static void glink_smem_tx_write(struct qcom_glink_pipe *glink_pipe,
unsigned int head;
head = le32_to_cpu(*pipe->head);
+ if (head > pipe->native.length) {
+ pr_warn_once("%s: head overflow\n", __func__);
+ return;
+ }
head = glink_smem_tx_write_one(pipe, head, hdr, hlen);
head = glink_smem_tx_write_one(pipe, head, data, dlen);
--
2.43.0
On 1/13/2024 5:55 AM, Michal Koutný wrote:
> Add bounds check on values read from shared memory in the tx path. In
> cases where the VM is misbehaving, the transport should exit and print a
> warning when bogus values may cause out of bounds to be read.
>
> Link: https://git.codelinaro.org/clo/la/kernel/msm-5.10/-/commit/32d9c3a2f2b6a4d1fc48d6871194f3faf3184e8b
> Suggested-by: Chris Lew <[email protected]>
> Suggested-by: Sarannya S <[email protected]>
> Signed-off-by: Michal Koutný <[email protected]>
> ---
> drivers/rpmsg/qcom_glink_smem.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> Why RFC? The patch is adopted from the link above. It would be good to
> asses whether such conditions can also happen with rpmsg glink.
> (And if so, whether the zeroed values are the best correction.)
>
Hi Michal,
There is already a patch posted for similar problem -
https://lore.kernel.org/all/[email protected]/
> diff --git a/drivers/rpmsg/qcom_glink_smem.c b/drivers/rpmsg/qcom_glink_smem.c
> index 7a982c60a8dd..3e786e590c03 100644
> --- a/drivers/rpmsg/qcom_glink_smem.c
> +++ b/drivers/rpmsg/qcom_glink_smem.c
> @@ -146,6 +146,11 @@ static size_t glink_smem_tx_avail(struct qcom_glink_pipe *np)
> else
> avail -= FIFO_FULL_RESERVE + TX_BLOCKED_CMD_RESERVE;
>
> + if (avail > pipe->native.length) {
> + pr_warn_once("%s: avail clamped\n", __func__);
> + avail = 0;
> + }
> +
> return avail;
> }
>
> @@ -177,6 +182,10 @@ static void glink_smem_tx_write(struct qcom_glink_pipe *glink_pipe,
> unsigned int head;
>
> head = le32_to_cpu(*pipe->head);
> + if (head > pipe->native.length) {
> + pr_warn_once("%s: head overflow\n", __func__);
> + return;
> + }
>
> head = glink_smem_tx_write_one(pipe, head, hdr, hlen);
> head = glink_smem_tx_write_one(pipe, head, data, dlen);
On Mon, Jan 29, 2024 at 04:18:36PM +0530, Deepak Kumar Singh <[email protected]> wrote:
> There is already a patch posted for similar problem -
> https://lore.kernel.org/all/[email protected]/
I was not aware, thanks for the pointer.
Do you plan to update your patch to "just" bail-out/zero instead of
using slightly random values (as pointed out by Bjorn)?
Michal
On 1/29/2024 10:03 PM, Michal Koutný wrote:
> On Mon, Jan 29, 2024 at 04:18:36PM +0530, Deepak Kumar Singh <[email protected]> wrote:
>> There is already a patch posted for similar problem -
>> https://lore.kernel.org/all/[email protected]/
>
> I was not aware, thanks for the pointer.
>
> Do you plan to update your patch to "just" bail-out/zero instead of
> using slightly random values (as pointed out by Bjorn)?
>
> Michal
Hi Michal,
Yes, i will be fixing those comments and re post patch.