From: Joel Selvaraj <joelselvaraj.oss@gmail.com>
To: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
Cc: "srinivas.kandagatla@linaro.org" <srinivas.kandagatla@linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Ekansh Gupta <quic_ekangupt@quicinc.com>,
stable <stable@kernel.org>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Subject: Re: [PATCH 6/6] misc: fastrpc: Restrict untrusted app to attach to privileged PD
Date: Thu, 15 Aug 2024 03:35:13 -0500 [thread overview]
Message-ID: <362eea30-7b6d-4cd5-aed9-88c0d014dd91@gmail.com> (raw)
In-Reply-To: <2024081535-unfasten-afloat-9684@gregkh>
Hi greg k-h,
The git commit id is: bab2f5e8fd5d2f759db26b78d9db57412888f187
But I am bit hesitant if we should revert it because there is a CVE
attached to it: https://ubuntu.com/security/CVE-2024-41024
Also, I am ok with changing userspace if it's necessary. It would be
nice if the authors can clarify the ideal fix here.
Regards,
Joel Selvaraj
On 8/15/24 00:15, gregkh@linuxfoundation.org wrote:
> On Thu, Aug 15, 2024 at 02:34:18AM +0000, Selvaraj, Joel (MU-Student) wrote:
>> Hi Srinivas Kandagatla and Ekansh Gupta,
>>
>> On 6/28/24 06:45, srinivas.kandagatla@linaro.org wrote:
>>> From: Ekansh Gupta <quic_ekangupt@quicinc.com>
>>>
>>> Untrusted application with access to only non-secure fastrpc device
>>> node can attach to root_pd or static PDs if it can make the respective
>>> init request. This can cause problems as the untrusted application
>>> can send bad requests to root_pd or static PDs. Add changes to reject
>>> attach to privileged PDs if the request is being made using non-secure
>>> fastrpc device node.
>>>
>>> Fixes: 0871561055e6 ("misc: fastrpc: Add support for audiopd")
>>> Cc: stable <stable@kernel.org>
>>> Signed-off-by: Ekansh Gupta <quic_ekangupt@quicinc.com>
>>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>>> ---
>>> drivers/misc/fastrpc.c | 22 +++++++++++++++++++---
>>> include/uapi/misc/fastrpc.h | 3 +++
>>> 2 files changed, 22 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
>>> index 5680856c0fb8..a7a2bcedb37e 100644
>>> --- a/drivers/misc/fastrpc.c
>>> +++ b/drivers/misc/fastrpc.c
>>> @@ -2087,6 +2087,16 @@ static int fastrpc_req_mem_map(struct fastrpc_user *fl, char __user *argp)
>>> return err;
>>> }
>>>
>>> +static int is_attach_rejected(struct fastrpc_user *fl)
>>> +{
>>> + /* Check if the device node is non-secure */
>>> + if (!fl->is_secure_dev) {
>>> + dev_dbg(&fl->cctx->rpdev->dev, "untrusted app trying to attach to privileged DSP PD\n");
>>> + return -EACCES;
>>> + }
>>> + return 0;
>>> +}
>>
>> This broke userspace for us. Sensors stopped working in SDM845 and other
>> qcom SoC devices running postmarketOS. Trying to communicate with the
>> fastrpc device just ends up with a permission denied error. This was
>> previously working. I am not sure if this is intended. Here are my two
>> observations:
>>
>> 1. if change the if condition to
>>
>> `if (!fl->is_secure_dev && fl->cctx->secure)`
>>
>> similar to how it's done in fastrpc's `is_session_rejected()` function,
>> then it works. But I am not sure if this is an valid fix. But currently,
>> fastrpc will simply deny access to all fastrpc device that contains the
>> `qcom,non-secure-domain` dt property. Is that the intended change?
>> Because I see a lot of adsp, cdsp and sdsp fastrpc nodes have that dt
>> property.
>>
>> 2. In the `fastrpc_rpmsg_probe()` function, it is commented that,
>>
>> "Unsigned PD offloading is only supported on CDSP"
>>
>> Does this mean adsp and sdsp shouldn't have the `qcom,non-secure-domain`
>> dt property? In fact, it was reported that removing this dt property and
>> using the `/dev/fastrpc-sdsp-secure` node instead works fine too. Is
>> this the correct way to fix it?
>>
>> I don't know much about fastrpc, just reporting the issue and guessing
>> here. It would be really if this can be fixed before the stable release.
>
> I will be glad to revert it, what was the git id for this in the tree
> now?
>
> thanks,
>
> greg k-h
next prev parent reply other threads:[~2024-08-15 8:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-28 11:44 [PATCH 0/6] misc: fastrpc: fixes for 6.10 srinivas.kandagatla
2024-06-28 11:44 ` [PATCH 1/6] misc: fastrpc: Fix DSP capabilities request srinivas.kandagatla
2024-06-28 11:44 ` [PATCH 2/6] misc: fastrpc: Copy the complete capability structure to user srinivas.kandagatla
2024-06-28 11:44 ` [PATCH 3/6] misc: fastrpc: Avoid updating PD type for capability request srinivas.kandagatla
2024-06-28 11:44 ` [PATCH 4/6] misc: fastrpc: Fix memory leak in audio daemon attach operation srinivas.kandagatla
2024-06-28 11:45 ` [PATCH 5/6] misc: fastrpc: Fix ownership reassignment of remote heap srinivas.kandagatla
2024-06-28 11:45 ` [PATCH 6/6] misc: fastrpc: Restrict untrusted app to attach to privileged PD srinivas.kandagatla
2024-08-15 2:34 ` Selvaraj, Joel (MU-Student)
2024-08-15 5:15 ` gregkh
2024-08-15 5:17 ` gregkh
2024-08-15 8:35 ` Joel Selvaraj [this message]
2024-08-15 8:41 ` gregkh
2024-08-15 10:02 ` gregkh
2024-08-15 10:16 ` Joel Selvaraj
2024-08-15 13:30 ` Srinivas Kandagatla
2024-08-15 13:43 ` gregkh
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=362eea30-7b6d-4cd5-aed9-88c0d014dd91@gmail.com \
--to=joelselvaraj.oss@gmail.com \
--cc=dmitry.baryshkov@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_ekangupt@quicinc.com \
--cc=srinivas.kandagatla@linaro.org \
--cc=stable@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