Merge pull request #2473 from HackTricks-wiki/research_update_src_binary-exploitation_common-binary-protections-and-bypasses_memory-tagging-extension-mte_20260706_154514

Research Update Enhanced src/binary-exploitation/common-bina...

Author: carlospolop

src/binary-exploitation/common-binary-protections-and-bypasses/memory-tagging-extension-mte.md

@@ -28,62 +28,129 @@ Therefore, this allows up to **16 different tag values**.
 
 Every **16B of physical memory** have a corresponding **memory tag**.
 
-The memory tags are stored in a **dedicated RAM region** (not accessible for normal usage). Having 4bits tags for every 16B memory tags up to 3% of RAM.
+The memory tags are stored in a **dedicated RAM region** (not accessible for normal usage). Having 4-bit tags for every 16B of memory costs roughly **3% of RAM**.
 
 ARM introduces the following instructions to manipulate these tags in the dedicated RAM memory:
 
 ```asm
 STG [<Xn/SP>], #<simm>    Store Allocation (memory) Tag
-LDG <Xt>, [<Xn/SP>]       Load Allocatoin (memory) Tag
+LDG <Xt>, [<Xn/SP>]       Load Allocation (memory) Tag
 IRG <Xd/SP>, <Xn/SP>      Insert Random [pointer] Tag
+ADDG <Xd/SP>, <Xn/SP>, #<uimm>, #<uimm>
+SUBG <Xd/SP>, <Xn/SP>, #<uimm>, #<uimm>
 ...
 ```
 
 ## Checking Modes
 
 ### Sync
 
-The CPU check the tags **during the instruction executing**, if there is a mismatch, it raises an exception (SIGSEGV with `SEGV_MTESERR`) and you immediately know the exact instruction and address.\
-This is the slowest and most secure because the offending load/store is blocked.
+The CPU checks the tags **during instruction execution**. If there is a mismatch, it raises an exception (`SIGSEGV` with `SEGV_MTESERR`) and you immediately know the exact instruction and address.\
+This is the slowest and most secure mode because the offending load/store is blocked before its effects become architecturally visible.
 
 ### Async
 
-The CPU check the tags **asynchronously**, and when a mismatch is found it sets an exception bit in one of the system registers. It's **faster** than the previous one but it's **unable to point out** the exact instruction that cause the mismatch and it doesn't raise the exception immediately (`SIGSEGV` with `SEGV_MTEAERR`), giving some time to the attacker to complete his attack.
+The CPU checks the tags **asynchronously**. When a mismatch is found it sets state in a fault status register and the process is usually killed on the **next kernel entry** (`SIGSEGV` with `SEGV_MTEAERR`). It's **faster** than SYNC but it's **unable to point out** the exact instruction that caused the mismatch, and some attacker-visible effects may already have happened before the signal is delivered.
 
-### Mixed
+### Asymmetric / per-core upgrades
 
-Per-core preferences (for example writing `sync`, `async` or `asymm` to `/sys/devices/system/cpu/cpu*/mte_tcf_preferred`) let kernels silently upgrade or downgrade per-process requests, so production builds usually request ASYNC while privileged cores force SYNC when workload allows it.
+Recent Arm/Android deployments also use **ASYMM** (synchronous reads, asynchronous writes) and **per-core preferred modes**. For example, writing `sync`, `async` or `asymm` to `/sys/devices/system/cpu/cpu*/mte_tcf_preferred` can silently upgrade a process that only requested ASYNC when it lands on a stricter core.
+
+This matters during exploitation because the **manifest / `prctl()` request is not always the effective mode** you end up attacking.
+
+## Quick Recon / Enable Checks
+
+From an exploit-dev perspective the first question is usually not "does the CPU support MTE?" but **"is this specific process actually running with tagged mappings and enforced checks?"**
+
+### Linux / Android quick checks
+
+```bash
+grep -i mte /proc/cpuinfo
+readelf -n ./target | grep -E 'AARCH64_FEATURE_1_(BTI|PAC)'
+rg -n 'memtagMode|PR_SET_TAGGED_ADDR_CTRL|PROT_MTE' .
+```
+
+In code or during reversing, look for these indicators:
+
+- **`HWCAP2_MTE`** advertised to userspace
+- **`PROT_MTE`** used in `mmap()` / `mprotect()`
+- **`prctl(PR_SET_TAGGED_ADDR_CTRL, ...)`** with `PR_MTE_TCF_SYNC` / `PR_MTE_TCF_ASYNC`
+- Android manifests requesting **`android:memtagMode="sync|async"`** (and note that `readelf` is useful for **BTI/PAC**, but not as a generic detector for whether MTE is enabled for a process)
+
+A minimal userspace mapping looks like:
+
+```c
+void *p = mmap(NULL, 0x1000, PROT_READ | PROT_WRITE | PROT_MTE,
+               MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+prctl(PR_SET_TAGGED_ADDR_CTRL,
+      PR_TAGGED_ADDR_ENABLE | PR_MTE_TCF_SYNC,
+      0, 0, 0);
+```
+
+On Android, stack tagging is not automatic for arbitrary native code: if a lab or target was compiled with **`-fsanitize=memtag`** and a **`-fsanitize-memtag-mode=sync`** link mode, stack bugs that would normally stay invisible to heap-only MTE may now fault reliably. For a concrete exploitation scenario where MTE can break the overflow stage before shellcode/ROP, check [the ARM64 stack shellcode notes](../stack-overflow/stack-shellcode/stack-shellcode-arm64.md).
 
 ## Implementation & Detection Examples
 
 Called Hardware Tag-Based KASAN, MTE-based KASAN or in-kernel MTE.\
