SyzTrust: State-aware Fuzzing on Trusted OS Designed for IoT Devices

Qinying Wang∗† , Boyu Chang∗ , Shouling Ji∗( ), , Yuan Tian‡ , Xuhong Zhang∗ , Binbin Zhao§ , Gaoning Pan∗ ,
Chenyang Lyu∗ , Mathias Payer† , Wenhai Wang∗ , Raheem Beyah§
∗ Zhejiang
University, † EPFL, ‡ University of California, Los Angelos, § Georgia Institute of Technology
E-mails: {wangqinying, bychang, sji}@zju.edu.cn, [email protected], [email protected], [email protected],
{pgn, puppet}@zju.edu.cn, [email protected], [email protected], [email protected]
arXiv:2309.14742v1 [cs.CR] 26 Sep 2023

Abstract—Trusted Execution Environments (TEEs) embedded Samsung have designed TEEs for low-end Microcontroller
in IoT devices provide a deployable solution to secure IoT Units (MCUs) [20], [57], [61] and device manufacturers
applications at the hardware level. By design, in TEEs, the have embedded the TEE in IoT devices such as unmanned
Trusted Operating System (Trusted OS) is the primary com- aerial vehicles and smart locks, to protect sensitive data and
ponent. It enables the TEE to use security-based design tech- to provide key management services. A TEE is composed of
niques, such as data encryption and identity authentication. Client Applications (CAs), Trusted Applications (TAs), and
Once a Trusted OS has been exploited, the TEE can no a Trusted Operating System (Trusted OS). Among them, the
longer ensure security. However, Trusted OSes for IoT devices Trusted OS is the primary component to enable the TEE
have received little security analysis, which is challenging using security-based design techniques, and its security is
from several perspectives: (1) Trusted OSes are closed-source the underlying premise of a reliable TEE where the code and
and have an unfavorable environment for sending test cases data are protected in terms of confidentiality and integrity.
and collecting feedback. (2) Trusted OSes have complex data Unfortunately, implementation flaws in Trusted OSes violate
structures and require a stateful workflow, which limits existing the protection guarantees, bypassing confidentiality and in-
vulnerability detection tools. tegrity guarantees. These flaws lead to critical consequences,
To address the challenges, we present S YZ T RUST, the including sensitive information leakage (CVE-2019-25052)
first state-aware fuzzing framework for vetting the security of
and code execution within the Trusted OS context [13],
[42]. Once attackers gain control of Trusted OSes, they can
resource-limited Trusted OSes. S YZ T RUST adopts a hardware-
launch critical attacks, such as creating a backdoor to the
assisted framework to enable fuzzing Trusted OSes directly
Linux kernel [12], and extracting full disk encryption keys
on IoT devices as well as tracking state and code coverage
of Android’s KeyMaster service [11].
non-invasively. S YZ T RUST utilizes composite feedback to guide
While TEEs are increasingly embedded in IoT devices,
the fuzzer to effectively explore more states as well as to
the security of Trusted OS for IoT devices remains under
increase the code coverage. We evaluate S YZ T RUST on Trusted
studied. Considering the emerging amount of diversified
OSes from three major vendors: Samsung, Tsinglink Cloud, MCUs and IoT devices, manual analysis, such as reverse
and Ali Cloud. These systems run on Cortex M23/33 MCUs, engineering, requires significant expert efforts and is there-
which provide the necessary abstraction for embedded TEEs. fore infeasible at scale. Recent academic works use fuzzing
We discovered 70 previously unknown vulnerabilities in their to automate TEE testing. However, unlike Trusted OSes
Trusted OSes, receiving 10 new CVEs so far. Furthermore, for Android devices, Trusted OSes for IoT devices are
compared to the baseline, S YZ T RUST has demonstrated sig- built on TrustZone-M with low-power and cost-sensitive
nificant improvements, including 66% higher code coverage, MCUs, including NuMicro M23. Thus, Trusted OSes for
651% higher state coverage, and 31% improved vulnerability- IoT devices are more hardware-dependent and resource-
finding capability. We report all discovered new vulnerabilities constrained, complicating the development of scalable and
to vendors and open source S YZ T RUST. usable testing approaches with different challenges. In the
following, we conclude two challenges for fuzzing IoT
1. Introduction Trusted OSes.
Challenge I: The inability of instrumentation and re-
Trusted Execution Environments (TEEs) are essential stricted environment. Most Trusted OSes are closed-
to securing important data and operations in IoT devices. source. Additionally, TEE implementations, especially the
GlobalPlatform, the leading technical standards organiza- Trusted OSes are often encrypted by IoT vendors, which
tion, has reported a 25-percent increase in the number implies the inability to instrument and monitor the code ex-
of TEE-enabled IoT processors being shipped quarterly, ecution in the secure world. Accordingly, classic feedback-
year-over-year [29]. Recently, major IoT vendors such as driven fuzzing cannot be directly applied to the scenario
of testing TEEs including TAs and Trusted OSes. Existing
Shouling Ji is the corresponding author. works either rely on on-device binary instrumentations [15]

1
or require professional domain knowledge and rehosting IoT devices is resource constrained, which makes storing
through proprietary firmware emulation [32] to enable test- ETM traces on board difficult and limits the fuzzing speed.
ing and coverage tracking. However, as for the Trusted OSes Additionally, the TEE internals are complicated and have
designed for IoT devices, the situation is more challenging multiple components, which generate noisy trace packets.
due to the following two reasons. First, IoT devices are Therefore, we offload heavy-weight tasks to a PC and care-
severely resource-limited, while existing binary instrumen- fully scheduled the fuzzing subprocesses in a more parallel
tations are heavy-weight for them and considerably limit way. We also present an event- and address-based trace filter
their execution speed. Second, as for rehosting, IoT devices to handle the noisy trace packets that are not executed by
are mostly hardware-dependent, rendering the reverse en- the Trusted OS. Additionally, we adopt an efficient code
gineering and implementation effort for emulated software coverage calculation algorithm directly on the raw packets.
and hardware components unacceptable. In addition, rehost- Second, as for the Challenge II, the vulnerability detec-
ing faces the limitation of the inaccuracy of modeling the tion capability of coverage-based fuzzers is limited, and a
behavior of hardware components. To our best knowledge, more effective fuzzing strategy is required. Therefore, we
the only existing TEE rehosting solution PartEmu [32] is propose a composite feedback mechanism, which enhances
not publicly available and does not support the mainstream code coverage with state feedback. To be specific, we utilize
TEE based on Cortex-M MCUs designed for IoT devices. state variables that control the execution contexts to present
Challenge II: Complex structure and stateful work- the states of a Trusted OS. However, such state variables are
flow. Trusted OSes for IoT devices are surprisingly com- usually stored in closed-source and customized data struc-
plex. Specifically, Trusted OSes implement multiple cryp- tures within Trusted OSes. Existing state variable inference
tographic algorithms, such as AES and MAC, without un- methods either use explicit protocol packet sequences [45]
derlying hardware support for these algorithms as would or require source codes of target software [35], [68], which
be present on Cortex-A processors. To implement these are unavailable for Trusted OSes. Therefore, to identify the
algorithms in a secure way, Trusted OSes maintain several state-related members from those complex data structures,
state diagrams to store the execution contexts and guide the S YZ T RUST collects some heuristics for Trusted OS and
execution workflow. To explore more states of a Trusted utilizes them to perform an active state variable inference
OS, a fuzzer needs to feed syscall sequences in several algorithm. After that, S YZ T RUST monitors the state variable
specific orders with different specific state-related argument values during the fuzzing procedure as the state feedback.
values. Without considering such statefulness of Trusted Finally, S YZ T RUST is the first end-to-end solution ca-
OSes, coverage-based fuzzers are unlikely to explore further pable of fuzzing Trusted OSes for IoT devices. Moreover,
states, causing the executions to miss the vulnerabilities the design of the on-device fuzzing framework and modular
hidden in a deep state. Unfortunately, existing fuzzing tech- implementation make S YZ T RUST more extensible. With
niques lack state-awareness for Trusted OSes. Specifically, several MCU-specific configurations, S YZ T RUST scales to
they have trouble understanding which state a Trusted OS Trusted OSes on different MCUs from different vendors.
reaches since there are no rich-semantics response codes to
Evaluation. We evaluate S YZ T RUST on real-world Trusted
indicate it. In addition, due to the lack of source code and
OSes from three leading IoT vendors Samsung, Tsinglink
the inability of instrumentation, it is hard to infer and extract
Cloud, and Ali Cloud. The evaluation result shows that
the state variables by program analysis.
S YZ T RUST is effective at discovering new vulnerabilities
Our solution. To address the above key challenges, we pro-
and exploring new states and codes. As a result, S YZ T RUST
pose and implement S YZ T RUST, the first fuzzing framework
has discovered 70 new vulnerabilities. Among them, vendors
targeting Trusted OSes for IoT devices, supporting state and
confirmed 28, and assigned 10 CVE IDs. The vendors
coverage-guided fuzzing. Specifically, we propose an on-
are still investigating others. Compared to state-of-the-art
device fuzzing framework and leverage a hardware-in-the-
approaches, S YZ T RUST finds more vulnerabilities, hits 66%
loop approach. To support in-depth vulnerability detection,
higher code branches, and 651% higher state coverage.
we propose a composite feedback mechanism that guides the
fuzzer to explore more states and increase code coverage. Summary and contributions.
S YZ T RUST necessitates diverse contributions. First, to • We propose S YZ T RUST, the first fuzzing framework
tackle Challenge I, we propose a hardware-assisted fuzzing targeting Trusted OSes for IoT devices, supporting effective
framework to execute test cases as well as collect code state and code coverage guided fuzzing. With a carefully
coverage feedback. Specifically, we decouple the execution designed hardware-assisted fuzzing framework and a com-
engine from the rest of the fuzzer to enable directly exe- posite feedback mechanism, S YZ T RUST is extensible and
cuting test cases in the protective TEE secure world on the configurable to different IoT devices.
resource-limited MCU. To support coverage tracking, we • With S YZ T RUST, we evaluate three popular Trusted
present a selective trace collection approach instead of costly OSes on three leading IoT vendors and detect several
code instrumentation to enable tracing instructions on a previously unknown bugs. We have responsibly reported
target MCU. In particular, we leverage the ARM Embedded these vulnerabilities to the vendors and got acknowledged
Trace Macrocell (ETM) feature to collect raw trace packets from vendors such as Samsung. We release S YZ T RUST
by monitoring instruction and data buses on MCU with as an open-source tool for facilitating further studies at
a low-performance impact. However, the Trusted OS for https://github.com/SyzTrust.

2
 Normal World Secure World 2.2. Debug Probe
