From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4865B3A48E6 for ; Thu, 30 Jul 2026 04:52:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785387162; cv=none; b=mcRaFnbLcwisaISzvZox8UMOHBK2ZKlwxG1FAjx9kwu2gtqAjytgzH2G4rjvWb68tj2ema8xQS7U2LrZ4jDZT8TrfJXBHPnd7NxUAaxJ7wcSYp9t6fXa2MHRRCXMy25rVVvjpyFAMMRSC24YS/hFjTOpI4iigT7n4jPey/djLPo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785387162; c=relaxed/simple; bh=9R1jnhq2oXjdoMBKLvZuU0Q/c4UWJnm/6cs+1wVuRyY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=PPsI1OsvtXz48C6y52pKPGsnhdL8RLliaLJQNsQOSMYaFluLfNhkAunZ+07UozPSw/5lgXzjeJpBJNycaiVeg/lGABvVj1f409UYgtM1nFsAGvN4erXxyNwOC6XpKHqYZgHFsOtvTTPXdB59qhTR0/SOSfT+ug9PQ6mYRILCztg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=fir2qQNx; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=NvPS2KRX; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="fir2qQNx"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="NvPS2KRX" Received: from pps.filterd (m0279866.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 66U4bOm73736633 for ; Thu, 30 Jul 2026 04:52:40 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= kTnb0bbBTOh0ujs8xWkkOVPWXcBEgS7OoCRQ+dvQBes=; b=fir2qQNxhq8EnkM7 DvTLumrNy8XRHoHnQEsATqTf0fbMZyUte1xt2nwo8+jSAV5pfVyMsxhXXptxFqD2 XURBZg3KGec47VkFQjsEzJUWpvTOnQaq00AkH8cO8YavrB7cYzI1pnmZcXaDatPs 7VIJCzlHL6H3eGfTNCsh4b0x6WJbJ5LWADmMIXovkbOsysT9XnGaij5rNPMQ5iOO MagHalEgOEfyYhknPKBMkP5tyNwTOpKvvngGl7WwejYFQ1W3UWWfhr9fjIWgUNNe sPLZv5noskD2EB7fMc4gEcYa2cmbljuXCYq3LM9L3OenaXlgvU42Di6rTuBUNRCS 62u5MA== Received: from mail-pg1-f197.google.com (mail-pg1-f197.google.com [209.85.215.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4fqyra01qq-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Thu, 30 Jul 2026 04:52:40 +0000 (GMT) Received: by mail-pg1-f197.google.com with SMTP id 41be03b00d2f7-c9fe4c5eb39so1093093a12.1 for ; Wed, 29 Jul 2026 21:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1785387159; x=1785991959; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=kTnb0bbBTOh0ujs8xWkkOVPWXcBEgS7OoCRQ+dvQBes=; b=NvPS2KRXqf8dz6dO4mTatDuw6mQJaX/lejg6G/yxpsVLO2o3UZlduLftpKfwipLn/+ Zu9+uBOv9enX7iPFs0LCGFuGI8dICXl44yJP2zSQev2NXgpipoxNuR2Z7c+j2LbdJ+l8 VCukmUpmPFZUZNCaM7QS7wCW35vDHqQBEQPbp5jLx+x15sbb/QqRTI2M8P4IKW2maOCp veewvi8C8NEFNWbrtL9CQaAQpPwo4U1oguXSE3HWkHkg5yuk1vAJyrPt91uSBWe9Hwig ShNyK8SJol96mmdKZD5rkPHS9G7HS7f1THjMyuy6W+2yq2/DeIm7bme7c07bpwQimfFk HXqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785387159; x=1785991959; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=kTnb0bbBTOh0ujs8xWkkOVPWXcBEgS7OoCRQ+dvQBes=; b=LH1YtEwdwuqP/qksgZnm9Hzm5KpxYpn1D+AKGSPEfz6tkr+WZfnIXnb2UReQKqKXGS PvCzVPtWCm0zBtR5yMJE2aEy3x68cRfrImQFCLVGRGuW9isQi+xI/EaNbtiEs8C3CQdV lkM6Q+cHP4HjDjYlB1OeOVgldG0gpJOcjd4yS3Yh4SPgcfrd/8m07FFno/H7o4+nR96r EOyl+Umyz665zE2ocssaLB8W0P+XaUXJcUKfeVYAN52ikIV9eYsL/aNSmCKZAQQqSPFX 4Tg0aeC4Lre7SgMM5Vk79p/OywF7BC6VWcS5zWTUMFC5MdeUP6z0Ui3GmxfmzN7Dsn/f wUVg== X-Forwarded-Encrypted: i=1; AHgh+RqBNySqEdzgk7wmR70h/TszeYD02XBsT2IAux4lG0XM7n7HoFtcmCuwkefFtHzNblzdXFj3mW1Kw25h28Q=@vger.kernel.org X-Gm-Message-State: AOJu0Yx45PyNTZ6ayEBvSnVoDjznfrAIkAbgz+6NIhp8N6n0Y1ozYkHh BZdx/71PxuzaSMaEUvjB3ni5VbzTNIlL0se0PRVqfPDYip5nUsWDa+Ukw6l32xVPB6B6O0PFGZg Ls1FhH6i6vQURt7pf3sKmBehcOEO9iM4odjsa4aiiAvlYFJkAADl1x7vC5XsnV/9YjEw= X-Gm-Gg: AR+sD12HTIEkm9c52mxo0i1cmTPYxDvVl+HW+YLu/14FHwlgKRbmyxVbjgU8BSUQuwt 4RCy0Zc6WySgbeaE/44p3UroJ+nv06NZYEYKwgwGh+MC5kc93h5LNbIfCo6VaWQYKxrJVRAj9q3 CCvkOHAP7TI8yiH2iJC/FgAZ1gnXj7Z5Dv8zydnG/2LZjgOWc/4XjMYI+3CXfZ0/qmZBnT6VZiL 4JaFETLLEvudrxNA6mBOlDquda94gM0m3OiIHGNM42gMhlPkx0j87to2DK67x7V9HSFpAE0CzAw SOLVd/ojpdoGkxlNTcMox3o6J+XJDNLPEMyeSN91b2L94xQeicO+YmlhSeilTizfL9qVx0PCPcv dvPMoFZk6xnEcw3ySYzCrjs0Bx6VTKA== X-Received: by 2002:a05:6a20:7f99:b0:3c4:42d9:58e3 with SMTP id adf61e73a8af0-3c90066b1c6mr1078120637.13.1785387159497; Wed, 29 Jul 2026 21:52:39 -0700 (PDT) X-Received: by 2002:a05:6a20:7f99:b0:3c4:42d9:58e3 with SMTP id adf61e73a8af0-3c90066b1c6mr1078107637.13.1785387159035; Wed, 29 Jul 2026 21:52:39 -0700 (PDT) Received: from [10.204.78.242] ([202.46.23.25]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-cbdb78ae98asm1601217a12.1.2026.07.29.21.52.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Jul 2026 21:52:38 -0700 (PDT) Message-ID: <7942487a-1a1c-41bd-850b-25f1f4bb0773@oss.qualcomm.com> Date: Thu, 30 Jul 2026 10:22:33 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] misc: fastrpc: fix UAF and kernel panic during cleanup on process abort To: Jianping Li , Srinivas Kandagatla , Amol Maheshwari Cc: Arnd Bergmann , Greg Kroah-Hartman , Thierry Escande , linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, quic_chennak@quicinc.com, stable@kernel.org References: <20260630063409.475-1-jianping.li@oss.qualcomm.com> Content-Language: en-US From: Ekansh Gupta In-Reply-To: <20260630063409.475-1-jianping.li@oss.qualcomm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-ORIG-GUID: DCGP27UpzQWhpHgr0bWF-xWH4TSbOp97 X-Authority-Analysis: v=2.4 cv=N4wZ0W9B c=1 sm=1 tr=0 ts=6a6ad898 cx=c_pps a=rz3CxIlbcmazkYymdCej/Q==:117 a=ZePRamnt/+rB5gQjfz0u9A==:17 a=IkcTkHD0fZMA:10 a=RAioF0-LDSMA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=YMgV9FUhrdKAYTUUvYB2:22 a=VwQbUJbxAAAA:8 a=EUspDBNiAAAA:8 a=IFEFMmON-DzK0gGTnVEA:9 a=QEXdDO2ut3YA:10 a=bFCP_H2QrGi7Okbo017w:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzMwMDAzMCBTYWx0ZWRfX6XV3uwI29izm QgocY5xip0HjHp5PKfdKcqPthkZZYoZ6DBb98zwk01WdHGRvOodH5JZlpZERCDcg661RxTvR9a6 3xBQWuIA4jg7/q0A+Kt4ktxcYx3nmPCf5NcMZ9XomhE0W0coWJHh0FLF0wIbiDIFFAEuw446Dna Pc57/6+LbtXR1c6jmoCnGi/aRZGAUuNxA1GzA5pVrX8DEU0RNdq4wv8UF0zdYyhDicBUh7mwaAb X97HM2lLs+/TxI6PT7hfYzyP0LN8yanUE67R5IT9Nf6Re9wZmHzJcTHxPULrjKTl44A8aaLDUWK ARTmcgH725zHDQwyJwQNCcf54Z1tHdb24kbB8uVmDlXs2hBuSdiOzSpNXz7bfrlcDfsWJSq2aaz eNq7sBJugh9UlyDEvViMYpLl+DpG2I220U7+4p0a+aIOwfVEC687HM5ehi0QZE40x6lugBqqMZg jBbOTrCl1Cn2Nnd9UmQ== X-Proofpoint-Spam-Info: AW1haW4tMjYwNzMwMDAzMCBTYWx0ZWRfX92jVJQsgJ0IV GGZ0S/aDfWfrac4MHGG6J3ptj3JA7u/dIqicF/y40zEAiYVN/I0Z5RXx5ANOMdaHzCiN7+/x3y9 4w+29NvuCq9B7cxpMQVrEqGRFjNaZQ0= X-Proofpoint-GUID: DCGP27UpzQWhpHgr0bWF-xWH4TSbOp97 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-07-30_01,2026-07-29_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 impostorscore=0 malwarescore=0 lowpriorityscore=0 spamscore=0 adultscore=0 phishscore=0 bulkscore=0 clxscore=1015 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2607300030 On 30-06-2026 12:04, Jianping Li wrote: > When a userspace FastRPC client is abruptly terminated, FastRPC > cleanup paths can race with device and session teardown. > > This results in kernel panics in different release paths: > - fastrpc_release() when using remote heap, originating from > fastrpc_buf_free() > - fastrpc_device_release() when using system heap, originating from > fastrpc_free_map() > > In addition, fastrpc_map_put() may trigger refcount use-after-free > due to concurrent cleanup without proper synchronization. > > The root cause is that buffer and map cleanup paths may access map > and buf resources after the associated device or session has > already been released. > > Fix this by: > - Introducing mutex protection for map and buf lifetime > - Serializing buffer and map cleanup against device teardown > - Skipping buffer and map operations when the device is already gone > > These changes ensure cleanup paths are safe against unexpected > process aborts and prevent use-after-free and kernel panic scenarios. > > Fixes: c68cfb718c8f9 ("misc: fastrpc: Add support for context Invoke method") > Cc: stable@kernel.org > Signed-off-by: Jianping Li > --- > drivers/misc/fastrpc.c | 57 ++++++++++++++++++++++++++++++++++++++---- > 1 file changed, 52 insertions(+), 5 deletions(-) > > diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c > index a9b2ae44c06f..3521518f9fe5 100644 > --- a/drivers/misc/fastrpc.c > +++ b/drivers/misc/fastrpc.c > @@ -255,6 +255,8 @@ struct fastrpc_session_ctx { > int sid; > bool used; > bool valid; > + bool allocated; > + struct mutex mutex; > }; > > struct fastrpc_soc_data { > @@ -335,9 +337,14 @@ static inline u64 fastrpc_sid_offset(struct fastrpc_channel_ctx *cctx, > static void fastrpc_free_map(struct kref *ref) > { > struct fastrpc_map *map; > + struct fastrpc_user *fl; > > map = container_of(ref, struct fastrpc_map, refcount); > > + fl = map->fl; > + if (!fl) > + return; > + > if (map->table) { > if (map->attr & FASTRPC_ATTR_SECUREMAP) { > struct qcom_scm_vmperm perm; > @@ -356,10 +363,16 @@ static void fastrpc_free_map(struct kref *ref) > return; > } > } > + mutex_lock(&fl->sctx->mutex); > + if (!fl->sctx->dev) { > + mutex_unlock(&fl->sctx->mutex); in this case, should you still delete map from fl->maps list? should you still do dma_buf_put to remove dma_buf reference? Also, there was a recent change where fl refcounting was added[1]. Can you see if you can take use of that mechanism instead of adding checks at all these places? [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/misc/fastrpc.c?id=e85eb5feca8e254905ffa6c57a3c99c89a674a0f> + return; > + } > dma_buf_unmap_attachment_unlocked(map->attach, map->table, > DMA_BIDIRECTIONAL); > dma_buf_detach(map->buf, map->attach); > dma_buf_put(map->buf); > + mutex_unlock(&fl->sctx->mutex); > } > > if (map->fl) { > @@ -422,9 +435,18 @@ static int fastrpc_map_lookup(struct fastrpc_user *fl, int fd, > > static void fastrpc_buf_free(struct fastrpc_buf *buf) > { > - dma_free_coherent(buf->dev, buf->size, buf->virt, > - fastrpc_ipa_to_dma_addr(buf->fl->cctx, buf->dma_addr)); > - kfree(buf); > + struct fastrpc_user *fl = buf->fl; > + > + if (!fl) > + return; > + mutex_lock(&fl->sctx->mutex); > + if (fl->sctx->dev) { > + dma_free_coherent(buf->dev, buf->size, buf->virt, > + fastrpc_ipa_to_dma_addr(buf->fl->cctx, > + buf->dma_addr)); > + kfree(buf); kfree should happen unconditionally here, it's a leak if you skip it. //ekansh> + } > + mutex_unlock(&fl->sctx->mutex); > } > > static int __fastrpc_buf_alloc(struct fastrpc_user *fl, struct device *dev, > @@ -447,8 +469,11 @@ static int __fastrpc_buf_alloc(struct fastrpc_user *fl, struct device *dev, > buf->dev = dev; > buf->raddr = 0; > > - buf->virt = dma_alloc_coherent(dev, buf->size, &buf->dma_addr, > - GFP_KERNEL); > + mutex_lock(&fl->sctx->mutex); > + if (fl->sctx->dev) > + buf->virt = dma_alloc_coherent(dev, buf->size, &buf->dma_addr, > + GFP_KERNEL); > + mutex_unlock(&fl->sctx->mutex); > if (!buf->virt) { > mutex_destroy(&buf->lock); > kfree(buf); > @@ -491,6 +516,10 @@ static void fastrpc_channel_ctx_free(struct kref *ref) > struct fastrpc_channel_ctx *cctx; > > cctx = container_of(ref, struct fastrpc_channel_ctx, refcount); > + for (int i = 0; i < FASTRPC_MAX_SESSIONS; i++) { > + if (cctx->session[i].allocated) > + mutex_destroy(&cctx->session[i].mutex); > + } > > kfree(cctx); > } > @@ -855,19 +884,28 @@ static int fastrpc_map_attach(struct fastrpc_user *fl, int fd, > goto get_err; > } > > + mutex_lock(&fl->sctx->mutex); > + if (!fl->sctx->dev) { > + err = -ENODEV; > + mutex_unlock(&fl->sctx->mutex); > + goto attach_err; > + } > map->attach = dma_buf_attach(map->buf, sess->dev); > if (IS_ERR(map->attach)) { > dev_err(sess->dev, "Failed to attach dmabuf\n"); > err = PTR_ERR(map->attach); > + mutex_unlock(&fl->sctx->mutex); > goto attach_err; > } > > table = dma_buf_map_attachment_unlocked(map->attach, DMA_BIDIRECTIONAL); > if (IS_ERR(table)) { > err = PTR_ERR(table); > + mutex_unlock(&fl->sctx->mutex); > goto map_err; > } > map->table = table; > + mutex_unlock(&fl->sctx->mutex); > > if (attr & FASTRPC_ATTR_SECUREMAP) > map->dma_addr = sg_phys(map->table->sgl); > @@ -2246,6 +2284,8 @@ static int fastrpc_cb_probe(struct platform_device *pdev) > sess->used = false; > sess->valid = true; > sess->dev = dev; > + mutex_init(&sess->mutex); > + sess->allocated = true; > dev_set_drvdata(dev, sess); > sess->sid = sid; > > @@ -2260,6 +2300,8 @@ static int fastrpc_cb_probe(struct platform_device *pdev) > break; > dup_sess = &cctx->session[cctx->sesscount++]; > memcpy(dup_sess, sess, sizeof(*dup_sess)); > + mutex_init(&dup_sess->mutex); > + dup_sess->allocated = true; > } > } > spin_unlock_irqrestore(&cctx->lock, flags); > @@ -2282,6 +2324,11 @@ static void fastrpc_cb_remove(struct platform_device *pdev) > spin_lock_irqsave(&cctx->lock, flags); > for (i = 0; i < FASTRPC_MAX_SESSIONS; i++) { > if (cctx->session[i].sid == sess->sid) { > + spin_unlock_irqrestore(&cctx->lock, flags); > + mutex_lock(&cctx->session[i].mutex); > + cctx->session[i].dev = NULL; > + mutex_unlock(&cctx->session[i].mutex); > + spin_lock_irqsave(&cctx->lock, flags); > cctx->session[i].valid = false; > cctx->sesscount--; > }