-The kernel allocators (like `kmalloc`) will **call this module** which will prepare the tag to use (randomly) attach it to the kernel space allocated and to the returned pointer.
+The kernel allocators (like `kmalloc`) will **call this module** which will prepare the tag to use (randomly) and attach it to the allocated kernel memory and to the returned pointer.
 
-Note that it'll **only mark enough memory granules** (16B each) for the requested size. So if the requested size was 35 and a slab of 60B was given, it'll mark the first 16\*3 = 48B with this tag and the **rest** will be **marked** with a so-called **invalid tag (0xE)**.
+Note that it'll **only mark enough memory granules** (16B each) for the requested size. So if the requested size was 35 and a slab of 60B was given, it'll mark the first `16*3 = 48B` with this tag and the **rest** will usually be **marked** with a special **invalid tag** (commonly `0xE` in current Linux KASAN/MTE discussions).
 
-The tag **0xF** is the **match all pointer**. A memory with this pointer allows **any tag to be used** to access its memory (no mismatches). This could prevent MTE from detecting an attack if that tag is being used in the attacked memory.
+A very important nuance is that **kernel and userspace do not expose exactly the same behavior**:
 
-Therefore there are only **14 values** that can be used to generate tags as 0xE and 0xF are reserved, giving a probability of **reusing tags** to 1/17 -> around **7%**.
+- In the **Linux kernel**, the current implementation has important special cases around **tag `0xF`** (`TCMA1` / "match-all" style behavior in several paths), so forged pointers carrying `0xF` are especially interesting during kernel exploitation.
+- In **normal userspace Linux MTE**, there is **no general-purpose match-all logical tag** you can rely on from an unprivileged process.
 
-If the kernel accesses the **invalid tag granule**, the **mismatch** will be **detected**. If it accesses another memory location and the **memory has a different tag** (or the invalid tag) the mismatch will also be detected. If the attacker is lucky and the memory is using the same tag, it won't be detected. Chances are around 7%.
+Therefore, if the implementation reserves `0xE` and `0xF`, there are effectively **14 practical tag values**, so a blind tag re-use or reallocation collision is around **`1/14` (~7.1%)** per try instead of being a deterministic bypass.
 
-Another bug occurs in the **last granule** of the allocated memory. If the application requested 35B, it was given the granule from 32 to 48. Therefore, the **bytes from 36 to 47 are using the same tag** but they weren't requested. If the attacker accesses **these extra bytes, this isn't detected**.
+If the kernel accesses the **invalid-tag granule**, the **mismatch** will be **detected**. If it accesses another memory location and the **memory has a different tag** (or the invalid tag) the mismatch will also be detected. If the attacker is lucky and the memory is using the same tag, it won't be detected.
 
-When **`kfree()`** is executed, the memory is retagged with the invalid memory tag, so in a **use-after-free**, when the memory is accessed again, the **mismatch is detected**.
+Another blind spot occurs in the **last granule** of the allocated memory. If the application requested 35B, it was given the granule from 32 to 48. Therefore, the **bytes from 36 to 47 are using the same tag** but they weren't requested. If the attacker accesses **these extra bytes, this isn't detected**. This is one of the most important practical MTE limitations: **intra-granule overflows are invisible** unless another software mechanism adds extra checking.
 
-However, in a use-after-free, if the same **chunk is reallocated again with the SAME tag** as previously, an attacker will be able to use this access and this won't be detected (around 7% chance).
+When **`kfree()`** is executed, the memory is usually retagged, so in a **use-after-free**, when the memory is accessed again, the **mismatch is detected**.
 