Client Applications (CAs) Trusted Applications (TAs) A debug probe is a special hardware device for low-
CA CA CA TA TA TA level control of ARM-based MCUs, using DAP (Debug
Access Port) provided by the ARM CoreSight Architecture
[25]. It bridges the connection between a computer and an
TEE Client API TEE Internal API MCU and provides full debugging functionality, including
Rich OS Switch
watchpoints, flash memory breakpoints, memory, as well as
Trusted OS
(e.g., FreeRTOS) Instructions register examination or editing. In addition, a debug probe
can record data and instruction accesses at runtime through
Figure 1: Structure of TrustZone-M based TEE. the ARM ETM feature. ETM is a subsystem of ARM
Coresight Architecture and allows for traceability, whose
function is similar to Intel PT. The ETM generates trace
elements for executed signpost instructions that enable
2. Background reconstruction of all the executed instructions. Utilizing the
above features, the debug probe has shown its effectiveness
in tracing and debugging malware [49], unpacking Android
apps [65], or fuzzing Linux peripheral drivers [37].
2.1. TEE and Trusted OS
3. Threat Model
A TEE is a secure enclave on a device’s main processor Our attacker tries to achieve multiple goals: gaining
that is separated from the main OS. It ensures the confiden- control over, extracting confidential information from, and
tiality and integrity of code and data loaded inside it [64]. causing crashes in other Trusted Applications (TAs) hosted
For standardizing the TEE implementations, GlobalPlatform on the same Trusted OS or the Trusted OS itself. We
(GP) has developed a number of specifications. For instance, consider two practical attack scenarios. First, an attacker can
it specifies the TEE Internal Core API implemented in the exploit our discovered vulnerabilities by providing carefully
Trusted OS to enable a TA to perform its security functions crafted data to a TA. They can utilize a malicious Client
[30]. However, it is difficult for vendors to implement a Application (CA) to pass the crafted data to a TA. For
Trusted OS correctly since there are lots of APIs with instance, in mTower, CVE-2022-38511 (ID 1 in Table 1)
complex and stateful functions defined in the GP TEE spec- can be triggered by passing a large key size value from a
ifications. For instance, the TEE Internal Core API defines CA to a TA. Second, an attacker can exploit our discovered
six types of APIs, including cryptographic operations APIs vulnerabilities by injecting a malicious TA into the secure
supporting more than 20 complex cryptographic algorithms. world. They can do this through rollback attacks or electro-
In addition, the TEE Internal Core API also requires that a magnetic fault injections (CVE-2022-47549).
Trusted OS shall implement state diagrams to manage the
operation. The two aforementioned factors make it challeng- 4. Design
ing for device vendors to develop a secure Trusted OS.
ARM TrustZone has become the de-facto hardware tech- Figure 2 gives an overview of S YZ T RUST’s design.
nology to implement TEEs in mobile environments [17] and S YZ T RUST includes two modules: the fuzzing engine on the
has been deployed in servers [33], low-end IoT devices [8], Personal Computer (PC) and the execution engine on the
[53], and industrial control systems [27]. For IoT devices, MCU. The fuzzing engine generates and sends test cases
the Cortex-M23/33 MCUs, introduced by the ARM Commu- to the MCU via the debug probe. The execution engine
nity in 2016, are built on new TrustZone for ARMv8-M as executes the received test case on the target Trusted OS.
security foundations for billions of devices [22]. TrustZone At a high level, we propose a hardware-assisted fuzzing
for ARMv8-M Cortex-M has been optimized for faster con- framework and a composite feedback mechanism to guide
text switch and low-power applications and is designed from the fuzzer. Given the inaccessible environment of Trusted
the ground up instead of being reused from Cortex-A [54]. OSes, we design a TA and CA pair as a proxy to the
As Figure 1 shows, instead of utilizing a secure monitor Trusted OS and utilize a debug probe to access the MCU for
in TrustZone for Cortex-A, the division of the secure and feedback collection. To handle the challenge of limited re-
normal world is memory-based, and transitions take place sources, we decouple the execution engine from S YZ T RUST
automatically in the exception handle mode. Based on the and only run it on the MCU. This allows S YZ T RUST,
TrustZone-M, IoT vendors provide Trusted OS binaries to with its resource-demanding core components, to run more
the device manufacturers and then the device manufacturers effectively on a PC. To handle the statefulness of Trusted
produce devices with device-specific TAs for the end users. OSes, we include state feedback with code coverage in the
This paper focuses on the Trusted OSes from different IoT composite feedback. State variables represent internal states,
vendors and provides security insights for device manufac- and our inference method identifies them in closed-source
turers and end users. Trusted OSes.

3
 State Variable Fuzzing Loop
Trusted OS State Variables
Inference

Fuzzing Engine (on PC) Execution Engine

Test cases (on MCU)
Manager Test cases

Debug Probe
Initial Seeds Hardware-assisted Controller Test cases
Proxy CA & TA
Code coverage Trace
A Collector
Syscall composite
State coverage Feedback Feedback
feedback State Variables Trusted OS
Templates
Monitor

Figure 2: Overview of S YZ T RUST. S YZ T RUST consists of a fuzzing engine running on a PC, an execution engine running
on an MCU, and a debug probe to bridge the fuzzing engine and the execution engine.
The main workflow is as follows. First, S YZ T RUST a target Trusted OS by mutating them. However, there is
accepts two inputs, including initial seeds and syscall tem- no off-the-shelf seed corpus for testing Trusted OSes, and
plates. Second, the manager generates test cases through constructing one is not trivial, as the syscall sequences
two fuzzing tasks, including generating a new test case from with arguments should follow critical crypto constraints,
scratch based on syscall templates or by mutating a selected and manually constructing valid sequences will need much
seed. Then, the generated test cases are delivered to the effort. For example, a valid seed includes a certain order
execution engine on MCU through the debug probe. The of syscall sequences to initiate an encryption operation, and
execution engine executes these test cases to test the Trusted the key and the encryption mode should be consistent with
OS. Meanwhile, the debug probe selectively records the supporting encryption. Fortunately, OP-TEE [39], an open-
executed instruction trace, which is processed by our trace source TEE implementation for Cortex-A, offers a test suite,
collector as an alternative to code coverage. Additionally, which can be utilized to construct seeds for most Trusted
the state variable monitor tracks the values of a set of target OSes. Specifically, we automatically inject codes in TAs
state variables to calculate state coverage via the debug provided by the test suite to log the syscall names and
probe. Finally, the code and state coverage is fed to the their arguments. Then we automatically convert those logs
manager as composite feedback to guide the fuzzer. The into seeds following the format required by S YZ T RUST. In
above procedures are iteratively executed and we denote the addition, we automatically add data dependencies between
iterative workflow as the fuzzing loop. syscalls in the seed corpus. Accordingly, we identify the
return values from syscalls that are input arguments of other
4.1. Inputs syscalls and add helper syscalls for the identified values.
Although the syscall template and seed corpus construc-
Syscall templates and initial seeds are fed to S YZ T RUST. tion require extra work, it is a one-shot effort and can be
Syscall templates. Provided syscall templates, used in the further study of Trusted OS security.
S YZ T RUST is more likely to generate valid test cases
by following the format defined by the templates. Syscall 4.2. A Hardware-assisted Framework
templates define the syscalls with their argument types
as well as special types that provide the semantics of an Now our hardware-assisted fuzzing framework enables
argument. For instance, resources represent the values the generated test cases to be executed in protective and
that need to be passed from an output of one syscall resource-constrained trusted environments on IoT devices.
to an input of another syscall, which refers to the data To handle the constrained resources in Challenge I, we
dependency between syscalls. We manually write syscall decouple the execution engine from the other components
templates for the Internal Core API for the GP TEE in of S YZ T RUST to ease the execution overhead of the MCU.
Syzlang (S YZKALLER’s syscall description language [31]). As shown in Figure 2, the fuzzing engine, which includes
However, a value with a complex structure type, which is most core components of S YZ T RUST and requires more
common in Trusted OSes, cannot be used as a resource computing resources and memory space, runs on a PC,
value due to the design limitation of Syzlang. To handle while only the execution engine runs on the MCU. Thus,
this limitation, we extend the syscall templates with helper S YZ T RUST does the heavy tasks, including seed preserva-
syscalls, which accept values of complex structures and tion, seed selection, type-aware generation, and mutation.
output their point addresses as resource values. In As for the protected execution environment in Challenge
total, we have 37 syscall templates and 8 helper syscalls, I, we design a pair of CA and TA as the execution engine
covering all the standard cryptographic APIs. that executes the test cases to test the Trusted OSes. We
Initial seeds. Since syscall templates are used to gen- utilize a debug probe to bridge the connection between the
erate syntactically valid inputs, S YZ T RUST requires initial fuzzing engine and the execution engine. In the following,
seeds to collect some valid syscall sequences and argu- we introduce the design of delivering test cases and the pair
ments and speed up the fuzzing procedure. Provided initial of CA and TA. First, as shown in Figure 2, the debug probe
seeds, S YZ T RUST continuously generates test cases to test transfers test cases and feedback between the fuzzing engine

4
and the execution engine. Specifically, a debug probe can 10 InvokeOneSyscall ( ) ;
directly access the memory of the target MCU. Thus, the 11 / / Data a c c e s s e v e n t i s t r i g g e r e d , s t o p t r a c i n g
12 s t o p e v e n t ++;
debug probe accepts generated test cases from the manager 13 i f ( AllSyscallsExecuted () ){
engine and writes them to a specific memory of the target 14 break ;
15 }
MCU. As for test case transportation, we design a serializer 16 } while (1) ;
to encode the test cases into minimum binary data denoted 17 }
as payloads before sending them to the MCU. A payload 18

