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: <0e2b2819-dc54-4038-0046-712a3391c595@quicinc.com>
Date:   Wed, 26 Jul 2023 13:10:54 +0530
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.0
Subject: Re: [PATCH v2] misc: fastrpc: Fix incorrect DMA mapping unmap request
To:     Bjorn Andersson <andersson@kernel.org>
CC:     <srinivas.kandagatla@linaro.org>, <linux-arm-msm@vger.kernel.org>,
        <ekangupt@qti.qualcomm.com>, <gregkh@linuxfoundation.org>,
        <linux-kernel@vger.kernel.org>,
        <fastrpc.upstream@qti.qualcomm.com>, stable <stable@kernel.org>
References: <1690182571-7348-1-git-send-email-quic_ekangupt@quicinc.com>
 <zo6wjmqolvnla7x24qguh6rbjpf7l62vmckxhy3nps7hhaljdr@kyoh6xedhxaq>
Content-Language: en-US
From:   Ekansh Gupta <quic_ekangupt@quicinc.com>
In-Reply-To: <zo6wjmqolvnla7x24qguh6rbjpf7l62vmckxhy3nps7hhaljdr@kyoh6xedhxaq>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 7/26/2023 12:00 PM, Bjorn Andersson wrote:
> On Mon, Jul 24, 2023 at 12:39:31PM +0530, Ekansh Gupta wrote:
>> Scatterlist table is obtained during map create request and the same
> 
> I'm guessing that this all happens in fastrpc_map_create() where:
> 
>    map->table = dma_buf_map_attachment_unlocked(map->attach, DMA_BIDIRECTIONAL);
> 
> fails, we jump to map_err, and then call fastrpc_map_put(map), which
> then ends up in the code below?
> 
yes, your understanding is correct.
>> table is used for DMA mapping unmap. In case there is any failure
>> while getting the sg_table, ERR_PTR is returned instead of sg_table.
> 
> The problem isn't that ERR_PTR() is being returned, the problem is that
> this is being assigned to map->table and you keep running.
> 
>>
>> When the map is getting freed, there is only a non-NULL check of
>> sg_table which will also be true in case failure was returned instead
>> of sg_table. This would result in improper unmap request. Add proper
>> check to avoid bad unmap request.
>>
>> Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method")
>> Cc: stable <stable@kernel.org>
>> Tested-by: Ekansh Gupta <quic_ekangupt@quicinc.com>
> 
> You always test your own patches, so no need to declare this.
> 
sure, I'll avoid adding this for future changes.
>> Signed-off-by: Ekansh Gupta <quic_ekangupt@quicinc.com>
>> ---
>> Changes in v2:
>>    - Added fixes information to commit text
>>
>>   drivers/misc/fastrpc.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
>> index 9666d28..75da69a 100644
>> --- a/drivers/misc/fastrpc.c
>> +++ b/drivers/misc/fastrpc.c
>> @@ -313,7 +313,7 @@ static void fastrpc_free_map(struct kref *ref)
>>   
>>   	map = container_of(ref, struct fastrpc_map, refcount);
>>   
>> -	if (map->table) {
>> +	if (map->table && !IS_ERR(map->table)) {
> 
> Rather than carrying around an IS_ERR(map->table), I think you should
> address this at the originating place. E.g. assign the return value of
> the dma_buf_map_attachment_unlocked() to a local variable and only if it
> is valid you assign map->table. Or perhaps make it NULL in the error
> path.
> 
understood, this looks much cleaner solution. I'll update this in the 
next patch. Thanks for taking your time to review this change, Bjorn.
--ekansh

> Regards,
> Bjorn
> 
>>   		if (map->attr & FASTRPC_ATTR_SECUREMAP) {
>>   			struct qcom_scm_vmperm perm;
>>   			int vmid = map->fl->cctx->vmperms[0].vmid;
>> -- 
>> 2.7.4
>>