kernel/linux.git/drivers/misc/fastrpc.c, branch v6.19.12

misc: fastrpc: check qcom_scm_assign_mem() return in rpmsg_probe

2026-04-11T12:29:55+00:00

commit 6a502776f4a4f80fb839b22f12aeaf0267fca344 upstream. In the SDSP probe path, qcom_scm_assign_mem() is used to assign the reserved memory to the configured VMIDs, but its return value was not checked. Fail the probe if the SCM call fails to avoid continuing with an unexpected/incorrect memory permission configuration. This issue was found by an in-house analysis workflow that extracts AST-based information and runs static checks, with LLM assistance for triage, and was confirmed by manual code review. No hardware testing was performed. Fixes: c3c0363bc72d4 ("misc: fastrpc: support complete DMA pool access to the DSP") Cc: stable@vger.kernel.org # 6.11-rc1 Signed-off-by: Xingjing Deng Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20260131065539.2124047-1-xjdeng@buaa.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman

misc: fastrpc: possible double-free of cctx->remote_heap

2026-04-11T12:29:55+00:00

commit ba2c83167b215da30fa2aae56b140198cf8d8408 upstream. fastrpc_init_create_static_process() may free cctx->remote_heap on the err_map path but does not clear the pointer. Later, fastrpc_rpmsg_remove() frees cctx->remote_heap again if it is non-NULL, which can lead to a double-free if the INIT_CREATE_STATIC ioctl hits the error path and the rpmsg device is subsequently removed/unbound. Clear cctx->remote_heap after freeing it in the error path to prevent the later cleanup from freeing it again. This issue was found by an in-house analysis workflow that extracts AST-based information and runs static checks, with LLM assistance for triage, and was confirmed by manual code review. No hardware testing was performed. Fixes: 0871561055e66 ("misc: fastrpc: Add support for audiopd") Cc: stable@vger.kernel.org # 6.2+ Signed-off-by: Xingjing Deng Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20260129234140.410983-1-xjdeng@buaa.edu.cn Signed-off-by: Greg Kroah-Hartman

misc: fastrpc: Fix dma_buf object leak in fastrpc_map_lookup

2025-10-22T06:03:24+00:00

In fastrpc_map_lookup, dma_buf_get is called to obtain a reference to the dma_buf for comparison purposes. However, this reference is never released when the function returns, leading to a dma_buf memory leak. Fix this by adding dma_buf_put before returning from the function, ensuring that the temporarily acquired reference is properly released regardless of whether a matching map is found. Fixes: 9031626ade38 ("misc: fastrpc: Fix fastrpc_map_lookup operation") Cc: stable@kernel.org Signed-off-by: Junhao Xie Tested-by: Xilin Wu Rule: add Link: https://lore.kernel.org/stable/48B368FB4C7007A7%2B20251017083906.3259343-1-bigfoot%40radxa.com Link: https://patch.msgid.link/48B368FB4C7007A7+20251017083906.3259343-1-bigfoot@radxa.com Signed-off-by: Greg Kroah-Hartman

Merge tag 'char-misc-6.18-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc

2025-10-07T19:13:26+00:00

Pull char/misc fixes from Greg KH: "Here are some small nvmem and fastrpc fixes that missed the cut-off to get into 6.17-final, due to me being slow in getting them out, my fault, not the maintainers of these subsystems :( Anyway, better late than never. Changes included in here are: - nvmem fix for automatic module loading - fastrpc driver fixes for reported issues All of these have been in linux-next for weeks (4?) with no reported issues" * tag 'char-misc-6.18-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: misc: fastrpc: Skip reference for DMA handles misc: fastrpc: fix possible map leak in fastrpc_put_args misc: fastrpc: Fix fastrpc_map_lookup operation misc: fastrpc: Save actual DMA size in fastrpc_map structure nvmem: layouts: fix automatic module loading

misc: fastrpc: Skip reference for DMA handles