includes a sequence of syscalls with their syscall names, Listing 1: A code snippet containing the main execution
syscall argument types, and syscall argument values. In ad- logic from our designed TA.
dition, S YZ T RUST denotes syscall names as ordinal numbers
to minimize the transportation overhead. Second, the pair of However, the IoT Trusted OSes are highly resource-
CA and TA plays the role of a proxy to handle the test cases. constrained, making locally storing ETM traces infeasi-
Accordingly, the CA monitors the specific memory in the ble and limiting the speed of local fuzzing. Therefore,
MCU. If a payload is written, the CA reads the binary data S YZ T RUST utilizes the debug probe (see Section 4.2) to
from the specific memory and delivers them to the TA. Then stream all ETM trace data to the host PC in real time while
the TA deserializes the received binary data and executes the target system is running. Moreover, S YZ T RUST enables
them one by one to test a Trusted OS implementation. parallel execution of test case generation, transmission, and
Accordingly, the TA invokes specific syscalls according execution, as well as coverage calculation, thereby boosting
to the ordinal numbers and fills them in with arguments the speed of fuzzing.
extracted from the payload. To this end, the TA hardcodes For code coverage, we cannot directly use the raw
the syscalls declaration codes that are manually prepared. instruction trace packets generated by the ETM as a re-
The manual work to prepare the declaration codes is a one- placement for branch coverage due to two issues. First,
shot effort that can be easily done by referring to the GP there is a gap between the raw ETM trace packets and
TEE Internal Core API specification. the instruction traces generated by the Trusted OS. The
TEE internals are complicated and the ETM component
4.3. Selective Instruction Trace Tracking records instruction traces generated by the software running
on the MCU, including the CA, rich OS, the TA, and the
This section introduces how to obtain the code coverage Trusted OS. Thus, we design a selective instruction trace
feedback in S YZ T RUST when testing the Trusted OSes. collection strategy to generate fine-grained traces. ARM
To handle the inability of instrumentation in Challenge ETM allows enabling/disabling trace collection when cor-
I, we present a selective instruction trace track, which is responding events occur. We configure the different events
implemented in the trace collector in the fuzzing engine. via the Data Watchpoint and Trace Unit (DWT) hardware
The trace collector controls the debug probe to collect traces feature to filter out noisy packets. In S YZ T RUST, we aim to
synchronously when the test cases are being executed. After calculate the code coverage triggered by every syscall in a
completing a test case, it calculates the code coverage and test case and generated by Trusted OS. Thus, as shown in
delivers it to the manager as feedback. Listing 1, we configure the event-based filters by adding two
In the selective instruction trace track, we utilize the data write access event conditions. The two event conditions
ETM component to enable non-invasive monitoring of the start ETM tracing before invoking a syscall and stop ETM
execution context of target Trusted OSes. The overall work- tracing after completing the syscall, respectively. In addition,
flow is as follows. (1) Before each payload is sent to we specify the address range of the secure world shall be
the MCU, the hardware-assisted controller resets the target included in the trace stream to filter noisy trace packets
MCU via the debug probe. (2) Once the execution engine generated from the normal world.
reads a valid payload from the specific memory space and Second, there is a gap between the raw ETM trace pack-
starts to execute it, the hardware-assisted controller starts ets to the quantitive coverage results. To precisely recover
the ETM component to record the instruction trace for each the branch coverage information, we have to decode the raw
syscall from the payload. Specifically, in the meanwhile trace packets and map them to disassembled binary instruc-
of executing the syscalls, the generated instruction trace is tion address. After that, we can recover the instruction traces
synchronously recorded and delivered to the fuzzing engine and construct the branch coverage information [69] [65].
via the debug probe. (3) After completing a payload, the However, disassembling code introduces significant run-time
hardware-assisted controller computes the coverage based overhead as it incurs high computation cost [18]. Thus, we
on the instruction traces for the manager. calculate the branch coverage directly using the raw trace
1 extern int32 t start event ; packets [37]. At a high level, this calculation mechanism
2 extern int32 t stop event ; utilizes a special basic block generated with Linear Code
3 void TA ProcessEachPayload ( ) { Sequence and Jump (LCSAJ) [66] to reflect any change in
4 RecvPayloadFromCA ( ) ;
5 DecodePayload ( ) ; basic block transitions. LCSAJ basic blocks consist of the
6 / / S t a r t i n v o k i n g s y s c a l l s one by one basic address of a raw ETM branch packet and a sequence of
7 do {
8 / / Data a c c e s s e v e n t i s t r i g g e r e d , s t a r t t r a c i n g branch conditions. The branch conditions indicate whether
9 s t a r t e v e n t ++; the instructions followed by the basic address are executed.

5
This mechanism performs several hash operations on the Test Cases
TEE_AllocateOperation
LCSAJ basic blocks to transform them into random IDs, (TEE_OperationHandle *operation,
uint32_t algorithm, uint32_t mode,
which we utilize as branch coverage feedback. uint32_t maxKeySize)
TEE_ResetOperation(…)
…
Test Harness
4.4. State Variable Inference and Monitoring Output Buffer
0000 0000 00c0 0000 0000 0008 0000
0000 0000 00a8 2d00 2000 0000 0000 Trusted OS
Here we introduce how to identify the internal state State Variable …
Inferer
of the Trusted OS and how to obtain the state coverage
feedback through the state variable monitor component. In
particular, the state variable inference provides the state struct __TEE_OperationHandle{
[0:3] algorithm: 0000 0000 00c0 0000 …
variable monitor with the address ranges of the inferred state … Hardware-assisted State
[40:43] operationState: 0001
Variables Monitor
variables. Then the state variable monitor tracks the values }
…

of these state variables synchronously when the execution

engine executes test cases. After completing a test case, Figure 3: State variable inference.
the state variable monitor calculates the state coverage and
delivers it to the manager as feedback. Below are the details
about state variable inference and monitoring. implementations. This method is based on the assumption
According to the GP TEE Core API specification, that the state variables in the above two handles will have
Trusted OSes have to maintain several complex state ma- different values according to different cryptographic oper-
chines to achieve the cryptographic algorithm in a highly ation configurations. For instance, in Samsung’s Trusted
secure way. To explore all states of Trusted OS, the OS implementation, after executing several syscalls to set
fuzzer needs to feed syscall sequences in several specific cryptographic arguments, the value of a state variable from
orders with different specific state-related argument val- TEE_OperationHandle changes from 0 to 1, which
ues. Coverage-based fuzzers are unlikely to explore further means a cryptographic operation is initialized.
states, causing the executions to miss some vulnerabilities Based on the assumption, S YZ T RUST uses a test har-
hidden in a deep state. For instance, a syscall sequence ness to generate and execute test cases carefully. Then
achieves a new DES cryptographic operation configuration S YZ T RUST records the buffers of the two handles and ap-
by filling different arguments, whose code coverage may plies state variable inference to detect the address ranges of
be the same as the syscall sequence to achieve a new state variables in the recorded buffers, as shown in Figure 3.
AES cryptographic operation configuration. Preserving such S YZ T RUST first filters randomly changeable byte sequences
syscall sequences as a seed and further exploring them that store pointers, encryption keys, and cipher text. Specif-
will achieve new cryptographic operations and gain new ically, S YZ T RUST conducts a 24-hour basic fuzzing proce-
code coverages. However, a coverage-based fuzzer may dure on the initial seeds from Section 4.1 and collects the
discard such syscall sequences that seem to have no code buffers of the two handles. S YZ T RUST then parses the buffer
coverage contribution but trigger new internal states. Thus, into four-byte sequences to recognize changeable values. Af-
S YZ T RUST additionally adopts state coverage as feedback ter that, S YZ T RUST collects all different values for each byte
to handle the statefulness of Trusted OSes. sequence in the fuzzing procedure and calculates the number
State variable inference. By referring to the GP of times that these different values occur. S YZ T RUST con-
TEE Internal Core API specification and several open- siders the byte sequences that occur over 80 times as buffers
source TEE implementations from Github, we find that and excludes them from the state variables. For the remain-
Trusted OSes maintain two important structures, includ- ing byte sequences, S YZ T RUST applies the following infer-
ing the struct named TEE_OperationHandle and ence to identify state variables. In our observations, the cryp-
the struct named TEE_ObjectHandle, which present tographic operation configurations are determined by the
the internal states and control the execution context. We operation-related arguments, including the operation mode
further find that several vital variables (with names such (encryption, decryption, or verification) and cryptographic
as operationState and flags) in the two com- algorithm (AES, DES, or MAC). The cryptographic oper-
plex structs determine the Trusted OS’ internal state. ation configurations are also determined by the operation-
Thus, we utilize the value combinations of state variables related syscall sequences. We identify such arguments and
to present the states of Trusted OS and track all state- syscalls by referring to GP TEE Internal Core API specifica-
related variables to collect their values. Then, we con- tion and conclude the operation-related syscalls include the
sider a new value of the state variable combination as a syscalls that accept the two handles as an input argument
new state. However, the TEE_OperationHandle and and are specified to allocate, init, update, and finish a cryp-
TEE_ObjectHandle implementations are customized tographic operation, such as TEE_AllocateOperation
and close source, making recognizing the state variables and and TEE_AllocateTriansientObject. S YZ T RUST
their addresses challenging. performs mutated seeds that include the operation-related
To handle it, we come up with an active infer- syscalls and records the buffers of the two handles. These
ence method to recognize the state variables in the byte sequences that vary with certain syscall sequences with
TEE_OperationHandle and TEE_ObjectHandle certain arguments are considered state variables. Finally,

6
 Hit Times 𝐻𝑖𝑡 𝐻𝑖𝑡 ... 𝐻𝑖𝑡
preserves and prioritizes seeds that trigger new code or
HitMap
states. We design two maps as the seed corpus to preserve
seeds according to code coverage and state feedback. With
State Hashes 𝑆𝑡 𝑆𝑡 ... 𝑆𝑡
such seed corpus, S YZ T RUST then periodically selects seeds
SeedMap
from the hash table to explore new codes and new states.
𝑆𝑑 This section introduces how S YZ T RUST fine-tunes the evo-
𝑆𝑑 lution through a novel composite feedback mechanism, in-
Seed A Seed Node cluding seed preservation and seed selection strategy.
𝑆𝑑
Buckets • A Syscall Sequence
with Arguments
Seed preservation. Given the composite feedback
...

• Branch Coverage mechanism, we thus provide two maps as the seed corpus
𝑆𝑑
to store seeds that discover new state values and new code,
respectively. As shown in Figure 4, in two maps, S YZ T RUST
Figure 4: Seed corpus in S YZ T RUST. calculates the hash of combination values of state variables
as the keys. S YZ T RUST maps the state hashes to their hit
times in the HitMap and maps the state hashes to seed
S YZ T RUST outputs the address ranges of these byte se-
buckets in the SeedMap. In the SeedMap, for a certain
12/3 quences and feeds them to the hardware-assisted controller. 11
state hash, the mapping seed bucket contains one or several
State variable monitor. The identified state variables
seeds that can produce the matching state variable values. To
and their address ranges are then used as configurations
construct the SeedMap, S YZ T RUST handles the following
of the hardware-assisted controller. S YZ T RUST utilizes the
two situations. First, if a syscall from a test case triggers a
debug probe to monitor the state variables. When a new
new value combination of state variables, S YZ T RUST adds
TEE_OperationHandle or TEE_ObjectHandle is
a new state hash in the SeedMap. Then, S YZ T RUST maps
allocated, S YZ T RUST records its start address. Given the
the new state hash to a new seed bucket. To construct the
start address of the two handles and address ranges of state
seed bucket, S YZ T RUST utilizes the test case with its branch
variables, S YZ T RUST calculates the memory ranges of state
coverage to construct a seed node and appends the seed
variables and directly reads the memory via the debug probe.
bucket with the newly constructed seed node. Second, if
In the fuzzing loop, for each syscall, beside the branch cov-
a syscall from a test case triggers a new code coverage,
erage, S YZ T RUST records the hash of combination values
S YZ T RUST adds a new seed node in a seed bucket. Specifi-
of the state variables as the state coverage.
cally, S YZ T RUST calculates the hash of combination values
of state variables produced by the syscall. Then, S YZ T RUST
4.5. Fuzzing Loop looks up the seed bucket that is mapped to the state hash
and appends a new seed node that contains the test case
After collecting code and state coverage feedback, the
and its branch coverage to the seed bucket. Noted, a test
fuzzer enters the main fuzzing loop implemented in the
case could be stored in multiple seed buckets if it triggers
manager. S YZ T RUST has a similar basic fuzzing loop to
multiple feedbacks at the same time. As for the HitMap,
S YZKALLER. It schedules two tasks for test case gener-
each time after completing a test case, S YZ T RUST calculates
ation: generating a new test case from syscall templates
all the state hashes it triggers and updates the hit times for
or mutating an existing one based on selected seeds. As
these state hashes according to their hit times.
for the generation task, S YZ T RUST faithfully borrows the
Seed selection. Given the preserved seed corpus,
generation strategy from S YZKALLER. As for the muta-
S YZ T RUST applies a special seed selection strategy to
tion task, S YZ T RUST utilizes a composite feedback mech-
improve the fuzzing efficiency. Algorithm 1 shows how
anism to explore rarely visited states while increasing code
S YZ T RUST selects seeds from the corpus. First, S YZ T RUST
coverage. Notably, S YZ T RUST does not adopt the Triage
chooses a state and then chooses a seed from the map-
scheduling tasks from S YZKALLER due to two key reasons.
ping seed buckets according to the state. In state selection,
First, S YZ T RUST fuzzes directly on the MCU, enabling
S YZ T RUST is more likely to choose a rarely visited state
swift MCU resets after each test case, thus mitigating false
by a weighted random selection algorithm. The probability
positives in branch coverage. Branch coverage validation
of choosing a seed is negatively correlated with its hit
through triaging is, therefore, unnecessary. Second, exe-
times. Thus, we assign each seed a weight value, which
cuting test cases for Trusted OSes (averaging 30 syscalls)
is the reciprocal of its hit times. Finally, The probability of
is time-consuming, incurring a significant overhead for
choosing a seed is equal to the proportion of its weight in
S YZ T RUST to minimize a syscall sequence by removing
the sum of all weights. In seed selection, S YZ T RUST is more
syscalls one by one. Appendix A further experimentally
likely to choose a seed with high branch coverage. To this
demonstrates our intuition for the new scheduling tasks.
end, S YZ T RUST chooses a seed based on a weighted random
selection algorithm, and the probability of choosing a certain
4.6. Composite Feedback Mechanism seed is equal to the proportion of its branch coverage in all
S YZ T RUST adopts a novel composite feedback mecha- coverages. Notably, the probabilities of choosing a state and
nism, leveraging both code and state coverage to guide mu- seed are dynamically updated since the hit times and the sum
tation tasks within the fuzzing loop. Specifically, S YZ T RUST of coverage is updated in the fuzzing procedure.

7
 Algorithm 1: Seed Selection Algorithm structures in the Trusted OS and the use of our state variable
Input: C , SeedMap that maps state hashes to a set inference to collect address ranges. These structures can
of seeds be extracted from the documents and header files. We rely
Input: H , HitMap that maps state hashes to hit on two heuristics to help extract them. First, state-related
times data structures usually have common names, e.g., related to
Output: s, the selected seed context or state. Second, the state structures will be the in-
1 Sum W ← 0;
puts and outputs of several crypto operation-related syscalls.
2 M ap W = initMap() //maps state hashes to their
For example, on Link TEE Air, a pointer named context
weights ; is used among cryptographic syscalls such as tee aes init
3 for each key ∈ H do
and tee aes update, and can be further utilized to infer
4 t ← getValue(H, key ); state variables. This information can be obtained from the
5 Sum W ← Sum W + t−1 ; crypto.h header file.
6 end
7 for each key ∈ H do 5. Implementation
8 t ← getValue(H, key );
9 M ap W ← M ap W ∪ (key, t−1 /Sum W );
We have implemented a prototype of S YZ T RUST on
10 end
top of S YZKALLER. We replaced S YZKALLER’s execution
11 St ← WeightedRandom StateSelection(M ap W );
engine with our custom CA and TA pair, integrating our
12 seedSets ← getValue(C, St);
extended syscall templates, eliminating S YZKALLER’s triage
13 s ← WeightedRandom SeedSelection(seedSets);
scheduling task, and implementing our own seed preserva-
tion and selection strategy. Sections 4.2, 4.5, and 4.6 detail
these adaptations.
4.7. Scope and Scalability of S YZ T RUST. Below are details about our implementations. (1) As for
the overall fuzzing framework, we use the SEGGER J-Trace
S YZ T RUST targets Trusted OSes provided by IoT ven- Pro debug probe to control the communication between
dors and assumes that (i) a TA can be installed in the the fuzzing engine and the execution engine, as shown in
Trusted OS, and (ii) target devices have ETM enabled. Figure 5. The pair of CA and TA is developed following
These assumptions align with typical IoT Trusted OS sce- the GP TEE Internal Core API specification and is loaded
narios. First, given that IoT device manufacturers often into the MCU following the instructions provided by the
need to implement device-specific TAs, Trusted OS binaries IoT vendors. To control the debug probe, we developed a
supplied by IoT vendors generally allow TA installation. hardware-assisted controller based on the SEGGER J-Link
Second, S YZ T RUST tests IoT Trusted OSes by deploying SDK. The hardware-assisted controller receives commands
them on development boards where ETM is enabled by from the manager and sends feedback collected on the MCU
default. Moreover, S YZ T RUST can directly test the Trusted to the manager via socket communications. (2) For the selec-
OSes following the GP TEE Internal Core API specification tive instruction trace track, S YZ T RUST integrates the ETM
with MCU-specific configurations. It has built-in support for tracing component of the SEGGER J-Trace Pro and records
testing on alternative Trusted OSes, including proprietary the instruction traces from Trusted OSes non-invasively. The
ones. Appendix B extends discussion with concrete data. raw ETM packets decoder and branch coverage calculation
S YZ T RUST can support other Trusted OSes. To test a are accomplished in the hardware-assisted controller. (3)
new Trusted OSes on a different MCU, S YZ T RUST requires For the state variable inference and monitoring, S YZ T RUST
MCU configurations, including the address ranges of spe- follows the testing strategy in Section 4.4 and utilizes an
cific memory for storing payloads, the addresses of the data RTT component [2] from the SEGGER J-Trace Pro to
events for the event-based filter, and the address ranges of record related state variable values and deliver them to the
secure memory for the address-based filter. We developed fuzzing engine. The RTT component accesses memory in
tooling in the CA and TA to automatically help the analyst the background with high-speed transmission.
obtain all required addresses. In addition, by following the Several tools help us analyze the root cause of detected
development documents from IoT TEE vendors, the CA crashes. We utilize CmBacktrace, a customized backtrace
and TA may require slight adjustments to meet the format tool [70], to track and locate error codes automatically. Ad-
required by the new Trusted OSes and loaded into the Rich ditionally, we develop TEEKASAN based on KASAN [34]
OS and Trusted OS. and MCUASAN [59] to help identify out-of-bound and use-
To extend S YZ T RUST to proprietary Trusted OSes, we after-free vulnerabilities. We integrate TEEKASAN with
augment the syscall templates and the API declarations in lightweight compiler instrumentation and develop shadow
our designed TA and test harness with the new version memory checking for bug triaging on the open source
of these customized APIs. This can be done by referring Trusted OSes. Since TEEKASAN only analyzed a small
to the API documents provided by IoT vendors, which is number of vulnerabilities due to the limitation of the instru-
simple and requires minimum effort. To enable the state- mentation tool and most Trusted OSes are closed-source, we
aware feature, we need expert analysis of the state-related manually triage the remaining vulnerabilities.

8
  
Power interface

USB
interface
MCU
(connected to 
computer)



7LPHPV

SWD/ETM
interface 
Debug
probe



5HVHW 7UDQVIHU ([HFXWLRQ &RY&DOF
Figure 5: S YZ T RUST setup in fuzzing a target TEE imple-
Figure 6: Overhead breakdown of S YZ T RUST.
mentation on the Nuvoton M2351 board. The debug probe
accesses memory and tracks instruction traces on the MCU
via the SWD/ETM interface. It also delivers data to the PC Experiment settings. We perform our evaluation under
and receives commands from the PC via a USB interface. the same experiment settings: a personal computer with
3.20GHz i7-8700 CPU, 32GB RAM, Python 3.8.2, Go
version 1.14, and Windows 10.
6. Evaluation Evaluation metrics. We evaluate S YZ T RUST with the fol-
lowing three aspects. (1) We measure the branch coverage to
In this section, we comprehensively evaluate the evaluate the capability of exploring codes, which is widely
S YZ T RUST, demonstrating its effectiveness in fuzzing IoT used in recent research [15] [32]. The branch calculation is
Trusted OSes. First, we evaluate the overhead breakdown introduced in Section 4.3. (2) To evaluate the capability of
of S YZ T RUST. Second, we conduct experiments explor- exploring the deep state, we measure the state coverage and
ing the effectiveness of our designs. Third, we examine the syscall sequence length of each fuzzer. Specifically, we
S YZ T RUST’s state variable inference capabilities. Finally, consider the value combinations of state variables as a state
we apply S YZ T RUST on fuzzing three real-world IoT and measure the number of different states. (3) We count the
Trusted OSes and introduce their vulnerabilities. In sum- number of unique vulnerabilities. S YZ T RUST relies on the
mary, we aim to answer the following research questions: built-in exception handling mechanism to detect abnormal
RQ1: What is the overhead breakdown of S YZ T RUST? behaviors of Trusted OSes. We explore the dedicated fault
(Section 6.2) status registers [5] to identify the HardFault exception in
RQ2: Is S YZ T RUST effective for fuzzing IoT Trusted OSes? concerns. These exceptions indicate critical system errors
(Section 6.3) and thus can be used as a crash signal [22]. For the crashes,
RQ3: Is the state variable inference method effective, and we reproduce them and report their stack traces by CmBack-
are the inferred state variables expressive? (Section 6.4) Trace to track and locate error codes. We filter stack traces
RQ4: How vulnerable are the real-world Trusted OSes into unique function call sequences to collect the explored
from different IoT vendors from S YZ T RUST’s results? (Sec- unique bugs on target programs, which are widely used for
tion 6.5) deduplication in the CVE dataset [1] and debugging for
vendors. Following best practices, we extract the top three
6.1. Experimental Setup function calls in the stack traces to de-duplicate bugs [36],
[38]. We then analyze the root cause of the bugs manually.
Target Trusted OSes. We evaluate S YZ T RUST on three State transition analysis. We further develop a script to
Trusted OSes designed for IoT devices, mTower, TinyTEE, automatically construct a state transition tree, which helps
and Link TEE Air. The reason for selecting these targets is visually understand the practical meaning of the state vari-
as follows. mTower and TinyTEE both provide the standard ables. Specifically, we utilize the state hashes calculated
APIs following the GP TEE Internal Core API specification. based on state variables to present the states of Trusted OSes
In addition, they are developed by two leading IoT vendors, and take the syscall sequences as state transition labels.
Samsung and Tsinglink Cloud (which serve more than 30
downstream IoT manufacturers, including China TELECON 6.2. Overhead Breakdown (RQ1)
and Panasonic), respectively. Link TEE Air is a proprietary
Trusted OSes developed by Ali Cloud for S YZ T RUST to We measure the execution time of sub-processes of
evaluate its built-in support of closed-source and proprietary S YZ T RUST to assess its impact on the overall overhead. For
Trusted OSes. Moreover, the three targets have been adopted each fuzzing round, S YZ T RUST performs the following sub-
in a number of IoT devices and their security vulnerabilities processes: (1) Reset means the time spent on the MCU re-
have a practical impact. In this paper, we evaluate mTower setting. (2) Transfer means the time spent on the manager
v0.3.0, TinyTEE v3.0.1, Link TEE Air v2.0.0, and each of engine sending the test case. (3) Execution means the
them is the latest version during our experiments. time spent on the execution engine executing the test case. In

9
the meanwhile, the debug probe records the raw instruction TABLE 1: The unique vulnerabilities found by
trace packets and state variable values and transfers them S YZKALLER, S YZ T RUST BASIC, S YZ T RUST S TATE,
to the PC via RTT. (4) CovCalc means the time spent on and S YZ T RUST FS TATE in 48 hours. The vulnerabilities
the hardware-assisted controller decoding the collected raw whose IDs are marked with * have already received CVEs.
trace packets and calculating the branch coverage. In the Vul. ID Syzkaller-Baseline SyzTrust-Basic SyzTrust-State SyzTrust-FState
meanwhile, the hardware-assisted controller calculates the 1*
2*
state hashes based on the state variable values. We only 3
evaluate the sub-processes that are related to interacting 4
5*
with the resource-limited MCU, which mainly determines 6
the speed of S YZ T RUST. As introduced in Section 4.3, the 7*
8*
subprocesses of Transfer, Execution, and CovCalc 9*
10
are designed to run in parallel. 11
The results are shown in Figure 6, from which we 12*
13*
have the following conclusions. First, the overheads of 14*
Reset, Transfer, and CovCalc in S YZ T RUST are 15*
16
relatively low. Thus, using Reset to mitigate the false 17
18
positive coverage and vulnerabilities is acceptable. Second, 19
Execution takes the most time. Test cases for IoT Trusted 20
21
OSes include 14.4 syscalls on average and are complex. In 22
addition, for Execution, the Nuvoton M2351 board used 23
24
in our manuscript has no Embedded Trace Buffer (ETB), 25
26
S YZ T RUST utilizes the debug probe to stream all the ETM 27
trace data to the host PC in real time. We conducted a 48- 28
29
hour fuzzing and found the peak tracing speed is 168 KB/s, 30
and 92% of the trace files for single syscalls are smaller 31
32
than 2KB. In conclusion, the ETM tracing takes less time 33
34
than the syscall execution. 35
36
RQ1: It takes S YZ T RUST 6,290 ms on average to com- 37
38
plete a test case and to collect its feedback. The sub- Total 26 28 31 35
process of executing a test case on the MCU takes the
most time, while the orchestration and analysis take only
roughly 1% of the overall time. them, S YZ T RUST BASIC archives the highest code cov-
erage among the four fuzzers with 1,983 branches, which
6.3. Effectiveness of S YZ T RUST (RQ2) shows the effectiveness of our new scheduling tasks and the
extended syscall templates. When state coverage feedback
In this section, we evaluate S YZKALLER, is integrated into S YZ T RUST, the branch coverage explored
S YZ T RUST BASIC, S YZ T RUST S TATE, and by the S YZ T RUST S TATE and S YZ T RUST FS TATE is lower
S YZ T RUST FS TATE on mTower to explore the effectiveness than S YZ T RUST BASIC. It is because their adopted com-
of our designs, with each experiment running for 48 hours. posite feedback mechanisms drive them to preserve more
To measure our new scheduling tasks and composite seeds that trigger new states, which might have no con-
feedback mechanism, we construct two prototypes of tribution to the code coverage. Given the same evaluation
S YZ T RUST only with the new scheduling tasks and time, a certain percentage of time is assigned to mutating
only with the composite feedback mechanism, which and testing such seeds that trigger new states, and the code
are named S YZ T RUST BASIC and S YZ T RUST FS TATE, coverage growth will result in slower growth. Thus, we
respectively. In addition, to measure the necessity of our additionally perform a long-time fuzzing experiment, and
state variable inference, we construct a prototype that the result shows that S YZ T RUST FS TATE can achieve 1,984
considers the complete buffer values of two state handles branches in 74 hours.
as state variables named S YZ T RUST S TATE. We evaluate Among the four fuzzers, S YZ T RUST FS TATE trig-
three prototypes of S YZ T RUST against the state-of-the-art gers the most states with 2,132 states on average, and
fuzzer S YZKALLER, which has found a large number of S YZKALLER triggers the least states with 284 states on
vulnerabilities on several kernels and is actively maintained. average shown in Figure 7b. S YZ T RUST S TATE has similar
To reduce the randomness, we repeat all experiments ten performances on the state growth with S YZ T RUST BASIC.
times. The results are shown in Figure 7 and Table 1. It is because S YZ T RUST S TATE spends lots of time ex-
Branch coverage is calculated in terms of LCSAJ ba- ploring the test cases that trigger new values of non-state
sic block number introduced in Section 4.3. S YZKALLER variables since S YZ T RUST S TATE utilizes the two whole
triggers 1,191 branches on average and is exceeded by all handles’ values to present state. To further illustrate this
three versions of S YZ T RUST shown in Figure 7. Among deduction, we present Figure 7c, where we calculate the

10
 6\]7UXVWB)6WDWH 6\]7UXVWB)6WDWH
 6\]7UXVWB6WDWH  6\]7UXVWB6WDWH 

 6\]7UXVWB%DVLF  6\]7UXVWB%DVLF
 6\]NDOOHUB%DVHOLQH 6\]NDOOHUB%DVHOLQH
 


  
 
