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: <8b696463-ec6e-4671-8176-432add3b0e70@oss.qualcomm.com>
Date: Mon, 2 Feb 2026 14:42:59 +0800
From: Jianping <jianping.li@....qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: srini@...nel.org, amahesh@....qualcomm.com, arnd@...db.de,
        gregkh@...uxfoundation.org, linux-arm-msm@...r.kernel.org,
        Ekansh Gupta <ekansh.gupta@....qualcomm.com>,
        thierry.escande@...aro.org, abelvesa@...nel.org,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        quic_chennak@...cinc.com, stable@...nel.org
Subject: Re: [PATCH v2 2/4] misc: fastrpc: Fix initial memory allocation for
 Audio PD memory pool



On 1/16/2026 4:45 AM, Dmitry Baryshkov wrote:
> On Thu, Jan 15, 2026 at 04:28:49PM +0800, Jianping Li wrote:
>> From: Ekansh Gupta <ekansh.gupta@....qualcomm.com>
>>
>> The initially allocated memory is not properly included in the pool,
>> leading to potential issues with memory management. The issue is
> 
> Define "properly" and be more explicit about "potential issues". Please
> be more precise in commit messages.
By “properly” I mean that the initially allocated buffer is supposed to 
be added into the Audio PD memory pool by setting pageslen accordingly.

With pageslen = 0, this buffer is never registered and therefore never 
becomes part of the pool.
I will drop the vague wording and describe the exact problem.
> 
>> actually a memory leak because the initial memory is never used by
> 
> Why is it not used?
Because pageslen = 0 indicates that no pages are provided.

As a result, Audio PD immediately issues a remote heap request, ignoring 
the initially allocated memory entirely.

That initial buffer becomes unreachable and is effectively leaked.
> 
>> Audio PD. It will immediately make a remote heap request as no memory is
> 
> Ok, you've described one issue. Beforehand it was "issues". Are there
> any others? if not, please drop the "potential issues" part.
There are no additional issues beyond the memory leak caused by the 
unused initial buffer.

I will remove the “potential issues” phrasing and state explicitly that 
the problem is a memory leak due to the initial buffer never being added 
to the pool.
> 
>> added to the pool initially. Set the number of pages to one to ensure
>> that the initially allocated memory is correctly added to the Audio PD
>> memory pool.
>>
>> Fixes: 0871561055e66 ("misc: fastrpc: Add support for audiopd")
>> Cc: stable@...nel.org
>> Co-developed-by: Ekansh Gupta <ekansh.gupta@....qualcomm.com>
>> Signed-off-by: Ekansh Gupta <ekansh.gupta@....qualcomm.com>
>> Signed-off-by: Jianping Li <jianping.li@....qualcomm.com>
>> ---
>>   drivers/misc/fastrpc.c | 8 ++++----
>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>
> 
> The patch  LGTM.
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