[PATCH v2 0/4] misc: fastrpc: add extended IOVA mapping support

[PATCH v2 0/4] misc: fastrpc: add extended IOVA mapping support

[Vinayak Katoch]

FastRPC context banks on kaanapali and glymur are limited to a 34-bit
IOVA window. Large compute workloads such as LLM inference on the CDSP
require mapping buffers that exceed this range. Dedicated extended
context banks exist in hardware but were unused by the driver.

This series wires up end-to-end driver and binding support:

  - Relax the DT binding to allow 64-bit iommu-ranges values on
    platforms that require extended addressing.

  - Fix SID extraction to read the correct cell of the reg property
    on platforms with #address-cells = <2>.

  - Detect extended context banks by the presence of iommu-ranges and
    register them separately so large allocations can be directed into
    the wider IOVA window.

  - Add two UAPI flags (FASTRPC_MAP_FD_EXTENDED and
    FASTRPC_MAP_FD_DELAYED_EXTENDED) so userspace can explicitly request
    mapping via an extended CB.

Signed-off-by: Vinayak Katoch <vinayak.katoch@oss.qualcomm.com>
---
Changes in v2:
- Split DTS changes (kaanapali, glymur) into a separate series.
- Fix DT binding to allow iommu-ranges on compute-cb subnodes.
- Fix krealloc() called with GFP_KERNEL under spinlock.
- Fix dma_set_mask() error path leaving stale ext_cb entry.
- Fix ext_cb sessions not invalidated in fastrpc_cb_devices_destroy().
- Fix lockless read of ext_cb[]/ext_cb_count in fastrpc_map_attach().
- Fix fastrpc_free_map() using fl->sctx->dev for extended-CB maps.
- Fix fastrpc_map_create() reusing a cached map with mismatched CB flags.
- Link to v1: https://lore.kernel.org/r/20260826-extended-mapping-v1-0-d046c1cb9a9f@oss.qualcomm.com

---
Vinayak Katoch (4):
      dt-bindings: misc: qcom,fastrpc: add iommu-ranges support for context bank
      misc: fastrpc: handle multi-cell reg in context bank probe
      misc: fastrpc: add extended context bank support
      misc: fastrpc: add UAPI flags for extended IOVA mapping

 .../devicetree/bindings/misc/qcom,fastrpc.yaml     |   6 +-
 drivers/misc/fastrpc.c                             | 132 +++++++++++++++++----
 include/uapi/misc/fastrpc.h                        |   7 ++
 3 files changed, 123 insertions(+), 22 deletions(-)
---
base-commit: 5c4d4169604b335c38bbc79bc1fc03042981fc6f
change-id: 20260826-extended-mapping-9b08b0c3108d
prerequisite-change-id: 20260609-dup-sessions-ea2acaac1994:v5
prerequisite-patch-id: 425dc9414848bbc3f2a053d067195d849898e2ae
prerequisite-patch-id: 4fea14b47d11a5a3e18065d8cf3a461841ee2b86
prerequisite-patch-id: da0a3d55397a522ea4b77769e387df9faea8e024

Best regards,
-- 
Vinayak Katoch <vinayak.katoch@oss.qualcomm.com>

[PATCH v2 1/4] dt-bindings: misc: qcom,fastrpc: add iommu-ranges support for context bank

[Vinayak Katoch]

The driver uses the presence of iommu-ranges on a context bank node to
identify it as dedicated for extended IOVA mapping. iommu-ranges lists
the IOVA ranges the IOMMU allocator may use for that device; any range
not listed is left unused.

Add iommu-ranges to the compute-cb subnode properties so the DT
validator accepts it on context bank nodes.

Relax #address-cells to enum: [1, 2] and #size-cells to enum: [0, 2] to
allow platforms that require 64-bit values in iommu-ranges to pass
binding validation.

Signed-off-by: Vinayak Katoch <vinayak.katoch@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
index e945c8ba75e3..f4ca9a767255 100644
--- a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
+++ b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
@@ -73,10 +73,10 @@ properties:
     $ref: /schemas/types.yaml#/definitions/uint32-array
 
   "#address-cells":
-    const: 1
+    enum: [1, 2]
 
   "#size-cells":
-    const: 0
+    enum: [0, 2]
 
 patternProperties:
   "(compute-)?cb@[0-9]*$":
@@ -98,6 +98,8 @@ patternProperties:
         minItems: 1
         maxItems: 10
 
+      iommu-ranges: true
+
       qcom,nsessions:
         $ref: /schemas/types.yaml#/definitions/uint32
         default: 1

-- 
2.34.1

[PATCH v2 2/4] misc: fastrpc: handle multi-cell reg in context bank probe

[Vinayak Katoch]

Platforms that use #address-cells = <2> on the fastrpc node encode the
context bank number in cell[1] of the reg property rather than cell[0].
Reading cell[0] on such platforms yields 0 for every context bank,
causing all sessions to share SID 0 and corrupting IOVA address
construction.

Use of_property_read_u32_index() with of_n_addr_cells() - 1 as the
index so the correct cell is read regardless of the parent address cell
width.

Signed-off-by: Vinayak Katoch <vinayak.katoch@oss.qualcomm.com>
---
 drivers/misc/fastrpc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index b29c1fd00de2..5c7bb56cf46d 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -2348,7 +2348,8 @@ static int fastrpc_cb_init(struct platform_device *pdev)
 	if (!cctx)
 		return -EINVAL;
 