-Moreover, only **`slab` and `page_alloc`** uses tagged memory but in the future this will also be used in `vmalloc`, `stack` and `globals` (at the moment of the video these can still be abused).
+However, in a use-after-free, if the same **chunk is reallocated again with the same tag** as previously, an attacker will be able to keep using the stale pointer and this won't be detected (probabilistic bypass).
 
-When a **mismatch is detected** the kernel will **panic** to prevent further exploitation and retries of the exploit (MTE doesn't have false positives).
+Moreover, only **`slab` and `page_alloc`** are broadly covered in current Linux kernel deployments; attackers should still pay attention to **untagged paths** such as `vmalloc`, stacks, globals, DMA-backed buffers, or mixed subsystems depending on kernel version and configuration.
+
+When a **mismatch is detected** the kernel may **panic** or at least kill the current task, depending on the exact mode/policy, to prevent further exploitation and retries.
+
+## Exploit-Relevant Debugging Primitives
+
+Linux exposes several interfaces that are very useful both for defenders and for attackers building local PoCs:
+
+- **`PTRACE_PEEKMTETAGS` / `PTRACE_POKEMTETAGS`** let a tracer read or write allocation tags in a tracee.
+- A thread can temporarily disable checking for its own accesses with **`PSTATE.TCO`**. This is not a pre-exploitation bypass by itself, but it matters once you already have controlled execution in the compromised thread.
+- In Android app triage, `debuggerd <PID> | head -30 | grep tagged_addr` is a quick way to see which MTE fault modes a process requested.
+
+These are not "remote bypasses", but they are extremely practical when building **local privilege-escalation exploits, debugger-assisted PoCs, or MTE-aware fuzzing harnesses**.
+
+## Practical Bypass Notes
+
+Project Zero's MTE testing/use-case analysis is still a good mental model:
+
+- **Known-tag bypasses**: if you can **leak the tag**, the probabilistic part of MTE mostly disappears.
+- **Unknown-tag bypasses**: even without leaking the tag, **implementation limits** can leave exploit paths where an invalid access still gives enough post-corruption leverage.
+- **ASYNC / ASYMM are softer targets** than SYNC because the exploit may only need to finish before the next kernel entry, signal delivery, or scheduler event.
+
+This is especially relevant for browser, IPC and kernel exploits where the attacker can try to keep the whole corruption chain inside one "quiet" execution window.
 
 ### Speculative Tag Leakage (TikTag)
 
-*TikTag* (2024) demonstrated two speculative execution gadgets (TIKTAG-v1/v2) able to leak the 4-bit allocation tag of any address in <4 seconds with >95% success. By speculatively touching attacker-chosen cache lines and observing prefetch-induced timing, an attacker can derandomize the tag assigned to Chrome processes, Android system services, or the Linux kernel and then craft pointers carrying the leaked value. Once the tag space is brute-forced away, the probabilistic granule reuse assumptions (`≈7%` false-negative rate) collapse and classic heap exploits (UAF, OOB) regain near-100% reliability even when MTE is enabled. The paper also ships proof-of-concept exploits that pivot from leaked tags to retagging fake slabs, illustrating that speculative side channels remain a viable bypass path for hardware tagging schemes.
+*TikTag* (2024) demonstrated two speculative execution gadgets (**TIKTAG-v1/v2**) able to leak the 4-bit allocation tag of arbitrary addresses with **>95% success** in **less than 4 seconds**. The key idea is to speculatively trigger a tag-checked access, use a cache side channel to learn whether the access matched, and iterate over candidate tags until the correct one is recovered.
+
+That result is important because it upgrades MTE from a **probabilistic mitigation** to something an attacker may **systematically derandomize**:
+
+1. Leak the tag of the vulnerable object.
+2. Leak the tag of the target object.
+3. Reallocate / groom until they match.
+4. Trigger the UAF/OOB with the now-correct tag.
+
+The paper demonstrates this against **Google Chrome** and the **Linux kernel**. Also, research such as **StickyTags** independently observed that speculative probing of tag-check success/failure is a real concern, reinforcing that **tag confidentiality** is one of the main assumptions behind MTE's offensive value.
 
 ## References
 
-- [https://www.youtube.com/watch?v=UwMt0e_dC_Q](https://www.youtube.com/watch?v=UwMt0e_dC_Q)
+- [Memory Tagging Extension (MTE) in AArch64 Linux](https://docs.kernel.org/arch/arm64/memory-tagging-extension.html)
 - [TikTag: Breaking ARM's Memory Tagging Extension with Speculative Execution](https://arxiv.org/abs/2406.08719)
 
 {{#include ../../banners/hacktricks-training.md}}