6\]7UXVWB)6WDWH  6\]7UXVWB)6WDWH
 6\]7UXVWB6WDWH  6\]7UXVWB6WDWH
 
 6\]7UXVWB%DVLF 6\]7UXVWB%DVLF
 6\]NDOOHUB%DVHOLQH    6\]NDOOHUB%DVHOLQH
                                                   
(a) Branch coverage. (b) States (based on variables). (c) States (based on handles). (d) Unique vulnerabilities.
Figure 7: The branch coverage growth, state numbers growth, and unique vulnerability growth discovered by S YZKALLER,
S YZ T RUST BASIC, S YZ T RUST S TATE, and S YZ T RUST FS TATE.

growth of the states based on the whole handle values. In TABLE 2: The number of state variables inferred by
such settings, S YZ T RUST S TATE triggers more states than S YZ T RUST. False postive is denoted as FP.
S YZ T RUST BASIC and S YZKALLER. However, these states Target Handle Number FP Precision
are not expressive and effective for guiding the fuzzer to T EE ObjectHandle 11 1
trigger more branch coverage and vulnerabilities. mTower 87.5%
T EE OperationHandle 13 2
T EE ObjectHandle 13 3
TinyTEE 82.6%
T EE OperationHandle 10 1
The exploration space of unique vulnerabilities trig-
T EE ObjectHandle 10 1
gered by S YZKALLER with 16 vulnerabilities on aver- OP-TEE 87.0%
T EE OperationHandle 13 2
age is fully covered and exceeded by the three ver-
sions of S YZ T RUST shown in Figure 7. Among them, context(AES) 6 2
Link TEE Air 71.4%
S YZ T RUST FS TATE detects 21 vulnerabilities on average, context(Hash) 8 2
which achieves the best vulnerability-finding capability.
S YZ T RUST S TATE has similar performances on vulnerabil-
ity detection with S YZ T RUST BASIC and they detect 20 RQ2: The design of S YZ T RUST is effective as the three
vulnerabilities on average. versions of S YZ T RUST outperform S YZKALLER in terms
of code and state coverage and number of detected vul-
nerabilities. New task scheduling with extended syscall
In addition, Table 1 shows the unique vulnerabili- templates significantly improves the fuzzer’s code ex-
ties detected by S YZKALLER and the three versions of ploration, and the composite feedback mechanism helps
S YZ T RUST in ten trials during 48 hours. The vulnera- trigger more states and detect more vulnerabilities.
bility ID in Table 1 is consistent with Table 6 in Ap-
pendix C. First, S YZ T RUST finds all the unique vulnerabil- 6.4. State Variable Inference (RQ3)
ities that S YZKALLER finds. Using the currently assigned
CVE as ground truth, S YZ T RUST detected more CVEs As for state variable inference evaluation, we first eval-
than S YZKALLER. Second, S YZ T RUST FS TATE finds the uate the precision of our state variable inference method.
most vulnerabilities and finds eight vulnerabilities that Second, we utilize the executed syscall sequences and their
S YZKALLER and S YZ T RUST BASIC cannot find. The eight state hashes to construct a state transition tree and present an
vulnerabilities are all triggered by syscall sequences whose example to show the expressiveness of our state variables.
lengths are more than 10, which indicates they are triggered For the precision evaluation, we manually analyze the
in a deep state. For instance, the vulnerability of ID 7 usage of the inferred state variables in the Trusted OSes.
occurs when the Trusted OS enters the key set&initialized We check if a state variable is used in condition statements
state after a MAC function is configured and the function to control the execution context. As for mTower and OP-
T EE M ACU pdate is invoked with an excessive size value TEE, we obtain their source codes and manually read the
of ”chunkSize”. S YZ T RUST FS TATE can detect more vul- state variable-related codes. As for TinyTEE and Link TEE
nerabilities, which is benefited from our composite feedback Air, we invite five experts with software reverse engineering
mechanism. Specifically, the fuzzer preserves the seeds that experiences to manually analyze their binary codes.
trigger new states and then can detect more vulnerabili- Table 2 shows the results. For Trusted OSes, including
ties by exploring these seeds. In summary, this evaluation a proprietary one, our active state variable inference method
reveals two observations. First, although coverage-based is effective and achieves 83.3% precision on average. These
fuzzer achieves high coverage effectively, their vulnerability validated state variables are expressive and meaningful,
detection capability will be limited when testing stateful including algorithm, operationClass (description
systems. Second, for stateful systems, understanding their identifier of operation types, e.g., CIPHER, MAC), mode
internal states and utilizing the state feedback to guide (description identifier of operation, e.g., ENCRYPT, SIGN),
fuzzing will be effective in finding more vulnerabilities. and handleState (describing the current state of the

11
 TEE_PopulateTransientObject TABLE 3: The number of unique vulnerabilities, branches
start 5 4 and states found by S YZ T RUST in 90 hours.
TEE_ResetOperation,
TEE_AllocateOperation TEE_InitRefAttribute,
TEE_SetOperationKey,
TEE_ResetTransientObject
TEE_CipherInit
Target Unique bugs Branches States
1 4 6 TEE_CipherUpdate mTower 38 2,105 3,994
TinyTEE 13 1,072 2,908
TEE_AllocateTransientObject TEE_SetOperationKey TEE_FreeOperation Link TEE Air 19 10,710 182,324

2 3 7
TEE_InitRefAttribute, TEE_PopulateTransientObject 6.5. Real World Trusted OSes (RQ4)
Figure 8: An example of state transition path from the
constructed state transition tree in mTower. We apply S YZ T RUST on mTower from Samsung, Tiny-
TEE from Tsinglink Cloud, and Link TEE Air for 90
hours. The results are shown in Table 3. The branch and
operation, e.g., an operation key has been set). The false state coverage explored by S YZ T RUST on Link TEE Air is
positive state variables are of two types. One is some relatively low because Link TEE Air has a more complicated
variables that indicate the length of several specific buffers, and large code base. As for vulnerability detection, a total
e.g., digest length, and have specific values. Another type of 70 vulnerabilities are found by S YZ T RUST, and 28 of
is several buffers that do not likely have changeable values. them are confirmed, while vendors are still investigating
Both of them generate a few false positive new states and the remaining bug reports. We have reported confirmed
have little impact on the fuzzing procedure. vulnerabilities to MITRE, and 10 of them have already been
assigned CVEs.
To evaluate state variables’ expressiveness, we construct
a state transition tree to help visualize their practical We categorize vulnerabilities into seven types following
meanings. As shown in Figure 8, we present an example the Common Weakness Enumeration (CWE) List [24] and
state transition path from our constructed state transition we have the following conclusions. First, the Trusted OSes
tree. We replace the state hashes with numerical values suffer from frequent null/untrusted pointer dereference vul-
in the node label to enhance the readability. Below is nerabilities. They lack code for validating supplied input
the meaning of the example state transition tree. First, pointers. When a TA tries to read or write a malformed
TEE_OperationHandle and TEE_ObjectHandle pointer by invoking Trusted OS syscalls, a crash will be
are allocated by TEE_AllocateOperation and triggered, resulting in a DoS attack. Even worse, care-
TEE_AllocateTriansientObject, respectively. fully designed pointers provided by a TA to the syscall
Once a handle is allocated, the state transition is can compromise the integrity of the execution context and
triggered. Second, TEE_ObjectHandle loads a dummy lead to arbitrary code execution, posing a significant risk.
key by executing TEE_InitRefAttribute and The problem is severe since Trusted OSes frequently rely
TEE_PopulateTransientObject. The dummy on pointers to transfer complex data structures, which are
key is then loaded into the TEE_OperationHandle used in cryptographic operations. Second, the Trusted OSes
by TEE_SetOperationKey. Then state node 4 is allocate resources without checking bounds. They allow
triggered, indicating mTower is in the key_set state, a TA to achieve excessive memory allocation via a large
which is consistent with the GP TEE Internal Core API len value. Since the IoT TEEs are resource-limited, these
specification. Third, TEE_ObjectHandle is reset and vulnerabilities may easily cause denial of service. Third,
TEE_OperationHandle loads an encryption key by the Trusted OSes suffer from buffer overflow vulnerabilities.
executing the same syscalls of the second procedure with They missed checks for buffer accesses with incorrect length
a valid key. Fourth, mTower turns to a new state after values and allowed a TA to trigger a memory overwriting,
TEE_CipherInit, which is specified as key_set & DoS, and information disclosure. We discuss the mitigation
initialized state in the specification. This state means in Section 7 and list the vulnerabilities with their root cause
that mTower loads the key and the initialization vector analysis found on mTower and TinyTEE in Table 6 in
for encryption. When mTower is in the key_set & Appendix C.
initialized, mTower processes the ciphering operation Case study 1: buffer overflow (CVE-2022-35858).
on provided buffers by TEE_CipherUpdate. Finally, S YZ T RUST identifies a stack-based buffer overflow
mTower turns to a new state after it frees all the encryption vulnerability in TEE_PopulateTransientObject
configurations by TEE_FreeOperation. As a result, syscall in mTower, which has 7.8 CVSS Score
our state presentation mechanism truthfully reflects the according to CVE Details [3]. Specifically, the
workflow of symmetric encryption. TEE_PopulateTransientObject syscall
creates a local array directly using the parameter
RQ3: On average, our active state variable inference attrCount without checking its size. Once
method is effective and achieves 83.3% precision on TEE_PopulateTransientObject is invoked with a
average. In addition, from the state transition tree, the large number in attrCount, a memory overwrite will be
inferred state variables are meaningful. triggered, resulting in Denial-of-Service (DoS), information
leakage, and arbitrary code execution.