-	if (of_property_read_u32(dev->of_node, "reg", &sid))
+	if (of_property_read_u32_index(dev->of_node, "reg",
+				       of_n_addr_cells(dev->of_node) - 1, &sid))
 		dev_info(dev, "FastRPC Session ID not specified in DT\n");
 
 	spin_lock_irqsave(&cctx->lock, flags);

-- 
2.34.1

[PATCH v2 3/4] misc: fastrpc: add extended context bank support

[Vinayak Katoch]

Detect extended context banks by the presence of iommu-ranges on the
context bank node. Register them in a separate ext_cb array so the
mapping layer can direct large allocations into the wider IOVA window.

Signed-off-by: Vinayak Katoch <vinayak.katoch@oss.qualcomm.com>
---
 drivers/misc/fastrpc.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 5c7bb56cf46d..d40cdcd5dec3 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -307,6 +307,8 @@ struct fastrpc_channel_ctx {
 	struct qcom_scm_vmperm vmperms[FASTRPC_MAX_VMIDS];
 	struct rpmsg_device *rpdev;
 	struct fastrpc_session_ctx session[FASTRPC_MAX_SESSIONS];
+	struct fastrpc_session_ctx **ext_cb;
+	int ext_cb_count;
 	spinlock_t lock;
 	struct idr ctx_idr;
 	struct list_head users;
@@ -538,9 +540,13 @@ static int fastrpc_remote_heap_alloc(struct fastrpc_user *fl, struct device *dev
 static void fastrpc_channel_ctx_free(struct kref *ref)
 {
 	struct fastrpc_channel_ctx *cctx;
+	int i;
 
 	cctx = container_of(ref, struct fastrpc_channel_ctx, refcount);
 
+	for (i = 0; i < cctx->ext_cb_count; i++)
+		kfree(cctx->ext_cb[i]);
+	kfree(cctx->ext_cb);
 	idr_destroy(&cctx->ctx_idr);
 	kfree(cctx);
 }
@@ -2343,6 +2349,7 @@ static int fastrpc_cb_init(struct platform_device *pdev)
 	u32 dma_bits;
 	u32 sid = 0;
 	int rc;
+	bool is_extended_cb = false;
 
 	cctx = dev_get_drvdata(dev->parent);
 	if (!cctx)
@@ -2352,6 +2359,43 @@ static int fastrpc_cb_init(struct platform_device *pdev)
 				       of_n_addr_cells(dev->of_node) - 1, &sid))
 		dev_info(dev, "FastRPC Session ID not specified in DT\n");
 
