Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <01bdf6e2-f72a-e114-f3d2-deccf55403b1@linaro.org>
Date:   Fri, 2 Sep 2022 11:02:35 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH 0/3] misc: fastrpc: fix memory corruption
Content-Language: en-US
To:     Johan Hovold <johan+linaro@kernel.org>,
        Amol Maheshwari <amahesh@qti.qualcomm.com>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Arnd Bergmann <arnd@arndb.de>,
        Bjorn Andersson <andersson@kernel.org>,
        Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
        linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20220829080531.29681-1-johan+linaro@kernel.org>
From:   Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
In-Reply-To: <20220829080531.29681-1-johan+linaro@kernel.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi Johan,

On 29/08/2022 09:05, Johan Hovold wrote:
> The fastrpc driver uses a fixed-sized array to store its sessions but
> missing and broken sanity checks could lead to memory beyond the array
> being corrupted.
> 
> This specifically happens on SC8280XP platforms that use 14 sessions for
> the compute DSP.
> 
Thanks for doing this.

I see that we hit this issue once again, and the way we are fixing it is 
not really scalable. We should really get rid of FASTRPC_MAX_SESSIONS.

We should allocate the sessions dynamically based in the child node 
count and qcom,nsessions.


thanks,
Srini

> These are all needed for 6.0.
> 
> Johan
> 
> 
> Johan Hovold (3):
>    misc: fastrpc: fix memory corruption on probe
>    misc: fastrpc: fix memory corruption on open
>    misc: fastrpc: increase maximum session count
> 
>   drivers/misc/fastrpc.c | 14 +++++++++-----
>   1 file changed, 9 insertions(+), 5 deletions(-)
>