12
 Case study 2: null pointer dereference (CVE-2022- lightweight Trusted OS implementations should be designed
40759). S YZ T RUST uncovers a null pointer dereference in to minimize the overhead brought by security mechanisms.
TEE_MACCompareFinal in mTower. A DoS attack can Limitations and future work. While S YZ T RUST pro-
be triggered by invoking TEE_MACCompareFinal with vides an effective way to fuzz IoT Trusted OSes, it also
a null pointer for the parameter operation. This bug is hard exposes some opportunities for future research. First, our
to trigger by traditional fuzzing, as it requires testing on a current prototype of S YZ T RUST primarily targets Trusted
specific syscall sequence to enter a specific state. S YZ T RUST OSes following GP TEE Internal Core API specification. It
can effectively identify such syscall sequences that trigger has built-in support for alternative Trusted OSes, including
new states and prioritize testing them. In this way, this proprietary ones, requiring certain modifications and con-
syscall sequence can be fuzzed to cause a null pointer figurations. We demonstrated this flexibility by extending
dereference vulnerability; otherwise, it will be discarded. to a proprietary Trusted OS and plan to extend SyzTrust
for broader applicability. Second, S YZ T RUST assumes that
RQ4: mTower, TinyTEE and Link TEE Air are all a TA can be installed in the Trusted OS for assisting fuzzing
vulnerable. S YZ T RUST identifies 38 vulnerabilities on and ARM ETM is enabled for collecting the traces. In the
mTower, 13 vulnerabilities on TinyTEE, and 19 vulner- case of certain Trusted OSes, such as ISEE-M, which are
abilities on Link TEE Air, resulting in 10 CVEs. developed and used within a relatively tight supply chain,
we will need to engage with the providers of these Trusted
OSes to help assess the security of their respective Trusted
7. Discussion OSes. Finally, S YZ T RUST targets the Trusted OS of TEE,
leaving several security aspects of TEEs to be studied, e.g.,
Ethic. We pay special attention to the potential ethical is- TAs and the interaction mechanism between peripherals and
sues in this work. First, we obtain all the tested Trusted OSes the Trusted OSes.
from legitimate sources. Second, we have made responsible
disclosure to report all vulnerabilities to IoT vendors. 8. Related Work
Lessons. Based on our evaluations, we provide several
security insights about the existing popular IoT Trusted TEE vulnerability detection. Several researchers have
OSes. First, mTower and TinyTEE are similar to OP-TEE, studied and exploited vulnerabilities in TrustZone-based
an open-source TEE implementation designed for Cortex- TEEs. Marcel et al. reverse-engineer HUAWEI’s TEE com-
A series MCUs, and they have several similar vulnerabili- ponents and present a critical security review [16]. Some
ties. For instance, they both implement vulnerable syscalls researchers studied the design vulnerabilities of TEE com-
TEE_Malloc and TEE_Realloc, which allow an exces- ponents [56], [67], such as Samsung’s TrustZone keymaster
sive memory allocation via a large value. In a resource- [58] and the interaction between the secure world and the
constrained MCU, such implementations can cause a crash normal world [43]. Recently, Cerdeira et al. analyzed more
and result in a DoS attack. Thus, the security principles than 200 bugs in TrustZone-assisted TEEs and presented a
should be rethought to meet the requirements of the IoT systematic view [17]. Since those works require manual ef-
scenario. As a mitigation, we suggest adding checks when forts for vulnerability detection or only provide an automatic
allocating memory; this suggestion is adopted by Samsung tool to target a specific vulnerability, some literature works
and TsingLink Cloud. Second, for the null/untrusted pointer on automatically testing the TEEs. Some works try to apply
dereference and buffer overflow vulnerabilities, the input other analysis tools, e.g., utilizing concolic execution [14]
pointers and critical parameters should be especially care- and fuzzing. A number of TA fuzzing tools are developed,
fully checked. For the untrusted pointer dereferences on such as TEEzz [15], PartEmu [32], Andrey’s work [4] and
handlers, in addition to checking if the pointer address is Slava’s work [44]. On the contrary, Trusted OS fuzzing
valid, we suggested adding a handler list to mark if they are receives little attention. To the best of our knowledge, the
allocated or released. Third, we found mTower and TinyTEE only tool OP-TEE Fuzzer [55] is for open-source TEEs,
implement several critical syscalls provided by Trusted OS which is not applicable to closed-source IoT TEEs.
in non-privileged codes, which exposes a number of null/un- ETM-based fuzzing. Firmware analysis primarily
trusted pointer dereference vulnerabilities. Thus, a TA can adopts two approaches: on-device testing [40], [41] and
easily reach these syscalls and damage the Trusted OSes. rehosting [19], [51]. For on-device testing, a few ETM-
Even worse, mTower and TinyTEE do not have memory assisted analysis methods have been proposed for ARM
protection mechanisms, such as ASLR (Address Space Lay- platforms [48], [50]. For instance, Ninjia [49] utilizes ETM
out Randomization). Trusted OSes and TAs are all loaded to analyze malware transparently. HApper [65] and NScope
into the same fixed address in the virtual address space. The [69] utilize ETM to unpack Android applications and ana-
above two problems make the exploitation of Trusted OSes lyze the Android native code. Recently, two studies have in-
easier. However, implementing privileged codes and mem- tegrated ETM features into fuzzing projects. One is AFL++
ory protection mechanisms requires additional overhead, CoreSight mode [46], which targets the applications running
which may be unacceptable for IoT devices. We suggest that on ARM Cortex-A platforms. Another is µAFL [37] to
the downstream TA developers should be aware of it and fuzz Linux peripheral drivers. However, these works have
carefully design their TAs to mitigate this security risk, or different purposes. AFL++ CoreSight mode and µAFL focus

