2025-12-24 18:00:20
4. Finding Tag Leakage Gadgets
6.1. Attacking Chrome
\
In this section, we evaluate the TIKTAG gadgets and MTE bypass exploits in two MTE-enabled systems, the Chrome browser (§7.1) and the Linux kernel (§7.2). All experiments were conducted on the Google Pixel 8 devices.
\ 7.1. Chrome Browser Tag Leakage
We evaluated the TIKTAG-v2 gadget in the V8 JavaScript engine in two environments:
i) the standalone V8 JavaScript engine, and
ii) the Chromium application. The V8 JavaScript engine runs as an independent process, reducing the interference from the Android platform. The Chromium application runs as an Android application, subject to the Android’s application management such as process scheduling and thermal throttling. The experiments were conducted with the V8 v12.1.10 and Chromium v119.0.6022.0 release build.
\ We leveraged MTE random tagging schemes provided by the underlying allocators (Table 1). The standalone V8 used the Scudo allocator [3] (i.e., Android default allocator), which supports 16 random tags for random tagging and offers the OddEvenTags option. When OddEvenTags is enabled, Scudo alternates odd and even random tags for neighboring objects, preventing linear overflow (i.e., OVERFLOWTUNING). When OddEvenTags is disabled, Scudo utilizes all 16 random tags for every object to maximize tag entropy for use-afterfree detection (i.e., UAFTUNING).
\ By default, OddEvenTags is enabled, while we evaluate both settings. Upon releasing an object, Scudo sets a new random tag that does not collide with the previous one. PartitionAlloc (i.e., Chrome default allocator) utilizes 15 random tags and reserves the tag 0x0 for unallocated memory. When releasing an object, PartitionAlloc increments the tag by one, making the tag of the re-allocated memory address predictable. However, in real-world exploits, it is challenging to precisely control the number of releases for a specific address, thus we assume the attacker still needs to leak the tag after each allocation.
\ For the evaluation, we constructed the TIKTAG-v2 gadget in JavaScript (Figure 6) and developed MTE bypass attacks as described in §6.1.3. These attacks exploit artificial vulnerabilities designed to mimic real-world renderer vulnerabilities, specifically linear overflow [44] and use-after-free [42]. We developed custom JavaScript APIs to allocate, free, locate, and access the renderer object to manipulate the memory layout and trigger the vulnerabilities. It’s worth noting that our evaluation shows the best-case performance of MTE bypass attacks since real-world renderer exploits involve
additional overheads in triggering the vulnerabilities and controlling the memory layout.
\
V8 JavaScript Engine. In the standalone V8 JavaScript engine, we evaluated the tag leakage of the TIKTAG-v2 gadget with cache eviction and a memory-based timer. For cache eviction, we used an L1 index-based random eviction set, 500 elements for slow[0] and probe[PROBE_OFFSET], 300 elements for victim.length. The eviction performance of the random eviction set varies on each run, so we repeated the same test 5 times and listed the best result.
\ The random eviction can be optimized with eviction set algorithms [70]. We used a memory counter-based timer with a custom worker thread incrementing a counter, which is equivalent to the SharedArrayBuffer timer [58]. For all possible tag guesses (i.e., 0x0-0xf), we measured the access latency of probe[PROBE_OFFSET] after the gadget 256 times and determined the guessed tag with the minimum average access latency as the correct tag.
\ Table 2 summarizes the MTE bypass exploit results in V8. For a single tag leakage, the gadget was successful in all 100 runs (100%), with an average elapsed time of 3.04 seconds. MTE bypass exploits were evaluated over 100 runs for each vulnerability and OddEvenTags configuration (i.e., disabled (0) and enabled (1)). We excluded linear overflow exploit with OddEvenTags enabled, since the memory corruption is always detected with spatially adjacent objects tagged with different tags and the attack would always fail.
\ The results demonstrate that the attacks were successful in over 97% of the runs, with an average elapsed time of 6 to 13 seconds. In use-after-free exploits, enabling OddEvenTags decreased the average elapsed time by around 40%, due to the decrease in tag entropy from 16 to 8, doubling the chance of tag collision between the temporally adjacent objects.
\
Chromium Application. In the Chromium application setting, we evaluated the TIKTAG-v2 gadget with cache flushing and a SharedArrayBuffer-based timer. Unlike V8, random eviction did not effectively evict cache lines, so we manually flushed the cache lines with dc civac instruction. We attribute this to the aggressive resource management of Android, which can be addressed in the future with cache eviction algorithms tailored for mobile applications.
\ To measure the cache eviction set overhead, we included the cache eviction set traversals in all experiments, using the same cache eviction configuration of the V8 experiments. We measured access latency with a SharedArrayBuffer-based timer as suggested by web browser speculative execution studies [8, 21]. The MTE bypass exploits experiments were conducted in the same manner as the V8 experiments. Table 3 shows the MTE bypass exploit results in the Chromium application.
\ The tag leakage of the TIKTAG-v2 gadget in the Chromium application was successful in 95% of 100 runs, with an average elapsed time of 2.54 seconds. With the MTE bypass exploits, success rates were over 95% for both vulnerability types, with an average elapsed time of 16.11 and 21.90 seconds for linear overflow and use-afterfree, respectively.
\ 7.2. Linux Kernel Tag Leakage
The experiments were conducted on the Android 14 kernel v5.15 using the default configuration. We used 15 random tags (i.e., 0x0–0xe) for kernel objects, as tag 0xf is commonly reserved for the access-all tag in the Linux kernel [37]. The cache line eviction of kernel address cond_ptr to trigger the speculative execution was achieved by cache line bouncing [25] from the user space.
\ For cache measurement, we utilized the virtual counter (i.e., CNTVCT_EL0) to determine the cache hit or miss with the threshold 1.0, which is accessible from the user space. As the virtual counter has a lower resolution (24.5MHz) than the CPU cycle frequency (2.4-2.9 GHz), the accuracy of the cache hit rate is lower than the physical CPU counter-based measurements in §5. The access time was measured in the user space or kernel space, depending on the experiment.
\
Kernel Context Evaluation. We first evaluated whether TIKTAG gadgets can leak MTE tags in the Linux kernel context (Figure 11). We created custom system calls containing TIKTAG-v1 (Figure 2) and TIKTAG-v2 (Figure 6) gadgets and executed them by calling the system calls from the user space. In CHECK, we accessed the guessptr that holds either the correct or wrong tag Tg. In TEST, testptr pointed to
\ either a kernel address or a user space address, depending on whether the cache state difference was measured in the kernel or user space. When we leveraged a user space address as testptr, we passed a user buffer pointer to the kernel space as a system call argument and accessed the pointer in TEST using copyto_user(). The user space address was flushed in the user space before the system call invocation, and the cache state was measured after the system call returned.
\ When we used a kernel address as test_ptr, the cache flush and measurement were performed in the kernel. Each experiment measured the access time over 1000 runs. When executing TIKTAG-v1 in the kernel context, the MTE tag leakage was feasible in both the kernel and user space, where the user space measurement results are shown in Figure 11a.
\ Compared to the user space gadget evaluation (Figure 3), the kernel context required more loads in CHECK to distinguish the cache state difference. Specifically, the cache state difference was discernible from 4 loads in the kernel context, while the user space context required only 2 loads.
\ This can be attributed to the noises from the kernel to the user space context switch overhead, such that the cache hit rates of the tag match cases were lower (i.e., under 90%) than the user space gadget evaluation (i.e., 100%). When executing the TIKTAG-v2 gadget in the kernel space, MTE tag leakage was observed only in the kernel space (Figure 11b).
\ When we measured the access latency of test_ptr in the user space, the gadget did not exhibit a cache state difference. Although the TIKTAG-v2 gadget might not be directly exploitable in the user space, cache state amplification techniques [21, 72] could be utilized to make it observable from the user space.
\
Kernel MTE Bypass Exploit. We evaluated MTE bypass exploits in the Linux kernel with two TIKTAG-v1 gadgets: an artificial TIKTAG-v1 gadget with 8 loads in CHECK (i.e., artificial) and a real-world TIKTAG-v1 gadget in sndtimeruserread() (Figure 10). The artificial gadget evaluates the best-case performance of MTE bypass attacks, while the sndtimeruserread() gadget demonstrates realworld exploit performance.
\ Both gadgets were triggered by invoking the system call containing the gadget from the user space, leveraging a user space address as testptr, and measuring the access latency of testptr in user space. We conducted a tag leakage attack and MTE bypass attack for each gadget. For the MTE bypass attack, we synthesized a buffer overflow vulnerability.
\ Each gadget dereferenced the vulnerable pointer (i.e., guess_ptr) to trigger tag checks; an out-of-bounds pointer and a dangling pointer for the buffer overflow and use-after-free exploits, respectively. The exploit methodology followed the process described in §D.
\
summarizes the MTE bypass exploit results. For a single tag leakage, the gadgets successfully leaked the correct tag in all 100 runs (100%), with an average elapsed time of 0.12 seconds in the artificial gadget, and 3.38 seconds in the sndtimeruser_read() gadget. The MTE bypass exploit for the artificial TIKTAG-v1 gadget was successful in all 100 runs (100%), with an average elapsed time of 0.18 seconds.
\ Regarding the MTE bypass exploit for the sndtimeruserread() gadget, the success rate was 97% with an average elapsed time of 6.86 seconds. As the sndtimeruserread() gadget involves complex kernel function calls and memory accesses, the performance of the MTE bypass exploit is slightly lower compared to the artificial gadget. Nevertheless, it still demonstrates a high success rate within a reasonable time frame.
:::info Authors:
:::
:::info This paper is available on arxiv under CC 4.0 license.
:::
\
2025-12-24 17:00:09
2. Constant function markets and concentrated liquidity
3. The wealth of liquidity providers in CL pools
4. Optimal liquidity provision in CL pools
6. Discussion: modelling assumptions
This section summarises our modelling assumptions and discusses their implications, strengths, and weaknesses.
Continuous trading. Our model assumes continuous repositioning of the LP’s position. However, when interacting with blockchains, updates occur at the block validation frequency. For instance, the Ethereum network’s blocks are validated every 13 seconds, on average.
\ Moreover, within each block, the transactions form a (random) queue that determines the priority with which they are executed. Finally, price formation in Ethereum blockchains leads to sandwich attacks; see Capponi et al. (2023b) for more details. Our model can be extended to include delays inherent to blockchains and we refer the reader to the work in Cartea and Sanchez-Betancourt ´ (2021) and Cartea et al. (2021).
\
Rebalancing. Continuous repositioning requires rebalancing the LP’s assets which incurs costs as discussed in Section 3.3. To model this aspect, we assume that the LP pays costs that are proportional to the quantity of asset Y held in the pool. In practice, the exact costs depend on variations in the holdings between two consecutive liquidity positions.
\ Thus, liquidity provision strategies should balance large variations in the holdings with fee revenue, PL, and concentration cost. However, the nonlinearity in the CL constant product formula complicates the mathematical modelling of this aspect of trading costs. Moreover, rebalancing costs depend on the cost structure of the trading venue where rebalancing trades are executed.
\
Gas fees. Our model assumes that gas fees paid by the LP to interact with the blockchain are flat and constant. In practice, gas fees are stochastic and depend on exogenous factors such as the price of electricity and network congestion. These could be included in our model by considering a stochastic gas fee that is observed by the LP.
\ Also, our model is optimal when the spread of liquidity position is continuously adjusted to account for changes in the stochastic drift and
profitability of liquidity taking according to (23). Thus, profitable liquidity provision using our strategy requires a large initial wealth to overcome gas fees from continuous trading.
\ However, we expect the strategy to remain profitable in discrete time when the stochastic drift µ and the stochastic profitability π remain stable, so the LP only rebalances her liquidity position when either the drift µ or the pool fee rate π undergo large changes.
\
Concentration costs. The specific microstructure of CL markets features a new type of investment risk which we refer to as concentration risk. To capture the losses due to concentration risk in a continuous-time framework, we introduced an instantaneous cost which is inversely proportional to the spread of the LP’s position, and we showed that it captures the losses due to concentration risk accurately. In practice, LPs must tailor the estimation of the concentration cost parameter γ in (12) to the rebalancing frequency and to the volatility of the marginal rate Z.
\
Asymmetry. Our model assumes a fixed relation between the asymmetry of the LP’s position and the drift in the marginal rate. This relation fits observed data but also leads the LP to skew the position to capture more LT trades and to profit from expected rate movements. Future work will consider a richer characterization of the asymmetry because it may be desirable for LPs to adjust the asymmetry of their position as a function of other state variables or as a controlled variable
\
Fee dynamics. Our model assumes that the distribution of fee revenue π among LPs is stochastic and proportional to the size of the pool to reflect that large pools attract more trading flow because trading is cheaper. We also make the simplifying assumption that fees are uncorrelated to the price. In practice, the dynamics of fee revenue may be correlated to those of the volatility of the rate, which is also related to the concentration cost parameter γ. Future work will consider more complex relations among these variables.
\
Profitability condition. We impose specific dynamics for the fee rate π such that it satisfies a profitability condition (19) that allows us to obtain an admissible strategy. While we use this constraint to solve the optimal liquidity provision problem, it also represents an adequate and natural measure for LPs to assess the profitability of liquidity provision in different pools before depositing their assets.
\
Constant volatility. At present, CFMs with CL mainly serve as trading venues for crypto-assets which are better described with a diffusion model with stochastic volatility. It is straightforward to extend our strategy to this type of models.
\
Market impact. Finally, our analysis does not take into account the impact of liquidity provision on liquidity taking activity, however, we expect liquidity provision in CPMs with CL to be profitable in pools where the volatility of the marginal rate is low, where liquidity taking activity is high, and when the gas fee cost to interact with the liquidity pools is low. These conditions ensure that the fees paid to LPs in the pool, adjusted by gas fees and concentration cost, exceed PL so liquidity provision is viable.
\ 6.1. Discussion: related work
Closest to this work are the strategic liquidity provision models proposed in Fan et al. (2021) and Fan et al. (2022) which also consider CL markets. Both models allow LPs to compute liquidity positions over different intervals centered around the marginal rate within a given time horizon; Fan et al. (2021) only consider static LP strategies which do not use of reallocations, and Fan et al. (2022) reposition liquidity whenever the price is outside of the position range.
\ Both approaches only focus on maximising fee revenue and rely on approximations of the LP’s objective and use Neural Networks to obtain context-aware approximate strategies. In contrast, our model leads to closed-form formulae that explicitly balance fee revenue with concentration risk, predictable loss, and rebalancing costs, while allowing LPs to use price signals (potentially based on exogenous information) to improve trading performance.
:::info Authors:
:::
:::info This paper is available on arxiv under CC0 1.0 Universal license.
:::
\
2025-12-24 17:00:04
4. Finding Tag Leakage Gadgets
6.1. Attacking Chrome
\
To demonstrate the exploitability of TIKTAG gadgets in MTE-based mitigation, this section develops two realworld attacks against Chrome and Linux kernel (Figure 9). There are several challenges to launching real-world attacks using TIKTAG gadgets. First, TIKTAG gadgets should be executed in the target address space, requiring the attacker to construct or find gadgets from the target system. Second, the attacker should control and observe the cache state to leak the tag check results. In the following, we demonstrate the real-world attacks using TIKTAG gadgets on two real-world systems: the Google Chrome browser (§6.1) and the Linux kernel (§6.2), and discuss the mitigation strategies.
\ 6.1. Attacking Chrome
Browser A web browser is a primary attack surface for webbased attacks as it processes untrusted web content, such as JavaScript and HTML. We first overview the threat model (§6.1.1) and provide a TIKTAG gadget constructed in the V8 JavaScript engine (§6.1.2). Then, we demonstrate the effectiveness of TIKTAG gadgets in exploiting the browser (§6.1.3) and discuss the mitigation strategies (§6.1.4).
\ ==6.1.1. Threat Model.== We follow the typical threat model of Chrome browser attacks, where the attacker aims to exploit memory corruption vulnerabilities in the renderer process. We assume the victim user visits the attacker-controlled website, which serves a malicious webpage. The webpage includes crafted HTML and JavaScript, which exploit memory corruption vulnerabilities in the victim’s renderer process. We assume all Chrome’s state-of-the-art mitigation techniques are in place, including ASLR [18], CFI [15], site isolation [53], and V8 sandbox [56]. Additionally, as an orthogonal defense, we assume that the renderer process enables random MTE tagging in PartitionAlloc [2].
\ ==6.1.2. Constructing TIKTAG Gadget.== In the V8 JavaScript environment, TIKTAG-v2 was successfully constructed and leaked the MTE tags of any memory address. However, we didn’t find a constructible TIKTAG-v1 gadget, since the tight timing constraint between BR and CHECK was not feasible in our speculative V8 sandbox escape technique (§A).
V8 TikTag-v2 Gadget. Figure 8 is the TIKTAG-v2 gadget constructed in the V8 JavaScript engine and its pseudo-C code after JIT compilation. With this gadget, the attacker can learn whether the guessed tag Tg matches with the tag Tm assigned to target_addr. The attacker prepares three arrays, slow, victim, probe, and an idx value. slow is a Unit8Array with a length of 64 and is accessed in BR to trigger the branch misprediction. victim is a Float64Array with length 64, which is accessed to trigger store-to-load forwarding. probe is a Uint8Array with length 512, and is accessed in
\ TEST to leak the tag check result. A Number type idx value is used in out-of-bounds access of victim. idx value is chosen such that victim[idx] points to targetaddr with a guessed tag Tg (i.e., (Tg«56)|targetaddr). To speculatively access the target_addr outside the V8 sandbox, we leveraged the speculative V8 sandbox escape technique we discovered during our research, which we detail in §A. Line 8 of Figure 8a is the BR block of the TIKTAG-v2 gadget, triggering branch misprediction with slow[0].
\ Line 12-13 is the CHECK block, which performs the store-to-load forwarding with victim[idx], accessing target_addr with a guessed tag Tg. When this code is JIT-compiled (Figure 8b), a bound check is performed, comparing idx against victim.length. If idx is an out-of-bounds index, the code returns undefined, but if victim.length field takes a long time to be loaded, the CPU speculatively executes the following store and load instructions.
\ After that, line 17 implements the TEST block, which accesses the probe with the forwarded value val as an index. Again, a bound check on val against the length of probe is preceded, but this check succeeds as PROBEOFFSET is smaller than the length of probe array. As a result, probe[PROBEOFFSET] is cached only when the store-to-load forwarding succeeds, which is the case when Tg matches Tm.
\ ==6.1.3. Chrome MTE bypass attack.== Figure 9a illustrates the overall MTE bypass attack on the Chrome browser with arbitrary tag leakage primitive of TIKTAG gadgets. We assume a buffer overflow vulnerability in the renderer process, where exploiting a temporal vulnerability (e.g., use-after-free) is largely the same. The vulnerability overflows a pointer (i.e., vuln_ptr) to a vulnerable object (i.e., objvuln), corrupting the adjacent object (i.e., objtarget).
\ With PartitionAlloc’s MTE enforcement, two objects have different tags with a 14/15 probability. To avoid raising an exception, the attacker needs to ensure that the tags of objvuln and objtarget are the same. TIKTAG-v2 can be utilized to leak the tag of objvuln ( 1 ) and objtarget ( 2 ). If both leaked tags are the same, the attacker exploits the vulnerability, which would not raise a tag check fault ( 3 ). Otherwise, the attacker frees and re-allocates objtarget and goes back to the first step until the tags match.
\ ==Triggering Cache Side-Channel.== To successfully exploit a TIKTAG gadget, the attacker needs to satisfy the following requirements:
i) branch training,
ii) cache control, and
iii) cache measurement. All three requirements can be met in JavaScript.
First, the attacker can train the branch predictor by running the gadget with non-zero slow[0] and in-bounds idx, and trigger the branch misprediction in BR with zero value in slow[0] and out-of-bounds idx.
Second, the attacker can evict the cache lines of slow[0], victim.length, and probe[PROBE_OFFSET] with JavaScript cache eviction techniques [8, 21, 70].
Third, the attacker can measure the cache status of probe[PROBE_OFFSET] with a high-resolution timer based on SharedArrayBuffer [16, 58].
\ ==Exploiting Memory Corruption Vulnerabilities.== Given the leaked MTE tags, the attacker can exploit spatial and temporal memory corruption vulnerabilities in the renderer. The attack strategy is largely the same as the traditional memory corruption attacks but should ensure that the vulnerability does not raise a tag check fault utilizing the leaked tags. We further detail the attack strategy in §C.
\ ==6.1.4. Mitigation.== To mitigate the TIKTAG gadget-based MTE bypass attacks in the browser renderer process, the following mitigations can be employed:
i) Speculative execution-aware sandbox: To stop attackers from launching TIKTAG-based attacks from a sandboxed environment like V8 sandbox, the sandbox can be fortified by preventing any speculative memory access beyond the sandbox’s memory region. While modern web browsers employ a sandbox to isolate untrusted web contents from the renderer, they often overlook speculative paths.
\ For instance, Chrome V8 sandbox [56] and Safari Webkit sandbox [1] do not completely mediate the speculative paths [27]. Based on current pointer compression techniques [64], speculative paths can be restricted to the sandbox region by masking out the high bits of the pointers.
\
ii) Speculation barrier: As suggested in §5, placing a speculation barrier after BR for potential TIKTAG gadgets can prevent speculative tag leakage attacks. However, this mitigation may not be applicable in the performance-critical browser environment, as it may introduce significant performance overhead.
\ iii) Prevention of gadget construction: As suggested in §5.2, the TIKTAG-v2 gadget can be mitigated by padding instructions between store and load instructions. A TIKTAGv1 gadget, although we have not found an exploitable one, can be mitigated by padding instructions between a branch and memory accesses, as described in §5.1.
\ 6.2. Attacking the Linux Kernel
The Linux kernel on ARM is widely used for mobile devices, servers, and IoT devices, making it an attractive attack target. Exploiting a memory corruption vulnerability in the kernel can escalate the user’s privilege, and thus MTE is a promising protection mechanism for the Linux kernel. TIKTAG-based attacks against the Linux kernel pose unique challenges different from the browser attack (§6.1).
\ This is because the attacker’s address space is isolated from the kernel’s address space where the gadget will be executed. In the following, we first overview the threat model of the Linux kernel (§6.2.1) and provide a proof-of-concept TIKTAG gadget we discovered in the Linux kernel (§6.2.2). Finally, we demonstrate the effectiveness of TIKTAG gadgets in exploiting Linux kernel vulnerabilities (§6.2.3).
\ ==6.2.1. Threat Model.== The threat model here is largely the same as that of typical privilege escalation attacks against the kernel. Specifically, we focus on the ARM-based Android Linux kernel, hardened with default kernel protections (e.g., KASLR, SMEP, SMAP, and CFI). We further assume the kernel is hardened with an MTE random tagging solution, similar to the production-ready MTE solutions, Scudo [3].
\ To be specific, each memory object is randomly tagged, and a random tag is assigned when an object is freed, thereby preventing both spatial and temporal memory corruptions. The attacker is capable of running an unprivileged process and aims to escalate their privilege by exploiting memory corruption vulnerabilities in the kernel. It is assumed that the attacker knows kernel memory corruption vulnerabilities but does not know any MTE tag of the kernel memory. Triggering memory corruption between kernel objects with
\ mismatching tags would raise a tag check fault, which is undesirable for real-world exploits. One critical challenge in this attack is that the gadget should be constructed by reusing the existing kernel code and executed by the system calls that the attacker can invoke. As the ARMv8 architecture separates user and kernel page tables, user space gadgets cannot speculatively access the kernel memory. This setup is very different from the threat model of attacking the browser (§6.1), which leveraged the attackerprovided code to construct the gadget. We excluded the eBPF-based gadget construction either [17, 28], because eBPF is not available for the unprivileged Android process [33].
\ ==6.2.2. Kernel TikTag Gadget==. As described in §4.1, TIKTAG gadgets should meet several requirements, and each requirement entails challenges in the kernel environment.
First, in BR, a branch misprediction should be triggered with cond_ptr, which should be controllable from the user space. Since recent AArch64 processors isolate branch prediction training between the user and kernel [33], the branch training needs to be performed from the kernel space.
Second, in CHECK, guessptr should be dereferenced. guessptr should be crafted from the user space such that it embeds a guess tag (Tg) and points to the kernel address (i.e., target_addr) to leak the tag (Tm). Unlike the browser JavaScript environment (§6.1), user-provided data is heavily sanitized in system calls, so it is difficult to create an arbitrary kernel pointer.
\ For instance, accessok() ensures that the user-provided pointer points to the user space, and the arrayindexnospec macro prevents speculative out-of-bounds access with the user-provided index. Thus, guessptr should be an existing kernel pointer, specifically the vulnerable pointer that causes memory corruption. For instance, a dangling pointer in use-after-free (UAF) or an out-of-bounds pointer in buffer overflow can be used. Lastly, in TEST, testptr should be dereferenced, and testptr should be accessible from the user space. To ease the cache state measurement, test_ptr should be a user space pointer provided through a system call argument.
\ ==Discovered Gadgets.== We manually analyzed the source code of the Linux kernel to find the TIKTAG gadget meeting the aforementioned requirements. As a result, we found one potentially exploitable TIKTAG-v1 gadget in sndtimeruserread() (Figure 10). This gadget fulfills the requirements of TIKTAG-v1 (§5.1). At line 10 (i.e., BR), the switch statement triggers branch misprediction with a user-controllable value tu->tread (i.e., condptr). At lines 14-17 (i.e., CHECK), tread (i.e., guessptr) is dereferenced by four load instructions. tread points to a struct sndtimer_tread64 object that the attacker can arbitrarily allocate and free.
\ If a temporal vulnerability transforms tread into a dangling pointer, it can be used as a guessptr. At line 20, (i.e., TEST), a user space pointer buffer (i.e., testptr) is dereferenced in copytouser. As this gadget is not directly reachable from the user space, we made a slight modification to the kernel code; we removed the early return for the default case at line 6. This ensures that the buffer is only accessed in the speculative path to observe the cache state difference due to speculative execution.
\ Although this modification is not realistic in a realworld scenario, it demonstrates the potential exploitability of the gadget if similar code changes are made. We discovered several more potentially exploitable gadgets, but we were not able to observe the cache state difference between the tag match and mismatch. Still, we think there is strong potential for exploiting those gadgets. Launching TIKTAG-based attacks involves complex and sensitive engineering, and thus we were not able to experiment with all possible cases.
\ Especially, TIKTAG-v1 relies on the speculation shrinkage on wrong path events, which may also include address translation faults or other exceptions in the branch misprediction path. As system calls involve complex control flows, the speculation shrinkage may not be triggered as expected. In addition, several gadgets may become exploitable when kernel code changes. For instance, a TIKTAG-v1 gadget in ip6mr_ioctl() did not exhibit an MTE tag leakage behavior when called from its system call path (i.e., ioctl). However, the gadget had tag leakage when it was ported to other syscalls (e.g., write) with a simple control flow.
\ ==6.2.3. Kernel MTE bypass attack.== Figure 9b illustrates the MTE bypass attacks on the Linux kernel. Taking a use-afterfree vulnerability as an example, we assume the attacker has identified a corresponding TIKTAG gadget, SysTikTagUAF(), capable of leaking the tag check result of the dangling pointer created by the vulnerability. For instance, the TIKTAG-v1 gadget in sndtimeruser_read() (Figure 10) can leak the tag check result of tread, which can become a dangling pointer by a use-after-free or double-free vulnerability.
\ The attack proceeds as follows: First, the attacker frees a kernel object (i.e., objvuln) and leaves its pointer (i.e., vuln_ptr) as a dangling pointer ( 1 ). Next, the attacker allocates another kernel object (i.e., objtarget) at the address of objvuln with SysAllocTarget() ( 2 ). Then, the attacker invokes SysTikTag() with a user space buffer (i.e., ubuf) ( 3 ), and leaks the tag check result (i.e., Tm == Tg) by measuring the access latency of ubuf ( 4 ). If the tags match, the attacker triggers SysExploitUAF(), a system call that exploits the use-after-free vulnerability ( 5 ). Otherwise, the attacker reallocates objtarget until the tags match.
\ ==Triggering Cache Side-Channel.== As in §6.1.3, a successful TIKTAG gadget exploitation requires i) branch training, ii) cache control, and iii) cache measurement. For branch training, the attacker can train the branch predictor and trigger speculation with user-controlled branch conditions from the user space. For cache control, the attacker can flush the user space buffer (i.e., ubuf), while the kernel memory address can be evicted by cache line bouncing [25]. For cache measurement, the access latency of ubuf can be measured with the virtual counter (i.e., CNTVCT_EL0) or a memory counter-based timer (i.e., near CPU cycle resolution).
\ ==Exploiting Memory Corruption Vulnerabilities.== TIKTAG gadgets enable bypassing MTE and exploiting kernel memory corruption vulnerabilities. The attacker can invoke the TIKTAG gadget in the kernel to speculatively trigger the memory corruption and obtain the tag check result. Then, the attacker can obtain the tag check result, and trigger the memory corruption only if the tags match. We detail the Linux kernel MTE bypass attack process in §D.
\ ==6.2.4. Mitigation.== To mitigate TIKTAG gadget in the Linux kernel, the kernel developers should consider the following mitigations:
i) Speculation barrier: Speculation barriers can effectively mitigate TIKTAG-v1 gadget in the Linux kernel. To prevent attackers from leaking the tag check result through the user space buffer, kernel functions that access user space addresses, such as copytouser and copyfromuser, can be hardened with speculation barriers. As described in §5.1, leaking tag check results with store access can be mitigated by placing a speculation barrier before the store access (i.e., TEST).
\ For instance, to mitigate the gadgets leveraging copytouser, a speculation barrier can be inserted before the copytouser invocation. For gadgets utilizing load access to the user space buffer, the barriers mitigate the gadgets if inserted between the branch and the kernel memory access (i.e., CHECK). For instance, to mitigate the gadgets leveraging copyfromuser, the kernel developers should carefully analyze the kernel code base to find the pattern of the conditional branch, kernel memory access, and copyfromuser(), and insert a speculation barrier between the branch and the kernel memory access.
\
ii) Prevention of gadget construction: To eliminate potential TIKTAG gadgets in the Linux kernel, the kernel source code can be analyzed and patched. As TIKTAG gadgets can also be constructed by compiler optimizations, a binary analysis can be conducted. For each discovered gadget, instructions can be reordered or additional instructions can be inserted to prevent the gadget construction, following the mitigation strategies in §5.1 and §5.2.
:::info Authors:
:::
:::info This paper is available on arxiv under CC 4.0 license.
:::
\
2025-12-24 16:00:04
4. Finding Tag Leakage Gadgets
6.1. Attacking Chrome
\
In this section, we present TIKTAG gadgets discovered by the tag leakage template and fuzzing (§4). Each gadget featuring unique memory access patterns leaks the MTE tag of a given memory address. TIKTAG-v1 (§5.1) exploits the speculation shrinkage in branch prediction and data prefetching, and TIKTAG-v2 (§5.2) leverages the blockage of store-to-load forwarding. We further analyze the root cause and propose mitigations at hardware and software levels.
\ 5.1. TIKTAG-v1: Exploiting Speculation Shrinkage
During our experiment with the MTE tag leakage template (§4.1), we observed that multiple tag checks in CHECK influence the cache state of testptr. With a single tag check, testptr was always cached regardless of the tag check result. However, with two or more tag checks, test_ptr was cached on tag match, but not cached on tag mismatch.
\ In summary, we found that the following three conditions should hold for the template to leak the MTE tag:
(i) CHECK should include at least two loads with guess_ptr;
(ii) TEST should access test_ptr (either load or store, dependent or independent to CHECK); and
(iii) CHECK should be close to BR (within 5 CPU cycles) while TEST should be far from CHECK (more than 10 CPU cycles away). If these conditions are met, testptr is cached on tag match and not cached on tag mismatch. If any of these is not met, testptr is either always cached or never cached. Based on this observation, we developed TIKTAG-v1, a gadget that leaks the MTE tag of any given memory address.
\ ==Gadget.== Figure 2 illustrates the TIKTAG-v1 gadget. In BR, the CPU mispredicts the branch result and speculatively executes CHECK. In CHECK, guessptr is dereferenced two or more times, triggering tag checks with Tg against Tm. GAP provides the time gap between BR and TEST, and then in TEST, testptr is accessed. GAP can be filled with various types of instructions, such as computational instructions (e.g., orr, mul) or memory instructions (e.g., ldr, str), as long as it provides more than 10 CPU cycles of the time gap.
\ ==Experimental Results.== We found that TIKTAG-v1 is an effective MTE tag leakage gadget on the ARM Cortex-X3 (core 8 of Pixel 8 devices) in both MTE synchronous and asynchronous modes. We leveraged the physical CPU cycle counter (i.e., PMCCNTR_EL0) for time measurement, which was enabled by modifying the Linux kernel. An L1 cache hit is determined if the access latency is less than or equal to 35 CPU cycles.
In a real-world setting, the virtual CPU cycle counter (i.e., CNTVCTEL0) is available to the user space with lower resolution, which also can effectively observe the tag leakage behavior. We experimented to measure the cache hit rate of testptr after executing TIKTAG-v1.
\ To verify condition
(i), we varied the number of loads in CHECK (i.e., Len(CHECK)) from 1, 2, 4, and 8. To verify condition
(ii), we varied the types of memory access in TEST (i.e., independent/dependent, load/store). To verify condition
(iii), we filled GAP with a sequence of orr instructions (where each orr is dependent on the previous one) and varied its length (i.e., Len(GAP)). Figure 3 shows the experimental results. The x-axis represents Len(GAP) and the y-axis represents the cache hit rate of test_ptr measured over 1,000 trials.
\ When Len(CHECK) was 1, the cache hit rate of testptr had no difference between tag match and mismatch. testptr was either always cached (i.e., load access) or cached until a certain threshold and then not cached (i.e., store access). When Len(CHECK) was 2 or more, depending on the tag check result, the cache hit rate differed, validating the condition
(i). If the tag matched, the cache hit rate was the same as when Len(CHECK) was 1. If the tag mismatched, the cache hit rate dropped compared to the tag match (annotated with arrows). This difference was observed in all access types of TEST, validating the condition
\ (ii). The cache hit rate drop was observed after about 10 orr instructions in GAP. Further experiments inserting lengthy instructions between BR and CHECK (§E) confirmed that CHECK should be close to BR, validating the condition
(iii). When the tag mismatched, the cache hit was periodic and the period got shorter as Len(CHECK) increased. When Len(CHECK) is 2, a cache hit occurred in 5 out of 6 trials (83%, arrows (a)). When Len(CHECK) is 4, a cache hit occurred in 2 out of 3 trials (66%, arrows b).
\ When Len(CHECK) is 8, the pattern differed between load and store accesses (arrows c and d). For store access, a cache hit was observed every 3 trials (33%, arrows c). For load access, the pattern changed over iterations from all cache hits (0%) to a cache hit every 2 trials (50%) (arrows d). A similar cache hit rate drop was observed when guess_ptr points to an unmapped address and generated speculative address translation faults. This further indicates that TIKTAG-v1 can be utilized as an address-probing gadget [20] useful for breaking ASLR.
\ ==Root Cause.== Analyzing the gadget, we found that tag check results affect the CPU’s data prefetching behavior and the
\ speculative execution. This refutes the previous studies on speculative MTE tag leakage [22, 38], which stated that tag check faults do not affect the speculation execution and did not state the impacts of the data prefetching. In general, modern CPUs speculatively access memory in two cases: speculative execution [30] and data prefetching [10, 19]. To identify the root cause of TIKTAG-v2 in these two cases, we conducted an ablation study (Figure 4).
\ First, we eliminated the effect of speculative execution by inserting a speculation barrier (i.e., sb) between CHECK and TEST. Second, we varied the memory access pattern between branch training and speculative execution phases to eliminate the effect of data prefetching. In Baseline, no speculation barrier was inserted, and both branch training and speculative execution phases accessed the same addresses in order. In this case, test_ptr was cached on tag match, but not cached on tag mismatch.
\ In -SE, a speculation barrier was inserted to prevent TEST from being speculatively executed. Here, the same cache state difference was observed, indicating that the difference in Baseline is not due to the speculative execution at least in this case. Next, in -SE & -DP, the memory access pattern was also varied in the speculative execution phase to prevent testptr from being prefetched. As a result, testptr was always not cached, verifying that the CPU failed to prefetch test_ptr due to the divergence in the access pattern. If we compare -SE and -SE & -DP, the cache state difference was observed only when data prefetching is enabled (-SE).
\ Considering the CPU’s mechanism, such a difference seems to be due to data prefetching—i.e., the CPU prefetches data based on the previous access pattern, but skips it on tag mismatch. Finally, in -DP, we removed the speculation barrier to reenable the speculative execution of TEST while still varying the memory access pattern. In this case, the difference is observed again between tag match and mismatch. Comparing -DP and -SE & -DP, we can conclude that the speculative execution is also the root cause of the cache difference—i.e.,
\ the CPU halts speculative execution on tag check faults. We suspect that the CPU optimizes performance by halting speculative execution and data prefetching on tag check faults. A relevant patent filed by ARM [12] explains that the CPU can reduce speculations on wrong path events [9], which are events indicating the possibility of branch misprediction, such as spurious invalid memory accesses. By detecting branch misprediction earlier, the CPU can save recovery time from wrong speculative execution and improve the data prefetch accuracy by not prefetching the wrong path-related data.
\ Since these optimizations are beneficial in both MTE synchronous and asynchronous modes, we think that the tag leakage behaviors were observed in both MTE modes. We also think there is a time window to detect wrong path events during speculative execution upon branch prediction, which seems to be 5 CPU cycles. As explained in the patent [12], the CPU may maintain speculation confidence values for speculative execution and data prefetching.
\ We think the CPU reduces the confidence values on tag check faults, halts speculation if it drops below a certain threshold, and restores it to the initial level. This reasoning explains the periodic cache miss of testptr on tag mismatch, where the confidence value is repeatedly reduced below the threshold (i.e., cache miss) and restored (i.e., cache hit). In addition, when TEST is store access, the speculation barrier made testptr always not cached. This indicates that the CPU does not prefetch data for store access, thus the speculation window shrinkage is the only root cause in such cases.
\ ==Variants.== Running the tag leakage fuzzer (§4.2), we discovered variants of TIKTAG-v1 leveraging linked list traversal (Figure 5). Before the gadget, a linked list of 4 instances is initialized, where each instance points to the next instance (i.e., ptr0 to ptr3), and the cache line of the last instance (ptr3) is flushed. The gadget traverses the linked list by accessing ptr0 to ptr3 in order, where TEST accesses ptr3 only if the branch result is true. After the gadget, the cache hit rate of ptr3 is measured.
\ In the first variant (Figure 5a), TEST is located in the true branch of the conditional branch BR. In the second variant (Figure 5b), TEST is located out of the conditional branch path, where both the true and false branches merge. In both variants, if the tag matched in CHECK, ptr3 was cached, but not cached if the tag mismatched, as in the original TIKTAG-v1 gadget (Figure 3). We think the root cause is the same as the original gadget—i.e., the CPU changes speculative execution and data prefetching behaviors
on tag check faults. Moreover, the variants can be effective in realistic scenarios like linked list traversal, and the tag leakage can also be observed from the memory access outside the conditional branch’s scope. Mitigation. TIKTAG-v1 exploits the speculation shrinkage on tag check faults in speculative execution and data prefetching. To prevent MTE tag leakage at the micro-architectural level, the CPU should not change the speculative execution or data prefetching behavior on tag check faults.
\ To prevent TIKTAG-v1 at the software level, the following two approaches can be used.
i) Speculation barrier: Speculation barrier can prevent the TIKTAG-v1 gadget from leaking the MTE tag. If TEST contains store access, placing a speculation barrier (i.e., sb) or instruction synchronization barrier (i.e., isb) makes test_ptr always not cached, preventing the tag leakage. If TEST contains load access, placing the barrier before TEST does not prevent tag leakage, but placing it before CHECK mitigates tag leakage, since speculative tag check faults are not raised.
ii) Padding instructions: TIKTAG-v1 requires that tag check faults are raised within a time window from the branch. By inserting a sequence of instructions before CHECK to extend the time window, the CPU does not reduce the speculations and test_ptr is always cached (§E).
\ 5.2. TIKTAG-v2: Exploiting Store-to-Load Forwarding
Inspired by Spectre-v4 [45] and LVI [67] attacks, we experimented with the MTE tag leakage template to trigger store-to-load forwarding behavior [61]. As a result, we discovered that store-to-load forwarding behavior differs on tag check result if the following conditions hold:
(i) CHECK triggers store-to-load forwarding, and
(ii) TEST accesses memory dependent on the forwarded value. If the tag matches in CHECK, the memory accessed in TEST is cached; otherwise, it is not cached.
\ Based on this observation, we developed TIKTAG-v2. Gadget. Figure 6 illustrates the TIKTAG-v2 gadget. The initial setting follows the MTE tag leakage template (§4.1), where the CPU mispredicts the branch BR and speculatively executes CHECK and TEST. At CHECK, the CPU triggers store-toload forwarding behavior by storing testptr at guessptr and immediately loading the value from guess_ptr as ptr.
\ If CHECK succeeds the tag checks (i.e., Tg matches Tm), the CPU forwards testptr to ptr and speculatively accesses testptr in TEST. If CHECK fails the tag checks (i.e., Tg mismatches Tm), the CPU blocks testptr from being forwarded to ptr and does not access testptr.
\ ==Experimental Results.== TIKTAG-v2 showed its effectiveness as an MTE tag leakage gadget in ARM Cortex-A715 (core 4-7 of Pixel 8). We identified one requirement for TIKTAGv2 to exhibit the tag leakage behavior: the store and load instructions in CHECK should be executed within 5 instructions. If this requirement is met, the cache hit rate of test_ptr after TIKTAG-v2 exhibited a notable difference between tag match and mismatch (Figure 7).
\ Otherwise, the store-toload forwarding always succeeded and the CPU forwarded testptr to ptr, and testptr was always cached. To verify the requirement, we conducted experiments by inserting two instruction sequences, SLIDE and GAP (Figure 6). Both sequences consist of bitwise OR operations (orr), each dependent on the previous one, while not changing register or memory states. SLIDE is added before the gadget to control the alignment of store-to-load forwarding in the CPU pipeline.
\ GAP is added between the store and load instructions in CHECK to control the distance between them. The results varying SLIDE from 0 to 40 and GAP from 0 to 4 are shown in Figure 7. In each subfigure, the x-axis represents the length of GAP, and the y-axis represents the cache hit rate of testptr after the gadget, measured over 1000 trials. On tag match, the cache hit rate of testptr was near 100% in all conditions. However, on tag mismatch, the hit rate dropped on every 5 instructions in SLIDE.
\ With Len(GAP)=0 (i.e., no instruction), the hit rate drop was most frequent, occurring in 4 out of SLIDE length. With Len(GAP)=1,2,3, the hit rate drop occurred in 3, 2, and 1 times every 5 instructions in SLIDE, respectively. With Len(GAP)=4, no hit rate drop was observed. Similarly to TIKTAG-v1, the blockage of store-to-load forwarding was not specific to the MTE tag check fault, but was also observed with address translation fault, thus TIKTAG-v2 can also be utilized as an address-probing gadget.
\ ==Root Cause.== The root cause of TIKTAG-v2 is likely due to the CPU preventing store-to-load forwarding on tag check faults. The CPU detects the store-to-load dependency utilizing internal buffers that log memory access information, such as Load-Store Queue (LSQ), and forwards the data if the dependency is detected. Although there is no documentation detailing the store-to-load forwarding mechanism on tag check faults, a relevant patent filed by ARM [7] provides a hint on the possible explanation.
\ The patent suggests that if the store-to-load dependency is detected, the load instruction can skip the tag check and the CPU can always forward the data. If so, store-to-load forwarding would not leak the tag check result (i.e., data is forwarded both on tag match and mismatch), as observed when Len(GAP) is 4 or more. When Len(GAP) is less than 4, however, the store-to-load succeeded on tag match and failed on tag mismatch.
\ We suspect that the CPU performs the tag check for the load instruction if the store-to-load dependency is not detected, and the CPU blocks the forwarding on tag check faults to prevent meltdown-like attacks [36, 41]. Considering the affected core (i.e., Cortex-A715) dispatches 5 instructions in a cycle [55], it is likely that the CPU cannot detect the dependency if the store and load instructions are executed in the same cycle, since the store information is not yet written to the internal buffers.
\ If Len(GAP) is 4 or more, the store and load instructions are executed in the different cycles, and the CPU can detect the dependency. Therefore, the CPU skips the tag check and always forwards the data from the store to load instructions. If Len(GAP) is less than 4, the store and load instructions are executed in the same cycle, and the CPU fails to detect the dependency and performs the tag check for the load instruction. In this case, the forwarding is blocked on tag check faults.
\ ==Mitigation.== To prevent tag leakage in TIKTAG-v2 at the micro-architectural level, the CPU should be designed to either always allow or always block the store-to-load forwarding regardless of the tag check result. Always blocking the store-to-load forwarding may raise a performance issue. Instead, always allowing forwarding can effectively prevent the tag leakage with low-performance overheads. This would not introduce meltdown-like vulnerabilities, because tag mismatch occurs within the same exception level.
\ At the software level, the following mitigations can be applied to prevent TIKTAG-v2.
i) Speculation barrier: If a speculation barrier is inserted before CHECK, the CPU does not speculatively execute storeto-load forwarding on both tag match and mismatch. Thus, test_ptr is not cached regardless of the tag check result.
ii) Preventing Gadget Construction: If the store and load instructions in CHECK are not executed within 5 instructions, the store-to-load forwarding is always allowed on both cases, making test_ptr cached always. The potential gadgets can be modified to have more than 5 instructions between the store and load instructions in CHECK, by adding dummy instructions (e.g., nop) or reordering the instructions.
:::info Authors:
:::
:::info This paper is available on arxiv under CC 4.0 license.
:::
\
2025-12-24 15:10:52
How are you, hacker?
🪐Want to know what's trending right now?:
The Techbeat by HackerNoon has got you covered with fresh content from our trending stories of the day! Set email preference here.
## The Hidden Cost of AI: Why It’s Making Workers Smarter, but Organisations Dumber 
By @yuliiaharkusha [ 8 Min read ]
AI boosts individual performance but weakens organisational thinking. Why smarter workers and faster tools can leave companies less intelligent than before. Read More.
By @ipinfo [ 4 Min read ] IPinfo explains why ‘99% accurate IP data’ is misleading and how real accuracy requires ongoing measurement, transparency, and ProbeNet validation. Read More.
By @pressreleases [ 3 Min read ] HackerNoon announces its AI-detection partnership with GPTZero. This AI detector will now analyse 5000+ monthly blog post submissions reviewed by the editors. Read More.
By @ipinfo [ 9 Min read ] IPinfo reveals how most VPNs misrepresent locations and why real IP geolocation requires active measurement, not claims. Read More.
By @theakashjindal [ 7 Min read ] AI focus shifts from automation to augmentation ("Collaborative Intelligence"), pairing AI speed with human judgment to boost productivity. Read More.
By @hunterthomas [ 4 Min read ] SpaceX is going public in 2026 at a potential $1.5 trillion valuation. Read More.
By @cm0g4qf5i0000357s7xsi7icm [ 4 Min read ] As you read this letter, generative AIs like ChatGPT and DeepSeek are sweeping across the globe with millions of interactions per second. Read More.
By @btcwire [ 2 Min read ] The project has opened the $SEC token presale, including early staking opportunities offering up to 100% APY during the presale phase. Chat to Pay is an instant Read More.
By @oxylabs [ 9 Min read ] Compare the best Amazon Scraper APIs for 2025, analyzing speed, pricing, reliability, and features for scalable eCommerce data extraction. Read More.
By @tyingshoelaces [ 4 Min read ] Researchers found LLMs satisfy laws from thermodynamics. That changes everything. Read More.
By @tanyadonska [ 4 Min read ] Lost $240K to a slower competitor. Users said our 400ms queries 'felt too fast to be real.' Started adding artificial delays on purpose. Trust isn't speed. Read More.
By @patrickokare [ 9 Min read ] Every micro-interaction is silently recorded, analyzed, and monetized. Read More.
By @nathanbsmith729 [ 7 Min read ] Monday marked a new max drawdown of -45.85%. Read More.
By @3techpolls [ 5 Min read ] AI has been a major force in seemingly every career field. Now, it seems to have set its eyes somewhere else: Hollywood. Read More.
By @indrivetech [ 6 Min read ] How we built an n8n automation that reads Kibana logs, analyzes them with an LLM, and returns human-readable incident summaries in Slack Read More.
By @melissaindia [ 5 Min read ] Partner with Melissa to empower VARs and SIs with accurate data, seamless integrations, and scalable verification tools for smarter, faster client solutions. Read More.
By @stevebeyatte [ 7 Min read ] From no-code tools to enterprise AI systems, discover the top AI workflow automation platforms to use in 2026, and learn which solution fits your business needs Read More.
By @beldexcoin [ 3 Min read ] The obscura hardfork enabled Bulletproofs++ on the Beldex mainnet at block height 4939549. Learn what this upgrades means for you. Read More.
By @nathanbsmith729 [ 6 Min read ] I need YOUR help for the future! Read More.
By @escholar [ 4 Min read ]
A study shows developers often misjudge which testing techniques are most effective—leading to measurable drops in software quality. Read More.
🧑💻 What happened in your world this week? It's been said that writing can help consolidate technical knowledge, establish credibility, and contribute to emerging community standards. Feeling stuck? We got you covered ⬇️⬇️⬇️
ANSWER THESE GREATEST INTERVIEW QUESTIONS OF ALL TIME
We hope you enjoy this worth of free reading material. Feel free to forward this email to a nerdy friend who'll love you for it.
See you on Planet Internet! With love,
The HackerNoon Team ✌️
.gif)
2025-12-24 15:00:07
4. Finding Tag Leakage Gadgets
6.1. Attacking Chrome
\
The security of MTE random tag assignment relies on the confidentiality of the tag information per memory address. If the attacker can learn the tag of a specific memory address, it can be used to bypass MTE—e.g., exploiting memory corruption only when the tag match is expected. In this section, we present our approach to discovering MTE tag leakage gadgets. We first introduce a template for an MTE tag leakage gadget (§4.1) and then present a template-based fuzzing to discover MTE tag leakage gadgets (§4.2).
\ 4.1. Tag Leakage Template
We first designed a template for a speculative MTE tag leakage gadget, which allows the attacker to leak the tag of a given memory address through speculative execution (Figure 1). The motivation behind the template is to trigger MTE tag checks in a speculative context and observe the cache state after the speculative execution. If there is any difference between tag match and mismatch, the attackers can potentially leak the tag check results and infer the tag
\ value. Since tag mismatch during speculative execution is not raised as an exception, such an attempt is not detected. We assume the attacker aims to leak the tag Tm assigned to targetaddr. To achieve this, the attacker prepares two pointers: guessptr and testptr ( 1 ). guessptr points to targetaddr while embedding a tag Tg— i.e., guessptr = (Tg«56)|(targetaddr & ~(0xff«56)). testptr points to an attacker-accessible, uncached address with a valid tag.
\ Next, the attacker executes the template with guessptr and testptr ( 2 ). The template consists of three components in order: BR, CHECK, and TEST. BR encloses CHECK and TEST using a conditional branch, ensuring that CHECK and TEST are speculatively executed. In CHECK, the template executes a sequence of memory instructions to trigger MTE checks. In TEST, the template executes an instruction updating the cache status of test_ptr, observable by the attacker later.
\ Our hypothetical expectation from this template is as follows: The attacker first trains the branch predictor by executing the template with condptr storing 1 and guessptr containing a valid address and tag. After training, the attacker executes the template with condptr storing 0 and guessptr pointing to targetaddr with a guessed tag, causing speculative execution of CHECK and TEST. If the MTE tag matches in CHECK, the CPU would continue to speculatively execute TEST, accessing testptr and filling its cache line.
\ If the tags do not match, the CPU may halt the speculative execution of TEST, leaving the cache line of testptr unfilled. Consequently, the cache line of testptr would not be filled. After executing the template, the attacker can measure the access latency of testptr after execution, and distinguish the cache hit and miss, leaking the tag check result ( 3 ). The attacker can then brute-force the template executions with all possible Tg values to eventually leak the correct tag of targetaddr.
\ ==Results.== We tested the template on real-world ARMv8.5 devices, Google Pixel 8 and Pixel 8 pro. We varied the number and type of memory instructions in CHECK and TEST, and observed the cache state of test_ptr after executing the template. As a result, we identified two speculative MTE leakage gadgets, TIKTAG-v1 (§5.1) and TIKTAG-v2 (§5.2) that leak the MTE tag of a given memory address in both Pixel 8 and Pixel 8 pro.
\ 4.2. Tag Leakage Fuzzing
To automatically discover MTE tag leakage gadgets, we developed a fuzzer in a similar manner to the Spectre-v1 fuzzers [48]. The fuzzer generates test cases consisting of a sequence of assembly instructions for the speculatively executed blocks in the tag leakage template (i.e., CHECK and TEST). The fuzzer consists of the following steps: Based on the template, the fuzzer first allocates memory for condptr, guessptr, and testptr. condptr and guessptr point to a fixed 128-byte memory region individually. testptr points to a variable 128-byte aligned address from a 4KB memory region initialized with random values.
\ Then, the fuzzer randomly picks two registers to assign condptr and guessptr from the available registers (i.e., x0-x28). The remaining registers hold a 128-byte aligned address within a 4KB memory region or a random value. The fuzzer populates CHECK and TEST blocks using a predefined set of instructions (i.e., ldr, str, eor, orr, nop, isb) to reduce the search space. Given an initial test case, the fuzzer randomly mutates the test case by inserting, deleting, or replacing instructions to generate new test cases.
\ The fuzzer runs test cases in two phases:
(i) a branch training phase, with condptr storing true and guessptr containing a correct tag; and
(ii) a speculative execution phase, with with condptr storing false and guessptr containing either a correct or wrong tag. The fuzzer executes each test case twice. The first execution runs the branch training phase and then the speculative execution phase with the correct tag. The second execution is the same as the first, but the only difference is to run the speculative execution phase with the wrong tag.
\ After each execution, the fuzzer measures the access latency of a cache line and compares the cache state between the two executions. This process is repeated for each cache line of the 4KB memory region. If a notable difference is observed, the fuzzer considers the test case as a potential MTE tag leakage gadget.
\ ==Results.== We developed the fuzzer and tested it on the same ARMv8.5 devices. As a result, we additionally identified variants of TIKTAG-v1 (§5.1) that utilize linked list traversal. The fuzzer was able to discover the gadgets within 1-2 hours of execution without any prior knowledge of them.
:::info Authors:
:::
:::info This paper is available on arxiv under CC 4.0 license.
:::
\
