linux-kernel - Re: [PATCH v1 5/5] misc: fastrpc: Add missing unmapping user-requested remote heap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f3d376cc-6e2d-4ac3-88f6-3104eec67acf@oss.qualcomm.com>
Date: Thu, 12 Jun 2025 10:50:10 +0530
From: Ekansh Gupta <ekansh.gupta@....qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: srinivas.kandagatla@....qualcomm.com, linux-arm-msm@...r.kernel.org,
        gregkh@...uxfoundation.org, quic_bkumar@...cinc.com,
        linux-kernel@...r.kernel.org, quic_chennak@...cinc.com,
        dri-devel@...ts.freedesktop.org, arnd@...db.de, stable@...nel.org
Subject: Re: [PATCH v1 5/5] misc: fastrpc: Add missing unmapping
 user-requested remote heap



On 5/22/2025 5:43 PM, Dmitry Baryshkov wrote:
> On Thu, 22 May 2025 at 08:01, Ekansh Gupta
> <ekansh.gupta@....qualcomm.com> wrote:
>>
>>
>> On 5/19/2025 7:04 PM, Dmitry Baryshkov wrote:
>>> On Mon, May 19, 2025 at 04:28:34PM +0530, Ekansh Gupta wrote:
>>>> On 5/19/2025 4:22 PM, Dmitry Baryshkov wrote:
>>>>> On Tue, May 13, 2025 at 09:58:25AM +0530, Ekansh Gupta wrote:
>>>>>> User request for remote heap allocation is supported using ioctl
>>>>>> interface but support for unmap is missing. This could result in
>>>>>> memory leak issues. Add unmap user request support for remote heap.
>>>>> Can this memory be in use by the remote proc?
>>>> Remote heap allocation request is only intended for audioPD. Other PDs
>>>> running on DSP are not intended to use this request.
>>> 'Intended'. That's fine. I asked a different question: _can_ it be in
>>> use? What happens if userspace by mistake tries to unmap memory too
>>> early? Or if it happens intentionally, at some specific time during
>>> work.
>> If the unmap is restricted to audio daemon, then the unmap will only
>> happen if the remoteproc is no longer using this memory.
>>
>> But without this restriction, yes it possible that some userspace process
>> calls unmap which tries to move the ownership back to HLOS which the
>> remoteproc is still using the memory. This might lead to memory access
>> problems.
> This needs to be fixed in the driver. We need to track which memory is
> being used by the remoteproc and unmap it once remoteproc stops using
> it, without additional userspace intervention.
If it's the audio daemon which is requesting for unmap then it basically means that
the remoteproc is no longer using the memory. Audio PD can request for both grow
and shrink operations for it's dedicated heap. The case of grow is already supported
from fastrpc_req_mmap but the case of shrink(when remoteproc is no longer using the
memory) is not yet available. This memory is more specific to audio PD rather than
complete remoteproc.

If we have to control this completely from driver then I see a problem in freeing/unmapping
the memory when the PD is no longer using the memory.
>