13
on the application, whereas S YZ T RUST focuses on Trusted References
OSes for IoT devices and incurs many challenges due to
the constrained resource and inability to instrumentation. [1] “CVE details,” https://www.cvedetails.com.
Moreover, S YZ T RUST proposes a novel fuzzing framework [2] “J-Link RTT - real time transfer,” https://www.segger.com/products/
and the state-aware feature to effectively test the state- debug-probes/j-link/technology/about-real-time-transfer.
ful Trusted OSes. Consequently, S YZ T RUST is a novel [3] “NVD, CVE: Common vulnerabilities and exposures,” https://cve.
hardware-assisted fuzzing approach proposed in this paper. mitre.org/.
State-aware fuzzing. Recently, state-aware fuzzing has [4] A. Andrey, “Launching feedback-driven fuzzing on trustzone tee,”
emerged and gained the attention of the research community. https://zeronights.ru/wp-content/themes/zeronights-2019/public/mat
erials/5 ZN2019 andrej akimovLaunching feedbackdriven fuzzing
To understand the internal states of target systems, existing on TrustZone TEE.pdf.
studies utilize the response code of protocol servers [28],
[5] ARM, “Arm Cortex-M23 Devices Generic User Guide r1p0 -
[52] or apply model learning [23], [63] to identify the Fault Handling,” https://developer.arm.com/documentation/dui1095/
server’s states. StateInspector [45] utilizes explicit proto- a/The-Cortex-M23-Processor/Fault-handling.
col packet sequences and run-time memory to infer the [6] ——, “TF-M platforms,” https://tf-m-user-guide.trustedfirmware.or
server’s state machine. However, they are not applicable to g/platform/index.html.
software and OSes since software and OSes do not have [7] C. Aschermann, S. Schumilo, A. Abbasi, and T. Holz, “Ijon: Explor-
such response codes or packet sequences. IJON [7] proposes ing deep state spaces via fuzzing,” in Proceedings of IEEE Symposium
an annotation mechanism that allows the user to infer the on Security and Privacy (S&P), 2020.
states during the fuzzing procedure manually. After that, [8] N. Asokan, T. Nyman, N. Rattanavipanon, A.-R. Sadeghi, and
numbers of studies work on automatically inferring the state G. Tsudik, “ASSURED: Architecture for secure software update of
of software and OSes [26], [47], [62], such as StateFuzz realistic embedded devices,” IEEE Transactions on Computer-Aided
Design of Integrated Circuits and Systems, vol. 37, no. 11, pp. 2290–
[68], SGFUZZ [9], and FUZZUSB [35]. However, these 2300, 2018.
studies either require the source codes of targets or precise [9] J. Ba, M. Böhme, Z. Mirzamomen, and A. Roychoudhury, “Stateful
dynamic instrumentation tools. Even worse, their targets are greybox fuzzing,” in Proceedings of USENIX Security Symposium
Linux kernels, protocols, and drivers, and their intuitions and (SEC), 2022.
observations are not suitable for IoT Trusted OSes. [10] Beanpod, “ISEE trusted execution environment platform (Secure
OS),” https://www.beanpodtech.com/en/products/.
[11] G. Beniamini, “Extracting Qualcomm’s keymaster keys - breaking
9. Conclusion android full disk encryption,” https://bits-please.blogspot.com/2016/
06/extracting-qualcomms-keymaster-keys.html.
We present S YZ T RUST, the first automated and practical [12] ——, “Hijacking the linux kernel from QSEE,” https://bits-please.bl
fuzzing system to fuzz Trusted OSes for IoT devices. We ogspot.com/2016/05/war-of-worlds-hijacking-linux-kernel.html.
evaluate the effectiveness of the S YZ T RUST on the Nuvoton [13] ——, “TrustZone kernel privilege escalation,” http://bits-please.blog
M2351 board with a Cortex M23, and the results show spot.com/2016/06/trustzone-kernel-privilege-escalation.html.
S YZ T RUST outperforms the baseline fuzzer S YZKALLER [14] M. Busch and K. Dirsch, “Finding 1-day vulnerabilities in trusted
with 66% higher code coverage, 651% higher state cover- applications using selective symbolic execution,” in Proceedings of
the 27th Annual Network and Distributed System Security Symposium
age, and 31% improved vulnerability-finding capability. Fur- (NDSS), San Diego, CA, USA, 2020.
thermore, we apply S YZ T RUST to evaluate real-world IoT
[15] M. Busch, A. Machiry, C. Spensky, G. Vigna, C. Kruegel, and
Trusted OSes from three leading IoT vendors and detect 70 M. Payer, “TEEzz: Fuzzing Trusted Applications on COTS Android
previously unknown vulnerabilities with security impacts. devices,” in Proceedings of IEEE Symposium on Security and Privacy
In addition, we present the understanding of Trusted OS (S&P), 2023.
vulnerabilities and discuss the limitation and future work. [16] M. Busch, J. Westphal, and T. Mueller, “Unearthing the TrustedCore:
We believe S YZ T RUST provides developers with a powerful A critical review on Huawei’s trusted execution environment,” in
tool to thwart TEE-related vulnerabilities within modern IoT Proceedings of 14th USENIX Workshop on Offensive Technologies
(WOOT 20), 2020.
devices and complete the current TEE fuzzing scope.
[17] D. Cerdeira, N. Santos, P. Fonseca, and S. Pinto, “Sok: Understanding
the prevailing security vulnerabilities in trustzone-assisted tee sys-
tems,” in Proceedings of IEEE Symposium on Security and Privacy
Acknowledgments (S&P), 2020.
[18] Y. Chen, D. Mu, J. Xu, Z. Sun, W. Shen, X. Xing, L. Lu, and
We sincerely appreciate our shepherd and all the anony- B. Mao, “Ptrix: Efficient hardware-assisted fuzzing for cots binary,”
mous reviewers for their insightful comments. This work in Proceedings of the 2019 ACM Asia Conference on Computer and
was partly supported by NSFC under No. U1936215, the Communications Security, 2019, pp. 633–645.
State Key Laboratory of Computer Architecture (ICT, CAS) [19] A. A. Clements, E. Gustafson, T. Scharnowski, P. Grosen, D. Fritz,
C. Kruegel, G. Vigna, S. Bagchi, and M. Payer, “{HALucinator}:
under Grant No. CARCHA202001, the Fundamental Re- Firmware re-hosting through abstraction layer emulation,” in 29th
search Funds for the Central Universities (Zhejiang Univer- USENIX Security Symposium (USENIX Security 20), 2020, pp. 1201–
sity NGICS Platform), SNSF PCEGP2 186974, ERC StG 1218.
850868, Google Scholar Award, Meta Faculty Award, and [20] A. Cloud, “About Alibaba Cloud Link TEE,” https://iot.aliyun.com
China Scholarship Council. /products/tee.

14
[21] P. Cohen, “Winbond partners with Nuvoton, Qinglianyun to release [41] P. Liu, S. Ji, X. Zhang, Q. Dai, K. Lu, L. Fu, W. Chen, P. Cheng,
fully integrated reference design for OTA firmware updating),” W. Wang, and R. Beyah, “IFIZZ: Deep-state and efficient fault-
https://embeddedcomputing.com/technology/iot/winbond-partners-w scenario generation to test IoT firmware,” in 2021 36th IEEE/ACM
ith-nuvoton-qinglianyun-to-release-fully-integrated-reference-desig International Conference on Automated Software Engineering (ASE).
n-for-ota-firmware-updating. IEEE, 2021, pp. 805–816.
[22] A. Community, “Cortex-M23 and Cortex-M33 - security foundation [42] L. Luo, Y. Zhang, C. Zou, X. Shao, Z. Ling, and X. Fu, “On runtime
for billions of devices,” https://community.arm.com/arm-communi software security of trustzone-m based iot devices,” in Proceedings of
ty-blogs/b/architectures-and-processors-blog/posts/cortex-m23-and-c GLOBECOM 2020-2020 IEEE Global Communications Conference,
ortex-m33---security-foundation-for-billions-of-devices. 2020.
[23] P. M. Comparetti, G. Wondracek, C. Kruegel, and E. Kirda, “Prospex: [43] A. Machiry, E. Gustafson, C. Spensky, C. Salls, N. Stephens,
Protocol specification extraction,” in Proceedings of IEEE Symposium R. Wang, A. Bianchi, Y. R. Choe, C. Kruegel, and G. Vigna,
on Security and Privacy (S&P), 2009. “BOOMERANG: Exploiting the semantic gap in trusted execution
[24] CWE, “CWE list version 4.9,” https://cwe.mitre.org/data/index.html. environments.” in Proceedings of Network and Distributed System
Security Symposium (NDSS), 2017.
[25] A. Developer, “ARM coresight architecture specification version 3.0,”
https://developer.arm.com/documentation/ihi0029/e. [44] S. Makkaveev, “The road to Qualcomm TrustZone apps fuzzing,”
https://research.checkpoint.com/2019/the-road-to-qualcomm-trustzo
[26] A. Fioraldi, D. C. D’Elia, and D. Balzarotti, “The use of likely in- ne-apps-fuzzing.
variants as feedback for fuzzers,” in Proceedings of USENIX Security
Symposium (SEC), 2021. [45] C. McMahon Stone, S. L. Thomas, M. Vanhoef, J. Henderson,
N. Bailluet, and T. Chothia, “The closer you look, the more you
[27] A. Fitzek, F. Achleitner, J. Winter, and D. Hein, “The ANDIX learn: A grey-box approach to protocol state machine learning,” in
research OS—ARM TrustZone meets industrial control systems se- Proceedings of the 2022 ACM SIGSAC Conference on Computer and
curity,” in Proceedings of IEEE 13th International Conference on Communications Security, 2022, pp. 2265–2278.
Industrial Informatics (INDIN), 2015.
[46] A. Moroo and S. Yuichi, “ARMored core-
[28] H. Gascon, C. Wressnegger, F. Yamaguchi, D. Arp, and K. Rieck,
sight: Towards efficient binary-only fuzzing,”
“Pulsar: Stateful black-box fuzzing of proprietary network protocols,”
https://ricercasecurity.blogspot.com/2021/11/armored-coresight-
in International Conference on Security and Privacy in Communica-
towards-efficient.html, November 2021.
tion Systems, 2015.
[47] R. Natella, “Stateafl: Greybox fuzzing for stateful network servers,”
[29] GlobalPlatform, “GlobalPlatform TEE spec adoption to reach 10
Empirical Software Engineering, vol. 27, no. 7, pp. 1–31, 2022.
billion,” https://globalplatform.org/latest-news/globalplatform-tee-s
pec-adoption-to-reach-10-billion. [48] Z. Ning, C. Wang, Y. Chen, F. Zhang, and J. Cao, “Revisiting arm
[30] ——, “TEE Internal Core API Specification v1.3.1,” https://globalpl debugging features: Nailgun and its defense,” IEEE Transactions on
atform.org/specs-library/tee-internal-core-api-specification. Dependable and Secure Computing, 2021.