+	if (of_property_present(dev->of_node, "iommu-ranges"))
+		is_extended_cb = true;
+
+	if (is_extended_cb) {
+		struct fastrpc_session_ctx **new_ext;
+
+		sess = kzalloc_obj(*sess);
+		if (!sess)
+			return -ENOMEM;
+
+		rc = dma_set_mask(dev, DMA_BIT_MASK(40));
+		if (rc) {
+			dev_err(dev, "40-bit DMA enable failed\n");
+			kfree(sess);
+			return rc;
+		}
+
+		new_ext = krealloc(cctx->ext_cb,
+				   (cctx->ext_cb_count + 1) * sizeof(*cctx->ext_cb),
+				   GFP_KERNEL);
+		if (!new_ext) {
+			kfree(sess);
+			return -ENOMEM;
+		}
+
+		spin_lock_irqsave(&cctx->lock, flags);
+		cctx->ext_cb = new_ext;
+		sess->valid = true;
+		sess->dev = dev;
+		sess->sid = sid;
+		dev_set_drvdata(dev, sess);
+		cctx->ext_cb[cctx->ext_cb_count++] = sess;
+		spin_unlock_irqrestore(&cctx->lock, flags);
+
+		return 0;
+	}
+
 	spin_lock_irqsave(&cctx->lock, flags);
 	if (cctx->sesscount >= FASTRPC_MAX_SESSIONS) {
 		spin_unlock_irqrestore(&cctx->lock, flags);
@@ -2391,6 +2435,8 @@ static void fastrpc_cb_devices_destroy(struct rpmsg_device *rpdev)
 	spin_lock_irqsave(&cctx->lock, flags);
 	for (i = 0; i < cctx->sesscount; i++)
 		cctx->session[i].valid = false;
+	for (i = 0; i < cctx->ext_cb_count; i++)
+		cctx->ext_cb[i]->valid = false;
 	spin_unlock_irqrestore(&cctx->lock, flags);
 
 	for_each_available_child_of_node(rdev->of_node, np) {

-- 
2.34.1

[PATCH v2 4/4] misc: fastrpc: add UAPI flags for extended IOVA mapping

[Vinayak Katoch]

Userspace has no way to request that a buffer be mapped through the
extended context bank, so large buffers cannot be placed in the wider
IOVA window even when one is available.

Add two UAPI flags:

  FASTRPC_MAP_FD_EXTENDED         - map immediately via the extended CB
  FASTRPC_MAP_FD_DELAYED_EXTENDED - map on demand via the extended CB

When either flag is set, fastrpc_map_attach() iterates cctx->ext_cb[]
and retries on -ENOMEM, falling over to the next extended CB when one
exhausts its IOVA space. The SID offset passed to the DSP must reflect
the actual CB used, so fastrpc_compute_dma_addr() takes an explicit
session rather than always using fl->sctx — without this the DSP would
fault on access.

Store the mapping flags in struct fastrpc_map. fastrpc_map_create()
validates the cached entry's flags against the request; a mismatched
entry is dropped and a fresh attachment is made to the correct CB type,
preventing a cached regular-CB map from being returned for an
extended-CB request.

All existing call sites pass flags=0 and are unaffected.

Signed-off-by: Vinayak Katoch <vinayak.katoch@oss.qualcomm.com>
---
 drivers/misc/fastrpc.c      | 83 ++++++++++++++++++++++++++++++++++-----------
 include/uapi/misc/fastrpc.h |  7 ++++
 2 files changed, 71 insertions(+), 19 deletions(-)

diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index d40cdcd5dec3..4ba07a5b28bb 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -81,6 +81,11 @@
 #define FASTRPC_MAX_DSP_ATTRIBUTES (256)
 #define FASTRPC_MAX_DSP_ATTRIBUTES_LEN (sizeof(u32) * FASTRPC_MAX_DSP_ATTRIBUTES)
 
+/* Check if the given flag is used for extended UDMA mapping */
+#define IS_EXTENDED_MAP_FLAG(flag) \
+	((flag) == FASTRPC_MAP_FD_EXTENDED || \
+	 (flag) == FASTRPC_MAP_FD_DELAYED_EXTENDED)
+
 /* Retrives number of input buffers from the scalars parameter */
 #define REMOTE_SCALARS_INBUFS(sc)	(((sc) >> 16) & 0x0ff)
 
@@ -252,6 +257,7 @@ struct fastrpc_map {
 	u64 len;
 	u64 raddr;
 	u32 attr;
+	u32 flags;
 	struct kref refcount;
 };
 
@@ -398,7 +404,7 @@ static void fastrpc_free_map(struct kref *ref)
 			err = qcom_scm_assign_mem(map->dma_addr, map->len,
 				&src_perms, &perm, 1);
 			if (err) {
-				dev_err(map->fl->sctx->dev,
+				dev_err(map->attach->dev,
 					"Failed to assign memory dma_addr %pad size 0x%llx err %d\n",
 					&map->dma_addr, map->len, err);
 				return;
@@ -882,16 +888,19 @@ static const struct dma_buf_ops fastrpc_dma_buf_ops = {
 	.release = fastrpc_release,
 };
 
-static dma_addr_t fastrpc_compute_dma_addr(struct fastrpc_user *fl, dma_addr_t sg_dma_addr)
+static dma_addr_t fastrpc_compute_dma_addr(struct fastrpc_user *fl, dma_addr_t sg_dma_addr,
+					   struct fastrpc_session_ctx *sess)
 {
-	return sg_dma_addr + fastrpc_sid_offset(fl->cctx, fl->sctx);
+	return sg_dma_addr + fastrpc_sid_offset(fl->cctx, sess);
 }
 
-static int fastrpc_map_attach(struct fastrpc_user *fl, int fd,
-			      u64 len, u32 attr, struct fastrpc_map **ppmap)
+static int fastrpc_map_attach_to_dev(struct fastrpc_user *fl, int fd,
+				     u64 len, u32 attr, u32 flags,
+				     struct fastrpc_session_ctx *sess,
+				     struct fastrpc_map **ppmap)
 {
-	struct fastrpc_session_ctx *sess = fl->sctx;
 	struct fastrpc_map *map = NULL;
+	struct device *dev = sess->dev;
 	struct sg_table *table;
 	struct scatterlist *sgl = NULL;
 	int err = 0, sgl_index = 0;
@@ -911,9 +920,9 @@ static int fastrpc_map_attach(struct fastrpc_user *fl, int fd,
 		goto get_err;
 	}
 
-	map->attach = dma_buf_attach(map->buf, sess->dev);
+	map->attach = dma_buf_attach(map->buf, dev);
 	if (IS_ERR(map->attach)) {
-		dev_err(sess->dev, "Failed to attach dmabuf\n");
+		dev_err(dev, "Failed to attach dmabuf\n");
 		err = PTR_ERR(map->attach);
 		goto attach_err;
 	}
@@ -928,18 +937,20 @@ static int fastrpc_map_attach(struct fastrpc_user *fl, int fd,
 	if (attr & FASTRPC_ATTR_SECUREMAP)
 		map->dma_addr = sg_phys(map->table->sgl);
 	else
-		map->dma_addr = fastrpc_compute_dma_addr(fl, sg_dma_address(map->table->sgl));
+		map->dma_addr = fastrpc_compute_dma_addr(fl, sg_dma_address(map->table->sgl), sess);
 	for_each_sg(map->table->sgl, sgl, map->table->nents,
 		sgl_index)
 		map->size += sg_dma_len(sgl);
+
 	if (len > map->size) {
-		dev_dbg(sess->dev, "Bad size passed len 0x%llx map size 0x%llx\n",
+		dev_dbg(dev, "Bad size passed len 0x%llx map size 0x%llx\n",
 				len, map->size);
 		err = -EINVAL;
 		goto get_err;
 	}
 	map->va = sg_virt(map->table->sgl);
 	map->len = len;
+	map->flags = flags;
 
 	if (attr & FASTRPC_ATTR_SECUREMAP) {
 		/*
@@ -956,7 +967,7 @@ static int fastrpc_map_attach(struct fastrpc_user *fl, int fd,
 		map->attr = attr;
 		err = qcom_scm_assign_mem(map->dma_addr, (u64)map->len, &src_perms, dst_perms, 2);
 		if (err) {
-			dev_err(sess->dev,
+			dev_err(dev,
 				"Failed to assign memory with dma_addr %pad size 0x%llx err %d\n",
 				&map->dma_addr, map->len, err);
 			goto get_err;
@@ -979,13 +990,47 @@ static int fastrpc_map_attach(struct fastrpc_user *fl, int fd,
 	return err;
 }
 
+static int fastrpc_map_attach(struct fastrpc_user *fl, int fd,
+			      u64 len, u32 attr, u32 flags, struct fastrpc_map **ppmap)
+{
+	if (IS_EXTENDED_MAP_FLAG(flags)) {
+		struct fastrpc_session_ctx **ext_cb;
+		int i, count, err = -ENODEV;
+		unsigned long lock_flags;
+
+		spin_lock_irqsave(&fl->cctx->lock, lock_flags);
+		count = fl->cctx->ext_cb_count;
+		ext_cb = fl->cctx->ext_cb;
+		spin_unlock_irqrestore(&fl->cctx->lock, lock_flags);
+
+		if (!count) {
+			dev_err(fl->sctx->dev, "no extended context bank found\n");
+			return -ENODEV;
+		}
+
+		for (i = 0; i < count; i++) {
+			err = fastrpc_map_attach_to_dev(fl, fd, len, attr, flags,
+							ext_cb[i], ppmap);
+			if (err != -ENOMEM)
+				break;
+		}
+		return err;
+	}
+
+	return fastrpc_map_attach_to_dev(fl, fd, len, attr, flags, fl->sctx, ppmap);
+}
+
 static int fastrpc_map_create(struct fastrpc_user *fl, int fd,
-			      u64 len, u32 attr, struct fastrpc_map **ppmap)
+			      u64 len, u32 attr, u32 flags, struct fastrpc_map **ppmap)
 {
-	if (!fastrpc_map_lookup(fl, fd, ppmap, true))
-		return 0;
+	if (!fastrpc_map_lookup(fl, fd, ppmap, true)) {
+		if ((*ppmap)->flags == flags)
+			return 0;
+		fastrpc_map_put(*ppmap);
+		*ppmap = NULL;
+	}
 
-	return fastrpc_map_attach(fl, fd, len, attr, ppmap);
+	return fastrpc_map_attach(fl, fd, len, attr, flags, ppmap);
 }
 
 /*
@@ -1063,10 +1108,10 @@ static int fastrpc_create_maps(struct fastrpc_invoke_ctx *ctx)
 
 		if (i < ctx->nbufs)
 			err = fastrpc_map_create(ctx->fl, ctx->args[i].fd,
-				 ctx->args[i].length, ctx->args[i].attr, &ctx->maps[i]);
+				 ctx->args[i].length, ctx->args[i].attr, 0, &ctx->maps[i]);
 		else
 			err = fastrpc_map_attach(ctx->fl, ctx->args[i].fd,
-				 ctx->args[i].length, ctx->args[i].attr, &ctx->maps[i]);
+				 ctx->args[i].length, ctx->args[i].attr, 0, &ctx->maps[i]);
 		if (err) {
 			dev_err(dev, "Error Creating map %d\n", err);
 			return -EINVAL;
@@ -1615,7 +1660,7 @@ static int fastrpc_init_create_process(struct fastrpc_user *fl,
 	fl->pd = USER_PD;
 
 	if (init.filelen && init.filefd) {
-		err = fastrpc_map_create(fl, init.filefd, init.filelen, 0, &map);
+		err = fastrpc_map_create(fl, init.filefd, init.filelen, 0, 0, &map);
 		if (err)
 			goto err;
 	}
@@ -2221,7 +2266,7 @@ static int fastrpc_req_mem_map(struct fastrpc_user *fl, char __user *argp)
 		return -EFAULT;
 
 	/* create SMMU mapping */
-	err = fastrpc_map_create(fl, req.fd, req.length, 0, &map);
+	err = fastrpc_map_create(fl, req.fd, req.length, 0, req.flags, &map);
 	if (err) {
 		dev_err(dev, "failed to map buffer, fd = %d\n", req.fd);
 		return err;
diff --git a/include/uapi/misc/fastrpc.h b/include/uapi/misc/fastrpc.h
index ba1ea5ed426c..b39c0e197a45 100644
--- a/include/uapi/misc/fastrpc.h
+++ b/include/uapi/misc/fastrpc.h
@@ -36,6 +36,11 @@
  * cache maintenance for the buffer.
  * @FASTRPC_MAP_FD_NOMAP: This flag is used to skip CPU mapping,
  * otherwise behaves similar to FASTRPC_MAP_FD_DELAYED flag.
+ * @FASTRPC_MAP_FD_EXTENDED: Map buffer in extended SMMU IOVA space (16GB - 1TB)
+ * and DSP VA space (4GB - 512GB). Can be accessed only through uDMA.
+ * @FASTRPC_MAP_FD_DELAYED_EXTENDED: Map buffer in extended SMMU IOVA space
+ * (16GB - 1TB) but skip DSP mapping. DSP mapping will be done later by
+ * the user. Can be accessed only through uDMA.
  * @FASTRPC_MAP_MAX: max count for flags
  *
  */
@@ -45,6 +50,8 @@ enum fastrpc_map_flags {
 	FASTRPC_MAP_FD = 2,
 	FASTRPC_MAP_FD_DELAYED,
 	FASTRPC_MAP_FD_NOMAP = 16,
+	FASTRPC_MAP_FD_EXTENDED,
+	FASTRPC_MAP_FD_DELAYED_EXTENDED,
 	FASTRPC_MAP_MAX,
 };
 

-- 
2.34.1

Re: [PATCH v2 1/4] dt-bindings: misc: qcom,fastrpc: add iommu-ranges support for context bank

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] dt-bindings: namespace violation and missing type for iommu-ranges
--

commit dcdf3e61cd19c2e633ae438160d6dad2d5a26363
Author: Vinayak Katoch <vinayak.katoch@oss.qualcomm.com>

dt-bindings: misc: qcom,fastrpc: add iommu-ranges support for context bank

This commit adds support for the iommu-ranges property to the compute-cb
subnode in the qcom,fastrpc device tree binding. It allows the context bank
nodes to specify IOVA ranges for the IOMMU allocator, and relaxes the
address and size cells properties to accommodate 64-bit values.

> diff --git a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
> index e945c8ba75e30..f4ca9a7672556 100644
> --- a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
> +++ b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
[ ... ]
> @@ -98,6 +98,8 @@ patternProperties:
>          minItems: 1
>          maxItems: 10
>  
> +      iommu-ranges: true
> +

[Severity: Low]
Does this property need a vendor prefix since it appears to be specific to
this driver rather than a standard device tree property? Device tree namespace
conventions generally expect a vendor prefix for non-standard properties, such
as qcom,iommu-ranges.

Additionally, should this property include a structural or type constraint?
Defining it simply as true without a type reference, such as
$ref: /schemas/types.yaml#/definitions/uint32-matrix, seems to bypass schema
validation. This could potentially allow malformed data to silently pass
the dt_binding_check validation.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261007-extended-mapping-v2-0-5dca3aa2c2d3@oss.qualcomm.com?part=1

Re: [PATCH v2 4/4] misc: fastrpc: add UAPI flags for extended IOVA mapping

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] misc: fastrpc: unbounded memory and DMA mapping leak via mismatched map flags
- [High] misc: fastrpc: UAF of ext_cb array due to race with krealloc during probe
- [High] fastrpc: refcount underflow via retained 0-refcount map on SCM error
- [High] misc: fastrpc: memory leak and invalid hyp unmap on secure mapping failure
- [Medium] misc: fastrpc: extended context bank mappings are bypassed and defeated during DSP invocation
--

commit d890ee0bf9f03c55cbc6da25fffce9e57f51d755
Author: Vinayak Katoch <vinayak.katoch@oss.qualcomm.com>
Subject: misc: fastrpc: add UAPI flags for extended IOVA mapping

This commit introduces new UAPI flags, FASTRPC_MAP_FD_EXTENDED and
FASTRPC_MAP_FD_DELAYED_EXTENDED, allowing userspace to map large buffers via
the extended SMMU context bank. It adds a flags parameter to map creation and
validation routines to handle the requested context bank type.

> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> index d40cdcd5dec30..4ba07a5b28bb4 100644
> --- a/drivers/misc/fastrpc.c
> +++ b/drivers/misc/fastrpc.c

[ ... ]

> @@ -398,7 +404,7 @@ static void fastrpc_free_map(struct kref *ref)
>  			err = qcom_scm_assign_mem(map->dma_addr, map->len,
>  				&src_perms, &perm, 1);
>  			if (err) {
> -				dev_err(map->fl->sctx->dev,
> +				dev_err(map->attach->dev,
>  					"Failed to assign memory dma_addr %pad size 0x%llx err %d\n",
>  					&map->dma_addr, map->len, err);
>  				return;

[Severity: High]
This problem wasn't introduced by this patch, but if qcom_scm_assign_mem()
fails, the function returns early without unlinking the map from the list
via list_del().

This leaves the map object in the fl->maps list with a 0-refcount.

During session teardown, fastrpc_user_free() calls fastrpc_map_put() on all
entries in fl->maps:

drivers/misc/fastrpc.c:fastrpc_user_free() {
	list_for_each_entry_safe(map, m, &fl->maps, node)
		fastrpc_map_put(map);
}

Does the early return here strand the map object in the active list and
lead to a double-put and refcount underflow?

[ ... ]

> @@ -956,7 +967,7 @@ static int fastrpc_map_attach(struct fastrpc_user *fl, int fd,
>  		map->attr = attr;
>  		err = qcom_scm_assign_mem(map->dma_addr, (u64)map->len, &src_perms, dst_perms, 2);
>  		if (err) {
> -			dev_err(sess->dev,
> +			dev_err(dev,
>  				"Failed to assign memory with dma_addr %pad size 0x%llx err %d\n",
>  				&map->dma_addr, map->len, err);
>  			goto get_err;

[Severity: High]
This problem wasn't introduced by this patch, but the map->attr field is set
to the requested attributes before calling qcom_scm_assign_mem().

If this hypervisor call fails, the code jumps to get_err and calls
fastrpc_map_put().

Because map->attr is already set to FASTRPC_ATTR_SECUREMAP, fastrpc_free_map()
will attempt to transition the memory back to HLOS using a source permission
mask that includes the secure VM:

drivers/misc/fastrpc.c:fastrpc_free_map() {
	if (map->attr & FASTRPC_ATTR_SECUREMAP) {
		...
		err = qcom_scm_assign_mem(map->dma_addr, map->len,
			&src_perms, &perm, 1);
		if (err) {
			dev_err(map->attach->dev, ...);
			return;
		}
	}
}

Since the initial transition never succeeded, the memory does not belong to
the secure VM and this second qcom_scm_assign_mem() call will fail.

Does setting map->attr before a successful hypervisor call lead to an invalid
unmap attempt that returns early, leaking the DMA structures and map object?

>  		}
> @@ -979,13 +990,47 @@ static int fastrpc_map_attach(struct fastrpc_user *fl, int fd,
>  	return err;
>  }
>  
> +static int fastrpc_map_attach(struct fastrpc_user *fl, int fd,
> +			      u64 len, u32 attr, u32 flags, struct fastrpc_map **ppmap)
> +{
> +	if (IS_EXTENDED_MAP_FLAG(flags)) {
> +		struct fastrpc_session_ctx **ext_cb;
> +		int i, count, err = -ENODEV;
> +		unsigned long lock_flags;
> +
> +		spin_lock_irqsave(&fl->cctx->lock, lock_flags);
> +		count = fl->cctx->ext_cb_count;
> +		ext_cb = fl->cctx->ext_cb;
> +		spin_unlock_irqrestore(&fl->cctx->lock, lock_flags);
> +
> +		if (!count) {
> +			dev_err(fl->sctx->dev, "no extended context bank found\n");
> +			return -ENODEV;
> +		}
> +
> +		for (i = 0; i < count; i++) {
> +			err = fastrpc_map_attach_to_dev(fl, fd, len, attr, flags,
> +							ext_cb[i], ppmap);

[Severity: High]
The ext_cb array pointer is cached under the lock but dereferenced outside
of it in a loop.

Because fastrpc_rpmsg_probe() registers the character device via
fastrpc_device_register() before calling fastrpc_cb_devices_create(),
userspace can concurrently issue a FASTRPC_IOCTL_MEM_MAP ioctl with an
extended map flag.

Concurrently, fastrpc_cb_init() resizes the array without RCU or
synchronization against readers:

drivers/misc/fastrpc.c:fastrpc_cb_init() {
	new_ext = krealloc(cctx->ext_cb,
			   (cctx->ext_cb_count + 1) * sizeof(*cctx->ext_cb),
			   GFP_KERNEL);
	...
	spin_lock_irqsave(&cctx->lock, flags);
	cctx->ext_cb = new_ext;
	...
}

If the memory is moved by krealloc(), it frees the old block.

Can this lockless traversal of ext_cb race with krealloc() during device
probe and cause a use-after-free?

> +			if (err != -ENOMEM)
> +				break;
> +		}
> +		return err;
> +	}
> +
> +	return fastrpc_map_attach_to_dev(fl, fd, len, attr, flags, fl->sctx, ppmap);
> +}
> +
>  static int fastrpc_map_create(struct fastrpc_user *fl, int fd,
> -			      u64 len, u32 attr, struct fastrpc_map **ppmap)
> +			      u64 len, u32 attr, u32 flags, struct fastrpc_map **ppmap)
>  {
> -	if (!fastrpc_map_lookup(fl, fd, ppmap, true))
> -		return 0;
> +	if (!fastrpc_map_lookup(fl, fd, ppmap, true)) {
> +		if ((*ppmap)->flags == flags)
> +			return 0;
> +		fastrpc_map_put(*ppmap);
> +		*ppmap = NULL;
> +	}

[Severity: High]
If a map with mismatched flags is found, its reference is dropped but it is
not removed from the list.

Since fastrpc_map_lookup() iterates from the head and always returns the
first matching fd:

drivers/misc/fastrpc.c:fastrpc_map_lookup() {
	list_for_each_entry(map, &fl->maps, node) {
		if (map->fd != fd || map->buf != buf)
			continue;
		...
		*ppmap = map;
		ret = 0;
		break;
	}
}

Any subsequent mapping request for the same fd with different flags will
repeatedly hit this old map, drop the newly acquired reference, and fall
through to fastrpc_map_attach() where it appends a new map to the list.

Could an unprivileged user exhaust kernel memory, DMA attachments, and SMMU
IOVA space by alternating flags in repeated FASTRPC_IOCTL_MEM_MAP calls?

>  
> -	return fastrpc_map_attach(fl, fd, len, attr, ppmap);
> +	return fastrpc_map_attach(fl, fd, len, attr, flags, ppmap);
>  }
>  
>  /*
> @@ -1063,10 +1108,10 @@ static int fastrpc_create_maps(struct fastrpc_invoke_ctx *ctx)
>  
>  		if (i < ctx->nbufs)
>  			err = fastrpc_map_create(ctx->fl, ctx->args[i].fd,
> -				 ctx->args[i].length, ctx->args[i].attr, &ctx->maps[i]);
> +				 ctx->args[i].length, ctx->args[i].attr, 0, &ctx->maps[i]);

[Severity: Medium]
When processing argument buffers during a DSP invocation, fastrpc_map_create()
is called with a hardcoded flags parameter of 0.

If the user previously mapped a buffer to the extended CB, fastrpc_map_create()
will find it but reject it because the cached flags do not match 0.

The invocation path will then discard the extended map and create a fresh
standard map attached to the regular SMMU CB, completely bypassing the wider
IOVA window the user requested.

Does hardcoding flags to 0 here cause valid extended-CB maps previously
requested by the user to be defeated during DSP invocation?

>  		else
>  			err = fastrpc_map_attach(ctx->fl, ctx->args[i].fd,
> -				 ctx->args[i].length, ctx->args[i].attr, &ctx->maps[i]);
> +				 ctx->args[i].length, ctx->args[i].attr, 0, &ctx->maps[i]);
>  		if (err) {
>  			dev_err(dev, "Error Creating map %d\n", err);
>  			return -EINVAL;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261007-extended-mapping-v2-0-5dca3aa2c2d3@oss.qualcomm.com?part=4

Re: [PATCH v2 2/4] misc: fastrpc: handle multi-cell reg in context bank probe

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] misc: fastrpc: out-of-bounds read due to index underflow bypassing bounds check
--

commit a9dd81ce5afe0b6b73eb7394627f61e8448d9435
Author: Vinayak Katoch <vinayak.katoch@oss.qualcomm.com>

misc: fastrpc: handle multi-cell reg in context bank probe

Platforms that use #address-cells = <2> on the fastrpc node encode the
context bank number in cell[1] of the reg property rather than cell[0].
Reading cell[0] on such platforms yields 0 for every context bank,
causing all sessions to share SID 0 and corrupting IOVA address
construction.

> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> index b29c1fd00de28..5c7bb56cf46d0 100644
> --- a/drivers/misc/fastrpc.c
> +++ b/drivers/misc/fastrpc.c
> @@ -2348,7 +2348,8 @@ static int fastrpc_cb_init(struct platform_device *pdev)
>  	if (!cctx)
>  		return -EINVAL;
>  
> -	if (of_property_read_u32(dev->of_node, "reg", &sid))
> +	if (of_property_read_u32_index(dev->of_node, "reg",
> +				       of_n_addr_cells(dev->of_node) - 1, &sid))

[Severity: High]
Can this code underflow the index if a malformed device tree explicitly sets
#address-cells = <0> on the parent node?

If of_n_addr_cells() evaluates to 0, the unchecked subtraction introduces an
underflow. Because the index argument to of_property_read_u32_index() is a
u32, this implicitly casts -1 to 0xFFFFFFFF.

This propagates down to bypass bounds checking in the property reader:

drivers/of/property.c:of_property_read_u32_index() {
    ...
	const u32 *val = of_find_property_value_of_size(np, propname,
					((index + 1) * sizeof(*out_value)),
					0,
					NULL);
    ...
}

The index + 1 expression wraps to 0 here, reducing the min size to 0 and
defeating the internal length check inside of_find_property_value_of_size().

This subsequently triggers an out-of-bounds read when extracting the value:

drivers/of/property.c:of_property_read_u32_index() {
    ...
	*out_value = be32_to_cpup(((__be32 *)val) + index);
    ...
}

This pointer arithmetic adds 0xFFFFFFFF to the base property address, resulting
in an immediate out-of-bounds memory dereference traversing approximately 17 GB
past the base pointer.

>  		dev_info(dev, "FastRPC Session ID not specified in DT\n");
>  
>  	spin_lock_irqsave(&cctx->lock, flags);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261007-extended-mapping-v2-0-5dca3aa2c2d3@oss.qualcomm.com?part=2

Re: [PATCH v2 3/4] misc: fastrpc: add extended context bank support

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [High] misc: fastrpc: Use-After-Free of ext_cb array due to concurrent krealloc during probe
- [High] misc: fastrpc: memory leak of dynamically allocated ext_cb array elements on probe error path
- [High] misc: fastrpc: premature device registration allows UAF on probe failure
- [High] of: double-free of device node in fastrpc_cb_devices_destroy
- [Medium] misc: fastrpc: memory leak of ext_cb on probe error path
- [Medium] misc: fastrpc: memory leak of ext_cb array on probe error path
--

commit 670e94cdc2cb15ca5f0de40ab9985878a7a72c7b
Author: Vinayak Katoch <vinayak.katoch@oss.qualcomm.com>

    misc: fastrpc: add extended context bank support
    
This commit detects extended context banks by checking for the iommu-ranges
property on the context bank node. It registers them in a separate ext_cb
array, allowing the mapping layer to direct large allocations into the wider
IOVA window.

> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> index 5c7bb56cf46d0..d40cdcd5dec30 100644
> --- a/drivers/misc/fastrpc.c
> +++ b/drivers/misc/fastrpc.c
[ ... ]
> @@ -2352,6 +2359,43 @@ static int fastrpc_cb_init(struct platform_device *pdev)
>  				       of_n_addr_cells(dev->of_node) - 1, &sid))
>  		dev_info(dev, "FastRPC Session ID not specified in DT\n");
>  
> +	if (of_property_present(dev->of_node, "iommu-ranges"))
> +		is_extended_cb = true;
> +
> +	if (is_extended_cb) {
> +		struct fastrpc_session_ctx **new_ext;
> +
> +		sess = kzalloc_obj(*sess);
> +		if (!sess)
> +			return -ENOMEM;

[Severity: High]
Can this new failure path trigger a use-after-free regression due to premature
device registration?

If this allocation fails, fastrpc_cb_init() returns an error, which propagates
up to fastrpc_rpmsg_probe(). In fastrpc_rpmsg_probe(), the misc device is
registered and exposed to userspace before fastrpc_cb_devices_create() is
called. 

If userspace opens the device concurrently during probe, it obtains an active
file descriptor. When the error path in fastrpc_rpmsg_probe() unconditionally
frees the channel context (data), any subsequent ioctl() or close() by userspace
will dereference the freed pointer.

> +
> +		rc = dma_set_mask(dev, DMA_BIT_MASK(40));
> +		if (rc) {
> +			dev_err(dev, "40-bit DMA enable failed\n");
> +			kfree(sess);
> +			return rc;
> +		}
> +
> +		new_ext = krealloc(cctx->ext_cb,
> +				   (cctx->ext_cb_count + 1) * sizeof(*cctx->ext_cb),
> +				   GFP_KERNEL);

[Severity: High]
Does this code cause a use-after-free regression of the ext_cb array pointer?

krealloc() is called without holding cctx->lock. If krealloc() allocates a new
block, it frees the old cctx->ext_cb pointer. The cctx->ext_cb pointer is only
updated to new_ext later inside the spinlock. 

During this window, cctx->ext_cb points to freed memory, and concurrent
readers may fetch the freed pointer if they race with the probe thread.

[Severity: High]
Does this code also introduce a regression that leaks the dynamically allocated
ext_cb array elements on the probe error path?

If a failure occurs during the context bank initialization loop
(e.g., if krealloc() fails for a second child node after the first succeeded),
the error propagates to fastrpc_rpmsg_probe(). 

The error path in fastrpc_rpmsg_probe() directly executes kfree(data), bypassing
the proper teardown sequence in fastrpc_channel_ctx_free(). Because
fastrpc_channel_ctx_free() is circumvented, the sess objects allocated by this
patch are permanently leaked.

[Severity: Medium]
Does this code also leak the ext_cb array itself on the probe error path?

Similar to the array elements, because the probe error path executes kfree(data)
directly and skips calling fastrpc_channel_ctx_free(), the new_ext block
allocated here is never freed and permanently leaked.

> +		if (!new_ext) {
> +			kfree(sess);
> +			return -ENOMEM;
> +		}
> +
> +		spin_lock_irqsave(&cctx->lock, flags);
> +		cctx->ext_cb = new_ext;
> +		sess->valid = true;
> +		sess->dev = dev;
> +		sess->sid = sid;
> +		dev_set_drvdata(dev, sess);
> +		cctx->ext_cb[cctx->ext_cb_count++] = sess;
> +		spin_unlock_irqrestore(&cctx->lock, flags);
> +
> +		return 0;
> +	}
> +
[ ... ]
> @@ -2391,6 +2435,8 @@ static void fastrpc_cb_devices_destroy(struct rpmsg_device *rpdev)
>  	spin_lock_irqsave(&cctx->lock, flags);
>  	for (i = 0; i < cctx->sesscount; i++)
>  		cctx->session[i].valid = false;
> +	for (i = 0; i < cctx->ext_cb_count; i++)
> +		cctx->ext_cb[i]->valid = false;
>  	spin_unlock_irqrestore(&cctx->lock, flags);
>  
>  	for_each_available_child_of_node(rdev->of_node, np) {
>  		if (!of_device_is_compatible(np, "qcom,fastrpc-compute-cb")) {
>  			of_node_put(np);

[Severity: High]
Does this loop cause a double-free regression of the device node?

The for_each_available_child_of_node() macro automatically drops the reference
to the previous node upon advancing in the loop. Explicitly calling
of_node_put(np) inside the loop body (both before continue and at the end of
the iteration) violates OF iterator semantics and results in a double-free.

Since this patch introduces new allocations in fastrpc_cb_init() that can
fail, it exposes this buggy cleanup path when fastrpc_cb_devices_destroy()
is triggered on error.

>  			continue;
>  		}
>  
>  		pdev = of_find_device_by_node(np);
>  		of_node_put(np);
>  		if (pdev)
>  			of_platform_device_destroy(&pdev->dev, NULL);
>  	}
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261007-extended-mapping-v2-0-5dca3aa2c2d3@oss.qualcomm.com?part=3

Re: [PATCH v2 1/4] dt-bindings: misc: qcom,fastrpc: add iommu-ranges support for context bank

[Krzysztof Kozlowski]

On Wed, Oct 07, 2026 at 05:07:48PM +0530, Vinayak Katoch wrote:
> The driver uses the presence of iommu-ranges on a context bank node to
> identify it as dedicated for extended IOVA mapping. iommu-ranges lists
> the IOVA ranges the IOMMU allocator may use for that device; any range
> not listed is left unused.
> 
> Add iommu-ranges to the compute-cb subnode properties so the DT
> validator accepts it on context bank nodes.

Example looks incomplete now. Please add a new example showing complete
picture of this device with all new properties.

> 
> Relax #address-cells to enum: [1, 2] and #size-cells to enum: [0, 2] to
> allow platforms that require 64-bit values in iommu-ranges to pass
> binding validation.

Which platforms are these?

> 
> Signed-off-by: Vinayak Katoch <vinayak.katoch@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 

Looks like this needs some dependencies.

Best regards,
Krzysztof