Hi,
I would like to report a likely shared-memory reference leak in
drivers/tee/tee_core.c, in tee_ioctl_supp_recv().
The issue is that tee_ioctl_supp_recv() calls params_from_user(), which
acquires references for MEMREF-type parameters via tee_shm_get_from_id(),
but the cleanup path only frees the params array and does not drop the
acquired shm references.
Relevant code in tee_ioctl_supp_recv():
rc = params_from_user(ctx, params, num_params, uarg->params);
if (rc)
goto out;
rc = ctx->teedev->desc->ops->supp_recv(ctx, &func, &num_params, params);
if (rc)
goto out;
...
out:
kfree(params);
return rc;
By contrast, other callers of params_from_user() in tee_core.c do release
MEMREF references on cleanup, for example:
- tee_ioctl_open_session()
- tee_ioctl_invoke()
- tee_ioctl_object_invoke()
The helper comment in param_from_user_memref() also states that the caller
is responsible for calling tee_shm_put() on all resolved pointers.
Reachability / trigger paths:
1. qcomtee backend:
qcomtee registers .supp_recv = qcomtee_supp_recv on a non-privileged
tee device path. qcomtee_supp_recv() rejects any non-meta parameter
after the first one:
for (i = 1; i < *num_params; i++)
if (params[i].attr)
return -EINVAL;
This allows a path where params_from_user() has already acquired a shm
reference for a MEMREF parameter, then qcomtee_supp_recv() returns an
error, and tee_ioctl_supp_recv() exits without tee_shm_put().
2. Partial failure before backend callback:
if params_from_user() successfully resolves an earlier MEMREF parameter
and then fails on a later parameter, tee_ioctl_supp_recv() still goes
to the same cleanup path without dropping already acquired shm refs.
This means the issue is not just a backend-specific quirk: the core ioctl
cleanup path itself is missing tee_shm_put() handling.
Impact:
- leaked shared-memory references
- shared-memory objects may remain pinned and never reach final release
- repeated triggering can cause resource exhaustion / DoS
This does not appear to be a UAF, since refcount_t saturation prevents
wraparound. The impact looks limited to resource leakage and availability.
If useful, I can also prepare a patch.
Thanks,
Qihang
Hello,
I am working on embedded automotive systems repair and investigating
behavior of Samsung eMMC (KLMBG4GEUF) in systems that appear to use OP-TEE
for secure storage.
Real scenario:
- Two identical devices (same hardware)
- One working, one not booting
- Full eMMC dump taken from working device:
- USER
- BOOT1 / BOOT2
- EXT_CSD
- RPMB (reported readable, but content appears empty or not usable)
Tests:
- Writing full dump to another device → no boot
- Swapping eMMC between boards → both fail
- Writing only USER → no change
From observations:
- RPMB appears non-clonable
- Secure storage likely bound to hardware
- Boot seems dependent on this binding
Questions:
1. In OP-TEE, is RPMB always tied to a hardware unique key (HUK)?
2. Is it expected that RPMB content cannot be reused across identical
devices?
3. Does OP-TEE enforce secure storage binding in a way that prevents
cloning?
4. In case of damaged eMMC, is there any supported way to reinitialize
or recover secure storage?
I am not trying to bypass security, but to understand the architectural
limitation in real repair scenarios.
Any clarification would be highly appreciated.
Best regards
From: Sumit Garg <sumit.garg(a)oss.qualcomm.com>
Qcom platforms has the legacy of using non-standard SCM calls
splintered over the various kernel drivers. These SCM calls aren't
compliant with the standard SMC calling conventions which is a
prerequisite to enable migration to the FF-A specifications from Arm.
OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't
support these non-standard SCM calls. And even for newer architectures
using S-EL2 with Hafnium support, QTEE won't be able to support SCM
calls either with FF-A requirements coming in. And with both OP-TEE
and QTEE drivers well integrated in the TEE subsystem, it makes further
sense to reuse the TEE bus client drivers infrastructure.
The added benefit of TEE bus infrastructure is that there is support
for discoverable/enumerable services. With that client drivers don't
have to manually invoke a special SCM call to know the service status.
So enable the generic Peripheral Authentication Service (PAS) provided
by the firmware. It acts as the common layer with different TZ
backends plugged in whether it's an SCM implementation or a proper
TEE bus based PAS service implementation.
The TEE PAS service ABI is designed to be extensible with additional API
as PTA_QCOM_PAS_CAPABILITIES. This allows to accommodate any future
extensions of the PAS service needed while still maintaining backwards
compatibility.
Currently OP-TEE support is being added to provide the backend PAS
service implementation which can be found as part of this PR [1].
This implementation has been tested on Kodiak/RB3Gen2 board with lemans
EVK board being the next target. In addition to that WIN/IPQ targets
planning to use OP-TEE will use this service too. Surely the backwards
compatibility is maintained and tested for SCM backend.
Note that kernel PAS service support while running in EL2 is at parity
among OP-TEE vs QTEE. Especially the media (venus/iris) support depends
on proper IOMMU support being worked out on the PAS client end.
Patch summary:
- Patch #1: adds Kodiak EL2 overlay since boot stack with TF-A/OP-TEE
only allow UEFI and Linux to boot in EL2.
- Patch #2: adds generic PAS service.
- Patch #3: migrates SCM backend to generic PAS service.
- Patch #4: adds TEE/OP-TEE backend for generic PAS service.
- Patch #5-#13: migrates all client drivers to generic PAS service.
- Patch #14: drops legacy PAS SCM exported APIs.
The patch-set is based on v7.1-rc1 tag and can be found in git tree here
[2].
Merge strategy:
It is expected due to APIs dependency, the entire patch-set to go via
the Qcom tree. All other subsystem maintainers, it will be great if I
can get acks for the corresponding subsystem patches.
[1] https://github.com/OP-TEE/optee_os/pull/7721
[2] https://git.kernel.org/pub/scm/linux/kernel/git/sumit.garg/linux.git/log/?h…
---
Changes in v4:
- Incorporate misc. comments on patch #4.
- Picked up an ack for patch #10.
- Clarify in cover letter about state of media support.
Changes in v3:
- Incorporated some style and misc. comments for patch #2, #3 and #4.
- Add QCOM_PAS Kconfig dependency for various subsystems.
- Switch from pseudo TA to proper TA invoke commands.
Changes in v2:
- Fixed kernel doc warnings.
- Polish commit message and comments for patch #2.
- Pass proper PAS ID in set_remote_state API for media firmware drivers.
- Added Maintainer entry and dropped MODULE_AUTHOR.
Mukesh Ojha (1):
arm64: dts: qcom: kodiak: Add EL2 overlay
Sumit Garg (14):
firmware: qcom: Add a generic PAS service
firmware: qcom_scm: Migrate to generic PAS service
firmware: qcom: Add a PAS TEE service
remoteproc: qcom_q6v5_pas: Switch over to generic PAS TZ APIs
remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs
soc: qcom: mdtloader: Switch to generic PAS TZ APIs
remoteproc: qcom_wcnss: Switch to generic PAS TZ APIs
remoteproc: qcom: Select QCOM_PAS generic service
drm/msm: Switch to generic PAS TZ APIs
media: qcom: Switch to generic PAS TZ APIs
net: ipa: Switch to generic PAS TZ APIs
wifi: ath12k: Switch to generic PAS TZ APIs
firmware: qcom_scm: Remove SCM PAS wrappers
MAINTAINERS: Add maintainer entry for Qualcomm PAS TZ service
MAINTAINERS | 9 +
arch/arm64/boot/dts/qcom/Makefile | 2 +
arch/arm64/boot/dts/qcom/kodiak-el2.dtso | 35 ++
drivers/firmware/qcom/Kconfig | 19 +
drivers/firmware/qcom/Makefile | 2 +
drivers/firmware/qcom/qcom_pas.c | 288 +++++++++++
drivers/firmware/qcom/qcom_pas.h | 50 ++
drivers/firmware/qcom/qcom_pas_tee.c | 479 ++++++++++++++++++
drivers/firmware/qcom/qcom_scm.c | 302 ++++-------
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 +-
drivers/media/platform/qcom/iris/Kconfig | 25 +-
.../media/platform/qcom/iris/iris_firmware.c | 9 +-
drivers/media/platform/qcom/venus/Kconfig | 1 +
drivers/media/platform/qcom/venus/firmware.c | 11 +-
drivers/net/ipa/Kconfig | 2 +-
drivers/net/ipa/ipa_main.c | 13 +-
drivers/net/wireless/ath/ath12k/Kconfig | 2 +-
drivers/net/wireless/ath/ath12k/ahb.c | 8 +-
drivers/remoteproc/Kconfig | 1 +
drivers/remoteproc/qcom_q6v5_mss.c | 5 +-
drivers/remoteproc/qcom_q6v5_pas.c | 51 +-
drivers/remoteproc/qcom_wcnss.c | 12 +-
drivers/soc/qcom/mdt_loader.c | 12 +-
include/linux/firmware/qcom/qcom_pas.h | 43 ++
include/linux/firmware/qcom/qcom_scm.h | 29 --
include/linux/soc/qcom/mdt_loader.h | 6 +-
28 files changed, 1115 insertions(+), 317 deletions(-)
create mode 100644 arch/arm64/boot/dts/qcom/kodiak-el2.dtso
create mode 100644 drivers/firmware/qcom/qcom_pas.c
create mode 100644 drivers/firmware/qcom/qcom_pas.h
create mode 100644 drivers/firmware/qcom/qcom_pas_tee.c
create mode 100644 include/linux/firmware/qcom/qcom_pas.h
--
2.51.0
This patch series introduces a Trusted Execution Environment (TEE)
driver for Qualcomm TEE (QTEE). QTEE enables Trusted Applications (TAs)
and services to run securely. It uses an object-based interface, where
each service is an object with sets of operations. Clients can invoke
these operations on objects, which can generate results, including other
objects. For example, an object can load a TA and return another object
that represents the loaded TA, allowing access to its services.
Kernel and userspace services are also available to QTEE through a
similar approach. QTEE makes callback requests that are converted into
object invocations. These objects can represent services within the
kernel or userspace process.
Note: This patch series focuses on QTEE objects and userspace services.
Linux already provides a TEE subsystem, which is described in [1]. The
tee subsystem provides a generic ioctl interface, TEE_IOC_INVOKE, which
can be used by userspace to talk to a TEE backend driver. We extend the
Linux TEE subsystem to understand object parameters and an ioctl call so
client can invoke objects in QTEE:
- TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF_*
- TEE_IOC_OBJECT_INVOKE
The existing ioctl calls TEE_IOC_SUPPL_RECV and TEE_IOC_SUPPL_SEND are
used for invoking services in the userspace process by QTEE.
The TEE backend driver uses the QTEE Transport Message to communicate
with QTEE. Interactions through the object INVOKE interface are
translated into QTEE messages. Likewise, object invocations from QTEE
for userspace objects are converted into SEND/RECV ioctl calls to
supplicants.
The details of QTEE Transport Message to communicate with QTEE is
available in [PATCH 12/12] Documentation: tee: Add Qualcomm TEE driver.
You can run basic tests with following steps:
git clone https://github.com/quic/quic-teec.git
cd quic-teec
mkdir build
cmake .. -DCMAKE_TOOLCHAIN_FILE=CMakeToolchain.txt -DBUILD_UNITTEST=ON
https://github.com/quic/quic-teec/blob/main/README.md lists dependencies
needed to build the above.
More comprehensive tests are availabe at
https://github.com/qualcomm/minkipc.
root@qcom-armv8a:~# qtee_supplicant &
root@qcom-armv8a:~# qtee_supplicant: process entry PPID = 378
Total listener services to start = 4
Opening CRequestTABuffer_open
Path /data/
register_service ::Opening CRegisterTABufCBO_UID
Calling TAbufCBO Register
QTEE_SUPPLICANT RUNNING
root@qcom-armv8a:~# smcinvoke_client -c /data 1
Run callback obj test...
Load /data/tzecotestapp.mbn, size 52192, buf 0x1e44ba0.
System Time: 2024-02-27 17:26:31
PASSED - Callback tests with Buffer inputs.
PASSED - Callback tests with Remote and Callback object inputs.
PASSED - Callback tests with Memory Object inputs.
TEST PASSED!
root@qcom-armv8a:~#
root@qcom-armv8a:~# smcinvoke_client -m /data 1
Run memory obj test...
Load /data/tzecotestapp.mbn, size 52192, buf 0x26cafba0.
System Time: 2024-02-27 17:26:39
PASSED - Single Memory Object access Test.
PASSED - Two Memory Object access Test.
TEST PASSED!
This series has been tested for QTEE object invocations, including
loading a TA, requesting services from the TA, memory sharing, and
handling callback requests to a supplicant.
Tested platforms: sm8650-mtp, sm8550-qrd, sm8650-qrd, sm8650-hdk
[1] https://www.kernel.org/doc/Documentation/tee.txt
Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi(a)oss.qualcomm.com>
Changes in v11:
- Rebased on next.
- Link to v10:
https://lore.kernel.org/r/20250909-qcom-tee-using-tee-ss-without-mem-obj-v1…
Changes in v10:
- Remove all loggings in qcom_scm_qtee_init().
- Reorder patches.
- Link to v9:
https://lore.kernel.org/r/20250901-qcom-tee-using-tee-ss-without-mem-obj-v9…
Changes in v9:
- Remove unnecessary logging in qcom_scm_probe().
- Replace the platform_device_alloc()/add() sequence with
platform_device_register_data().
- Fixed sparse warning.
- Fixed documentation typo.
- Link to v8:
https://lore.kernel.org/r/20250820-qcom-tee-using-tee-ss-without-mem-obj-v8…
Changes in v8:
- Check if arguments to qcom_scm_qtee_invoke_smc() and
qcom_scm_qtee_callback_response() are NULL.
- Add CPU_BIG_ENDIAN as a dependency to Kconfig.
- Fixed kernel bot errors.
- Link to v7:
https://lore.kernel.org/r/20250812-qcom-tee-using-tee-ss-without-mem-obj-v7…
Changes in v7:
- Updated copyrights.
- Updated Acked-by: tags.
- Fixed kernel bot errors.
- Link to v6:
https://lore.kernel.org/r/20250713-qcom-tee-using-tee-ss-without-mem-obj-v6…
Changes in v6:
- Relocate QTEE version into the driver's main service structure.
- Simplfies qcomtee_objref_to_arg() and qcomtee_objref_from_arg().
- Enhanced the return logic of qcomtee_object_do_invoke_internal().
- Improve comments and remove redundant checks.
- Improve helpers in qcomtee_msh.h to use GENMASK() and FIELD_GET().
- updated Tested-by:, Acked-by:, and Reviewed-by: tags
- Link to v5:
https://lore.kernel.org/r/20250526-qcom-tee-using-tee-ss-without-mem-obj-v5…
Changes in v5:
- Remove references to kernel services and public APIs.
- Support auto detection for failing devices (e.g., RB1, RB4).
- Add helpers for obtaining client environment and service objects.
- Query the QTEE version and print it.
- Move remaining static variables, including the object table, to struct
qcomtee.
- Update TEE_MAX_ARG_SIZE to 4096.
- Add a dependancy to QCOM_TZMEM_MODE_SHMBRIDGE in Kconfig
- Reorganize code by removing release.c and qcom_scm.c.
- Add more error messages and improve comments.
- updated Tested-by:, Acked-by:, and Reviewed-by: tags
- Link to v4: https://lore.kernel.org/r/20250428-qcom-tee-using-tee-ss-without-mem-obj-v4…
Changes in v4:
- Move teedev_ctx_get/put and tee_device_get/put to tee_core.h.
- Rename object to id in struct tee_ioctl_object_invoke_arg.
- Replace spinlock with mutex for qtee_objects_idr.
- Move qcomtee_object_get to qcomtee_user/memobj_param_to_object.
- More code cleanup following the comments.
- Cleanup documentations.
- Update MAINTAINERS file.
- Link to v3: https://lore.kernel.org/r/20250327-qcom-tee-using-tee-ss-without-mem-obj-v3…
Changes in v3:
- Export shm_bridge create/delete APIs.
- Enable support for QTEE memory objects.
- Update the memory management code to use the TEE subsystem for all
allocations using the pool.
- Move all driver states into the driver's main service struct.
- Add more documentations.
- Link to v2: https://lore.kernel.org/r/20250202-qcom-tee-using-tee-ss-without-mem-obj-v2…
Changes in v2:
- Clean up commit messages and comments.
- Use better names such as ubuf instead of membuf or QCOMTEE prefix
instead of QCOM_TEE, or names that are more consistent with other
TEE-backend drivers such as qcomtee_context_data instead of
qcom_tee_context.
- Drop the DTS patch and instantiate the device from the scm driver.
- Use a single structure for all driver's internal states.
- Drop srcu primitives and use the existing mutex for synchronization
between the supplicant and QTEE.
- Directly use tee_context to track the lifetime of qcomtee_context_data.
- Add close_context() to be called when the user closes the tee_context.
- Link to v1: https://lore.kernel.org/r/20241202-qcom-tee-using-tee-ss-without-mem-obj-v1…
Changes in v1:
- It is a complete rewrite to utilize the TEE subsystem.
- Link to RFC: https://lore.kernel.org/all/20240702-qcom-tee-object-and-ioctls-v1-0-633c3d…
---
Amirreza Zarrabi (11):
firmware: qcom: tzmem: export shm_bridge create/delete
firmware: qcom: scm: add support for object invocation
tee: allow a driver to allocate a tee_device without a pool
tee: add close_context to TEE driver operation
tee: add TEE_IOCTL_PARAM_ATTR_TYPE_UBUF
tee: add TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF
tee: increase TEE_MAX_ARG_SIZE to 4096
tee: add Qualcomm TEE driver
tee: qcom: add primordial object
tee: qcom: enable TEE_IOC_SHM_ALLOC ioctl
Documentation: tee: Add Qualcomm TEE driver
Documentation/tee/index.rst | 1 +
Documentation/tee/qtee.rst | 96 ++++
MAINTAINERS | 7 +
drivers/firmware/qcom/qcom_scm.c | 119 ++++
drivers/firmware/qcom/qcom_scm.h | 7 +
drivers/firmware/qcom/qcom_tzmem.c | 63 ++-
drivers/tee/Kconfig | 1 +
drivers/tee/Makefile | 1 +
drivers/tee/qcomtee/Kconfig | 12 +
drivers/tee/qcomtee/Makefile | 9 +
drivers/tee/qcomtee/async.c | 182 ++++++
drivers/tee/qcomtee/call.c | 820 +++++++++++++++++++++++++++
drivers/tee/qcomtee/core.c | 915 +++++++++++++++++++++++++++++++
drivers/tee/qcomtee/mem_obj.c | 169 ++++++
drivers/tee/qcomtee/primordial_obj.c | 113 ++++
drivers/tee/qcomtee/qcomtee.h | 185 +++++++
drivers/tee/qcomtee/qcomtee_msg.h | 304 ++++++++++
drivers/tee/qcomtee/qcomtee_object.h | 316 +++++++++++
drivers/tee/qcomtee/shm.c | 150 +++++
drivers/tee/qcomtee/user_obj.c | 692 +++++++++++++++++++++++
drivers/tee/tee_core.c | 127 ++++-
drivers/tee/tee_private.h | 6 -
include/linux/firmware/qcom/qcom_scm.h | 6 +
include/linux/firmware/qcom/qcom_tzmem.h | 15 +
include/linux/tee_core.h | 54 +-
include/linux/tee_drv.h | 12 +
include/uapi/linux/tee.h | 56 +-
27 files changed, 4410 insertions(+), 28 deletions(-)
---
base-commit: 8b8aefa5a5c7d4a65883e5653cf12f94c0b68dbf
change-id: 20241202-qcom-tee-using-tee-ss-without-mem-obj-362c66340527
Best regards,
--
Amirreza Zarrabi <amirreza.zarrabi(a)oss.qualcomm.com>
Hello,
I am working on embedded automotive systems repair and investigating
behavior of Samsung eMMC (KLMBG4GEUF) in systems that appear to use OP-TEE
for secure storage.
Real scenario:
- Two identical devices (same hardware)
- One working, one not booting
- Full eMMC dump taken from working device:
- USER
- BOOT1 / BOOT2
- EXT_CSD
- RPMB (reported readable, but content appears empty or not usable)
Tests:
- Writing full dump to another device → no boot
- Swapping eMMC between boards → both fail
- Writing only USER → no change
From observations:
- RPMB appears non-clonable
- Secure storage likely bound to hardware
- Boot seems dependent on this binding
Questions:
1. In OP-TEE, is RPMB always tied to a hardware unique key (HUK)?
2. Is it expected that RPMB content cannot be reused across identical
devices?
3. Does OP-TEE enforce secure storage binding in a way that prevents
cloning?
4. In case of damaged eMMC, is there any supported way to reinitialize
or recover secure storage?
I am not trying to bypass security, but to understand the architectural
limitation in real repair scenarios.
Any clarification would be highly appreciated.
Best regards,