[31] Google, “syzkaller - kernel fuzzer,” https://github.com/google/syzk [49] Z. Ning and F. Zhang, “Ninja: Towards transparent tracing and
aller. debugging on ARM,” in Proceedings of USENIX Security Symposium
(SEC), 2017.
[32] L. Harrison, H. Vijayakumar, R. Padhye, K. Sen, and M. Grace,
“PARTEMU: Enabling dynamic analysis of real-world TrustZone [50] ——, “Understanding the security of arm debugging features,” in
software using emulation,” in Proceedings of USENIX Security Sym- Proceedings of IEEE Symposium on Security and Privacy (S&P),
posium (SEC), 2020. 2019.
[33] Z. Hua, J. Gu, Y. Xia, H. Chen, B. Zang, and H. Guan, “vTZ: [51] H. Peng and M. Payer, “{USBFuzz}: A framework for fuzzing
Virtualizing ARM TrustZone,” in Proceedings of USENIX Security {USB} drivers by device emulation,” in 29th USENIX Security Sym-
Symposium (SEC), 2017. posium (USENIX Security 20), 2020, pp. 2559–2575.
[34] T. L. Kernel, “The kernel address sanitizer (KASAN),” https://www. [52] V.-T. Pham, M. Böhme, and A. Roychoudhury, “AFLNet: a greybox
kernel.org/doc/html/v5.0/dev-tools/kasan.html. fuzzer for network protocols,” in 2020 IEEE 13th International
Conference on Software Testing, Validation and Verification (ICST).
[35] K. Kim, T. Kim, E. Warraich, B. Lee, K. R. Butler, A. Bianchi,
IEEE, 2020, pp. 460–465.
and D. J. Tian, “FUZZUSB: Hybrid stateful fuzzing of USB gadget
stacks,” in Proceedings of IEEE Symposium on Security and Privacy [53] S. Pinto, T. Gomes, J. Pereira, J. Cabral, and A. Tavares, “IIoTEED:
(S&P), 2022. An enhanced, trusted execution environment for industrial IoT edge
[36] G. Klees, A. Ruef, B. Cooper, S. Wei, and M. Hicks, “Evaluating devices,” IEEE Internet Computing, vol. 21, no. 1, pp. 40–47, 2017.
fuzz testing,” in Proceedings of the 2018 ACM SIGSAC conference [54] S. Pinto and N. Santos, “Demystifying arm trustzone: A comprehen-
on computer and communications security, 2018, pp. 2123–2138. sive survey,” ACM computing surveys (CSUR), vol. 51, no. 6, pp.
[37] W. Li, J. Shi, F. Li, J. Lin, W. Wang, and L. Guan, “µAFL: Non- 1–36, 2019.
intrusive feedback-driven fuzzing for microcontroller firmware,” in [55] Riscure, “OP-TEE fuzzer,” https://github.com/Riscure/optee fuzzer.
2022 IEEE/ACM 44th International Conference on Software Engi-
neering (ICSE), 2022. [56] K. Ryan, “Hardware-backed heist: Extracting ECDSA keys from
qualcomm’s trustzone,” in Proceedings of the ACM SIGSAC Con-
[38] Y. Li, S. Ji, Y. Chen, S. Liang, W.-H. Lee, Y. Chen, C. Lyu, C. Wu, ference on Computer and Communications Security, 2019.
R. Beyah, P. Cheng et al., “UNIFUZZ: A holistic and pragmatic
metrics-driven platform for evaluating fuzzers.” in USENIX Security [57] Samsung, “mTower,” https://github.com/Samsung/mTower.
Symposium, 2021, pp. 2777–2794. [58] A. Shakevsky, E. Ronen, and A. Wool, “Trust dies in darkness: Shed-
[39] Linaro, “Open portable trusted execution environment,” https://ww ding light on samsung’s TrustZone keymaster design,” in Proceedings
w.op-tee.org. of USENIX Security Symposium (SEC), 2022.
[40] P. Liu, S. Ji, L. Fu, K. Lu, X. Zhang, J. Qin, W. Wang, and W. Chen, [59] E. Styger, “Finding memory bugs with Google address sanitizer
“How iot re-using threatens your sensitive data: Exploring the user- (ASAN) on microcontrollers,” https://mcuoneclipse.com/2021/05/
data disposal in used IoT devices,” in 2023 IEEE Symposium on 31/finding-memory-bugs-with-google-address-sanitizer-asan-on-mic
Security and Privacy (SP). IEEE, 2023, pp. 3365–3381. rocontrollers.

15
[60] Trustonic, “Mircochip first to use Turstonic revolutionary Kinibi-M

platform for microcontrollers,” https://www.sourcesecurity.com/new 7UXVWHG26
/LQX[NHUQHO
s/mircochip-turstonic-kinibi-m-microcontrollers-co-1530084457-g 
.90

a-co-1530085342-ga-npr.1530086842.html.
[61] TsinglinkCloud, “Qinglian Cloud’s TinyTEE,” https://www.qinglian

5DWLR


yun.com/Front/Secure/safe.


[62] H. Wang, X. Xie, Y. Li, C. Wen, Y. Li, Y. Liu, S. Qin, H. Chen,
and Y. Sui, “Typestate-guided fuzzer for discovering use-after-free 

vulnerabilities,” in Proceedings of IEEE/ACM 42nd International @ @ @ @ @ @ @ @ @ @ @ @ @
/HQJWKLQWHUYDO
Conference on Software Engineering (ICSE), 2020.
[63] Q. Wang, S. Ji, Y. Tian, X. Zhang, B. Zhao, Y. Kan, Z. Lin, C. Lin, Figure 9: The seed length ratio.
S. Deng, A. X. Liu et al., “MPInspector: A systematic and automatic
approach for evaluating the security of IoT messaging protocols,” in
30th USENIX Security Symposium (USENIX Security 21), 2021, pp. Appendix A.
4205–4222.
The Motivation of the New Scheduling
[64] Wikipedia, “Trusted execution environment,” https://en.wikipedia.o
rg/wiki/Trusted execution environment.
To justify our motivation for the new scheduling tasks
[65] L. Xue, H. Zhou, X. Luo, Y. Zhou, Y. Shi, G. Gu, F. Zhang, design for fuzzing the IoT Trusted OS implementation,
and M. H. Au, “Happer: Unpacking android apps via a hardware-
assisted approach,” in Proceedings of IEEE Symposium on Security we compare the seed length ratio when testing Trusted
and Privacy (S&P), 2021. OSes, Linux kernel and KVM. In the evaluation, we utilize
[66] D. F. Yates and N. Malevris, “The effort required by LCSAJ testing: S YZKALLER to test mTower, Linux kernel (git checkout
an assessment via a new path generation strategy,” Software Quality 356d82172), and KVM v5.19 for 24 hours, and the re-
Journal, vol. 4, no. 3, pp. 227–242, 1995. sults are shown in Figure 9. As shown in Figure 9, the
[67] B. Zhao, S. Ji, X. Zhang, Y. Tian, Q. Wang, Y. Pu, C. Lyv, and average seed length when fuzzing Trusted OSes is 27.8
R. Beyah, “UVSCAN: Detecting third-party component usage vi- while the others are less than 7. In the triage scheduling
olations in IoT firmware,” in 32nd USENIX Security Symposium task, S YZKALLER removes syscalls one by one in a syscall
(USENIX Security 23), 2023.
sequence. Then S YZKALLER tests the modified syscall se-
[68] B. Zhao, Z. Li, S. Qin, Z. Ma, M. Yuan, W. Zhu, Z. Tian, and quences to get the smallest syscall sequence that maintains
C. Zhang, “StateFuzz: System call-based state-aware linux driver
fuzzing,” in Proceedings of USENIX Security Symposium (SEC), the same code coverage. For those syscall sequences whose
2022. length is more than 30, the triage scheduling tasks prob-
[69] H. Zhou, S. Wu, X. Luo, T. Wang, Y. Zhou, C. Zhang, and H. Cai, ably spend lots of time on removing syscalls and testing
“NCScope: hardware-assisted analyzer for native code in android the modified syscall sequences. In addition, we count the
apps,” in Proceedings of the 31st ACM SIGSOFT International Sym- number of minimized syscalls when fuzzing mTower. In a
posium on Software Testing and Analysis, 2022, pp. 629–641. 48-hours fuzzing, only 56 syscall sequences are minimized,
[70] T. Zhu, “CmBacktrace: ARM Cortex-M series MCU error tracking and among them, 18 syscall sequences only are removed
library,” https://github.com/armink/CmBacktrace. with one syscall in the triaging tasks. Thus, S YZ T RUST
doesn’t have to perform triaging tasks since most test cases
will not be minimized.

Appendix B.
Scope and Scalability of S YZ T RUST
We first provide an overview of the major Trusted OSes
from leading IoT vendors and use the objective data to
validate our assumptions. Then, we justify how to extend
S YZ T RUST for Cortex-A TEE OSes.
TABLE 4: An overview of the major Trusted OS implemen-
tations provided by leading IoT vendors.
Support
Vendor Trusted OS Standards Some of supported devices
(installing TA)
Samsung mTower GP Standards NuMaker-PFM-M2351
Alibaba Link TEE Air Proprietary NuMaker-PFM-M2351
TsingLink Cloud TinyTEE GP Standards NuMaker-PFM-M2351/LPC55S69/STM32L562
Beanpod ISEE-M GP Standards LPC55S series/GD32W515/STM32L5 series
Trustonic Kinibi-M PSA Certified APIs MicroChip SAML11
ARM TF-M PSA Certified APIs NuMaker-PFM-M2351, STM32L5, ...

As shown in Table 4, there are six major Trusted OSes

for IoT devices, which are widely adopted by the major IoT
MCUs [6], [10], [20], [21], [57], [60], [61]. Three of them
follow the GP standards, and they all allow TA installation.

16
 TABLE 5: ETM feature on IoT devices. 2) Identifies an Impactful Vulnerability. Several vulnera-
Manufacturer Device
Privilige Secure Debug Debug Authentication bilities were identified, and CVEs are disclosed.
(including ETM) Managerment
Nuvoton NuMaker-PFM-M2351 Enable in default ICP programming tool
3) Provides a Valuable Step Forward in an Established
NXP Semiconductors LPC55S69 Enable in default Debug credential certificate Field. This paper leverages hardware-assisted features
STMicroelectronics STM32L562 Enable in default STM32CubeProgrammer
GigaDevice GD32W515 Enable in default Efuse such as Arm ETM to further improve the effectiveness
MicroChip SAML11 Enable in default Extern debugger
of TEE OS fuzzing on IoT devices.

