From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Jia-Ju Bai <baijiaju1990@gmail.com>
Cc: stanimir.varbanov@linaro.org, agross@kernel.org,
bjorn.andersson@linaro.org, linux-media@vger.kernel.org,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] media: venus: fix possible buffer overlow casued bad DMA value in venus_sfr_print()
Date: Fri, 27 Nov 2020 12:14:12 +0100 [thread overview]
Message-ID: <20201127121412.2c982188@coco.lan> (raw)
In-Reply-To: <20200530024117.24613-1-baijiaju1990@gmail.com>
Em Sat, 30 May 2020 10:41:17 +0800
Jia-Ju Bai <baijiaju1990@gmail.com> escreveu:
> The value hdev->sfr.kva is stored in DMA memory, and it is assigned to
> sfr, so sfr->buf_size can be modified at anytime by malicious hardware.
> In this case, a buffer overflow may happen when the code
> "sfr->data[sfr->buf_size - 1]" is executed.
>
> To fix this possible bug, sfr->buf_size is assigned to a local variable,
> and then this variable is checked before being used.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
> ---
> drivers/media/platform/qcom/venus/hfi_venus.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c b/drivers/media/platform/qcom/venus/hfi_venus.c
> index 0d8855014ab3..4251a9e47a1b 100644
> --- a/drivers/media/platform/qcom/venus/hfi_venus.c
> +++ b/drivers/media/platform/qcom/venus/hfi_venus.c
> @@ -960,18 +960,23 @@ static void venus_sfr_print(struct venus_hfi_device *hdev)
> {
> struct device *dev = hdev->core->dev;
> struct hfi_sfr *sfr = hdev->sfr.kva;
> + u32 buf_size;
> void *p;
>
> if (!sfr)
> return;
>
> - p = memchr(sfr->data, '\0', sfr->buf_size);
> + buf_size = sfr->buf_size;
> + if (buf_size > 1)
That seems plain wrong to me... I suspect you wanted to do,
instead:
if (buf_size < 1)
or even:
if (buf_size < 1 || buf_size >= maximum_size_of_data)
> + return;
> +
> + p = memchr(sfr->data, '\0', buf_size);
> /*
> * SFR isn't guaranteed to be NULL terminated since SYS_ERROR indicates
> * that Venus is in the process of crashing.
> */
> if (!p)
> - sfr->data[sfr->buf_size - 1] = '\0';
> + sfr->data[buf_size - 1] = '\0';
Well, a malicious hardware with DMA access could simply write 0 to
some random address, without needing to rely on the value
of sfr->buf_size. I can't see how a change like that would prevent
that.
A check like that only makes sense if the driver can ever
call this function with an invalid value for sfr->buf_size.
>
> dev_err_ratelimited(dev, "SFR message from FW: %s\n", sfr->data);
> }
Thanks,
Mauro
prev parent reply other threads:[~2020-11-27 11:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-30 2:41 [PATCH] media: venus: fix possible buffer overlow casued bad DMA value in venus_sfr_print() Jia-Ju Bai
2020-11-27 11:14 ` Mauro Carvalho Chehab [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=20201127121412.2c982188@coco.lan \
--to=mchehab+huawei@kernel.org \
--cc=agross@kernel.org \
--cc=baijiaju1990@gmail.com \
--cc=bjorn.andersson@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=stanimir.varbanov@linaro.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.