2025-09-12T14:34:10+00:00

If multiple dma handles are passed with same fd over a remote call the kernel driver takes a reference and expects that put for the map will be called as many times to free the map. But DSP only updates the fd one time in the fd list when the DSP refcount goes to zero and hence kernel make put call only once for the fd. This can cause SMMU fault issue as the same fd can be used in future for some other call. Fixes: 35a82b87135d ("misc: fastrpc: Add dma handle implementation") Cc: stable@kernel.org Co-developed-by: Ekansh Gupta Signed-off-by: Ekansh Gupta Signed-off-by: Ling Xu Reviewed-by: Dmitry Baryshkov Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20250912131236.303102-5-srini@kernel.org Signed-off-by: Greg Kroah-Hartman

misc: fastrpc: fix possible map leak in fastrpc_put_args

2025-09-12T14:34:10+00:00

copy_to_user() failure would cause an early return without cleaning up the fdlist, which has been updated by the DSP. This could lead to map leak. Fix this by redirecting to a cleanup path on failure, ensuring that all mapped buffers are properly released before returning. Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method") Cc: stable@kernel.org Co-developed-by: Ekansh Gupta Signed-off-by: Ekansh Gupta Signed-off-by: Ling Xu Reviewed-by: Dmitry Baryshkov Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20250912131236.303102-4-srini@kernel.org Signed-off-by: Greg Kroah-Hartman

misc: fastrpc: Fix fastrpc_map_lookup operation

2025-09-12T14:34:10+00:00

Fastrpc driver creates maps for user allocated fd buffers. Before creating a new map, the map list is checked for any already existing maps using map fd. Checking with just map fd is not sufficient as the user can pass offsetted buffer with less size when the map is created and then a larger size the next time which could result in memory issues. Check for dma_buf object also when looking up for the map. Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method") Cc: stable@kernel.org Co-developed-by: Ekansh Gupta Signed-off-by: Ekansh Gupta Signed-off-by: Ling Xu Reviewed-by: Dmitry Baryshkov Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20250912131236.303102-3-srini@kernel.org Signed-off-by: Greg Kroah-Hartman

misc: fastrpc: Save actual DMA size in fastrpc_map structure

2025-09-12T14:34:10+00:00

For user passed fd buffer, map is created using DMA calls. The map related information is stored in fastrpc_map structure. The actual DMA size is not stored in the structure. Store the actual size of buffer and check it against the user passed size. Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method") Cc: stable@kernel.org Reviewed-by: Dmitry Baryshkov Co-developed-by: Ekansh Gupta Signed-off-by: Ekansh Gupta Signed-off-by: Ling Xu Reviewed-by: Dmitry Baryshkov Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20250912131236.303102-2-srini@kernel.org Signed-off-by: Greg Kroah-Hartman

misc: fastrpc: add support for gdsp remoteproc

2025-09-12T13:48:45+00:00

Some platforms (like lemans) feature one or more GPDSPs (General Purpose DSPs). Similar to other kinds of Hexagon DSPs, they provide a FastRPC implementation, allowing code execution in both signed and unsigned protection domains. Extend the checks to allow domain names starting with "gdsp" (possibly followed by an index). Reviewed-by: Dmitry Baryshkov Reviewed-by: Ekansh Gupta Signed-off-by: Ling Xu Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20250912131302.303199-5-srini@kernel.org Signed-off-by: Greg Kroah-Hartman

misc: fastrpc: Cleanup the domain names

2025-09-12T13:48:45+00:00

Currently the domain ids are added for each instance of domains, this is totally not scalable approach. Clean this mess and create domain ids for only domains not its instances. Co-developed-by: Srinivas Kandagatla Signed-off-by: Srinivas Kandagatla Reviewed-by: Dmitry Baryshkov Reviewed-by: Ekansh Gupta Signed-off-by: Ling Xu Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20250912131302.303199-4-srini@kernel.org Signed-off-by: Greg Kroah-Hartman