In addition, as shown in Table 5, though the devices have D.4. Noteworthy Concerns
multiple debug authentication to disable the privilege secure
debug (debug in secure privileged modes), they enable priv- The proposed fuzzing framework targets Trusted OSes
ilege secure debug by default, thereby enabling the ETM following GP TEE internal API specification. It is assumed
feature to collect execution traces. Thus, S YZ T RUST can that a TA can be installed in the trusted OS for assisting
be directly deployed on half of the major Trusted OSes. fuzzing. Arm ETM needs to be enabled for collecting the
As for other Trusted OSes, S YZ T RUST can be applied with traces.
modification introduced in Section 5.
Though our paper focuses on Cortex-M Trusted OS for Appendix E.
IoT devices, S YZ T RUST can be applied to those Trusted Response to the Meta-Review
OSes for Cortex-A that allows installing a TA and having
their ETM feature enabled. For instance, OP-TEE from The meta-review notes that our proposed fuzzing frame-
Linaro, Link TEE Pro from Ali Cloud, and iTrustee from work, SyzTrust, targets trusted OSes following GP TEE
Huawei meet these assumptions. However, for the Cortex-A Internal API specification. To clarify, SyzTrust also has
Trusted OSes that are developed and employed in a rela- built-in support for testing alternative Trusted OSes, includ-
tively private supply chain, such as QSEE from Qualcomm, ing proprietary ones, as demonstrated by our extension of
we can collaborate with those mobile vendors and help them SyzTrust to the proprietary ”Link TEE Air”. We are also
vet the security of their Trusted OSes. extending our SyzTrust prototype to other OSes.
The meta-review notes that SyzTrust assumed that a
Appendix C. TA can be installed in the trusted OS for assisting fuzzing
Vulnerabilites Found by S YZ T RUST and ARM ETM needs to be enabled for collecting the
traces. We agree and note that these assumptions align with
We present all the vulnerabilities found by S YZ T RUST typical IoT Trusted OS scenarios. SyzTrust focuses on the
on mTower, TinyTEE and Link TEE Air with their root Trusted OS binaries provided by IoT vendors, delivering
cause in Table 6. We update the vulnerabilities disclosure security insights for device manufacturers and end users.
progress in the GitHub link https://github.com/SyzTrust. First, given that IoT device manufacturers often need to im-
plement device-specific TAs, Trusted OS binaries supplied
Appendix D. by IoT vendors generally allow TA installation (similar to
Meta-Review smartphones where manufacturers can similarly install TAs
in the respective TEEs). Second, SyzTrust tests IoT Trusted
D.1. Summary OSes by deploying them on development boards where ETM
is enabled by default. For certain Trusted OSes that are
This paper presents a fuzzing framework for TEEs on developed and used within a relatively private supply chain,
IoT devices. It leverages hardware-assisted features such we will need to engage with the providers of these Trusted
as Arm ETM to collect traces. It uses the state and code OSes to help assess the security of their respective Trusted
coverage as composite feedback to guide the fuzzer to OSes. Appendix B provides a detailed discussion along with
effectively explore more states. supporting data.

D.2. Scientific Contributions

• Creates a New Tool to Enable Future Science
• Identifies an Impactful Vulnerability
• Provides a Valuable Step Forward in an Established
Field

D.3. Reasons for Acceptance

1) Creates a New Tool to Enable Future Science. This
paper presents a new fuzzing tool that targets IoT
Trusted OSes.

17
 TABLE 6: Vulnerabilities detected by S YZ T RUST.
Vul. ID Target Description Status Root Cause & Impact
Allocation of resources CVE-2022-38155
1 mTower TEE Malloc allows a TA to achieve excessive memory allocation via a large len value
without limits or throttling (7.5 HIGH)
Allocation of resources CVE-2022-40762
2 mTower TEE Realloc allows a TA to achieve excessive memory allocation via a large len value
without limits or throttling (7.5 HIGH)
Allocation of resources
3 mTower Confirmed TEE AllocateOperation allows a TA to achieve excessive memory allocation via a large len value
without limits or throttling
Allocation of resources
4 mTower Confirmed TEE AllocateTransientObject allows a TA to achieve excessive memory allocation via a large len value
without limits or throttling
CVE-2022-40761 The function tee obj free allows a TA to trigger a denial of service by invoking the function TEE AllocateOperation with a disturbed heap layout, related
5 mTower Improper input validation
(7.5 HIGH) to utee cryp obj alloc
A Buffer Access with Incorrect Length Value vulnerability in the TEE MemMove function allows a TA to trigger a denial of service by invoking the function
6 mTower Buffer overflow Reported
TEE MemMove with a ”size” parameter that exceeds the size of ”dest”.
CVE-2022-40760 A Buffer Access with Incorrect Length Value vulnerability in the TEE MACUpdate function allows a TA to trigger a denial of service by invoking the function
7 mTower Buffer overflow
(7.5 HIGH) TEE MACUpdate with an excessive size value of chunkSize.
CVE-2022-40757 A Buffer Access with Incorrect Length Value vulnerability in the TEE MACComputeFinal function allows a TA to trigger a denial of service by invoking
8 mTower Buffer overflow
(7.5 HIGH) the function TEE MACComputeFinal with an excessive size value of messageLen.
CVE-2022-40758 A Buffer Access with Incorrect Length Value vulnerability in the TEE CipherUpdate function allows a TA to trigger a denial of service by invoking the function
9 mTower Buffer overflow
(7.5 HIGH) TEE CipherUpdate with an excessive size value of srcLen.
A Buffer Access with Incorrect Length Value vulnerability in the TEE DigestDoFinal function allows a TA to trigger a denial of service by invoking the function
10 mTower Buffer overflow Reported
TEE DigestDoFinal with an excessive size value of chunkLen.
A Buffer Access with Incorrect Length Value vulnerability in the TEE DigestUpdate function allows a TA to trigger a denial of service by invoking the function
11 mTower Buffer overflow Reported
TEE DigestUpdate with an excessive size value of chunkLen.
Missing release of memory CVE-2022-35858 The TEE PopulateTransientObject and utee from attr functions allow a TA to trigger a memory overwrite, denial of service, and information disclosure
12 mTower
after effective lifetime (7.8 HIGH) by invoking the function TEE PopulateTransientObject with a large number in the parameter attrCount.
CVE-2022-40759
13 mTower NULL pointer dereference TEE MACCompareFinal contains a NULL pointer dereference on the parameter operation
(7.5 HIGH)
CVE-2022-36621
14 mTower NULL pointer dereference TEE AllocateTransientObject contains a NULL pointer dereference on the parameter object
(7.5 HIGH)
CVE-2022-36622
15 mTower NULL pointer dereference TEE GetObjectInfo1 contains a NULL pointer dereference on the parameter objectInfo
(7.5 HIGH)
16 mTower NULL pointer dereference Confirmed TEE GetObjectInfo contains a NULL pointer dereference on the parameter objectInfo
17 mTower Untrusted pointer dereference Reported Uncertain (provided the PoC to the vendor)
18 mTower Untrusted pointer dereference Reported Uncertain (provided the PoC to the vendor)
TEE GetObjectInfo and utee cryp obj get info functions allow a corruption on the link field of object handle and then a Denial of Service (DoS) will
19 mTower Untrusted pointer dereference Reported
be triggered by invoking the function tee obj get
20 mTower Untrusted pointer dereference Reported An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE MACComputeFinal function
21 mTower Untrusted pointer dereference Reported An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE SetOperationKey2 function
22 mTower Untrusted pointer dereference Reported An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE MACUpdate function
23 mTower Untrusted pointer dereference Reported An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE GetOperationInfoMultiple function
24 mTower Untrusted pointer dereference Reported An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE AEEncryptFinal function
25 mTower Untrusted pointer dereference Reported An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE MACInit function
26 mTower Untrusted pointer dereference Reported An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE SetOperationKey function
27 mTower Untrusted pointer dereference Reported An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE ResetOperation function
28 mTower Untrusted pointer dereference Reported An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE DigestUpdate function
29 mTower Untrusted pointer dereference Reported An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE AEDecryptFinal function
30 mTower Untrusted pointer dereference Reported An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE CipherInit function
31 mTower Untrusted pointer dereference Reported An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE FreeOperation function
32 mTower Untrusted pointer dereference Reported An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE DigestDoFinal function
33 mTower Untrusted pointer dereference Reported An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE AllocateOperation function
34 mTower Untrusted pointer dereference Reported An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE FreeTransientObject function
35 mTower Untrusted pointer dereference Reported An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE AEUpdate function
36 mTower Untrusted pointer dereference Reported An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE ResetOperation function
37 mTower Untrusted pointer dereference Reported Uncertain (provided the PoC to the vendor)
38 mTower Untrusted pointer dereference Reported Uncertain (provided the PoC to the vendor)
Allocation of resources
39 TinyTEE Confirmed TEE Malloc allows a trusted application to achieve Excessive Memory Allocation via a large len value
without limits or throttling
Allocation of resources
40 TinyTEE Confirmed TEE Realloc allows a trusted application to achieve Excessive Memory Allocation via a large len value
without limits or throttling
41 TinyTEE NULL pointer dereference Confirmed TEE AllocateTransientObject contains a NULL pointer dereference on the parameter object
42 TinyTEE Untrusted pointer dereference Confirmed An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE DigestUpdate function
43 TinyTEE Untrusted pointer dereference Confirmed An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE SetOperationKey function
44 TinyTEE Untrusted pointer dereference Confirmed An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE SetOperationKey function
45 TinyTEE Untrusted pointer dereference Confirmed An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE ResetOperation function
46 TinyTEE Untrusted pointer dereference Confirmed An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE FreeOperation function
47 TinyTEE Untrusted pointer dereference Confirmed An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE CipherDoFinal function
48 TinyTEE Untrusted pointer dereference Confirmed An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE CipherInit function
49 TinyTEE Untrusted pointer dereference Confirmed An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE AllocateOperation function
50 TinyTEE Untrusted pointer dereference Confirmed An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE AsymmetricSignDigest function
51 TinyTEE Untrusted pointer dereference Confirmed An invalid pointer dereference can be triggered when a TA tries to read a malformed TEE OperationHandle by the TEE CipherUpdate function
52 Link TEE Air NULL pointer dereference Reported tee memcpy calls tee osa memcpy, which contains a NULL pointer dereference on the result object
53 Link TEE Air NULL pointer dereference Reported tee strcpy calls tee osa strcpy, which contains a NULL pointer dereference on the result object
54 Link TEE Air NULL pointer dereference Reported tee memset calls tee osa strcpy, which contains a NULL pointer dereference on the result object
tee hash update does not check the size of its second parameter ”size” and calls dev ioctl, which triggers an invalid memory access with large ”size” value
55 Link TEE Air Buffer overflow Reported
when consecutively copying 64 bytes in tee osa memcpy
56 Link TEE Air NULL pointer dereference Reported tee memmove calls tee osa memmove, which contains a NULL pointer dereference on the result object
57 Link TEE Air NULL pointer dereference Reported tee strcat calls tee osa strcat, which contains a NULL pointer dereference on the result object
tee hash digest does not check the size of its third parameter ”size” and calls dev ioctl, which triggers an heap overflow with large ”size” value and causes
58 Link TEE Air Buffer overflow Reported
an invalid pointer dereference in tee osa free
An invalid pointer dereference can be triggered when a trusted application tries to access an invalid address in the pool free function called
59 Link TEE Air Untrusted pointer dereference Reported
by tee osa free and tee free
60 Link TEE Air NULL pointer dereference Reported tee strncpy calls tee osa strncpy, which contains a NULL pointer dereference on the result object
61 Link TEE Air NULL pointer dereference Reported tee strcasecmp calls tee osa strcasecmp, which contains a NULL pointer dereference on the s1 and s2 object
62 Link TEE Air NULL pointer dereference Reported tee memcmp calls tee osa memcmp, which contains a NULL pointer dereference on the s1 and s2 object
63 Link TEE Air Untrusted pointer dereference Reported An invalid pointer dereference can be triggered when a trusted application tries to access an invalid address in the tee hash init function
64 Link TEE Air NULL pointer dereference Reported tee strncat calls tee osa strncat, which contains a NULL pointer dereference on the result object
65 Link TEE Air NULL pointer dereference Reported tee strnlen calls tee osa strnlen, which contains a NULL pointer dereference on the s object
tee base64 encode does not check the size of its parameters ”src len” and ”dst”, which triggers a buffer overflow if ”src len” is larger than the size
66 Link TEE Air Buffer overflow Reported
of ”dst” and ruins the metadata of the next chunk
67 Link TEE Air NULL pointer dereference Reported tee strlen calls tee osa strlen, which contains a NULL pointer dereference on the s object
68 Link TEE Air NULL pointer dereference Reported tee strcmp calls tee osa strcmp, which contains a NULL pointer dereference on the s1 and s2 object
tee hash final does not check the size of its first parameter ”dgst” and calls dev ioctl, which triggers an heap overflow if the size of ”dgst” is smaller than
69 Link TEE Air Buffer overflow Reported
48 bytes and causes an invalid pointer dereference in tee osa free
An invalid pointer dereference can be triggered when a trusted application tries to access an invalid address in the tee osa memcpy function
70 Link TEE Air Untrusted pointer dereference Reported
called by tee aes init

18