Threat reportVulnerabilityTL-2026-2044

Jamf Threat Labs: ARM MTE and Apple Memory Integrity Enforcement Expose iOS Kernel Use-After-Free in Networking Subsystem

mediumTRACKING

Jamf Threat Labs (TL-2026-2044) is a medium-severity software vulnerability, first published 2026-06-10. It has no confirmed attribution, affects Apple iPhone 17, maps to 9 MITRE ATT&CK techniques (T1082, T1106, T1499.004), and is covered by 9 detection rules and 8 indicators of compromise.

Severity
MEDIUMAssessed severity
CVEs
0None referenced
Techniques
9MITRE ATT&CK
Actors
0Not attributed
Detection rules
9SPL · KQL · Sigma
IOCs
8Indicators of compromise

Key facts for TL-2026-2044

Threat ID
TL-2026-2044
Severity
MEDIUM
Status
TRACKING
Category
VULNERABILITY
First published
Last reviewed
Attribution confidence
LOW
Motivation
UNKNOWN
Detection rules
9
Indicators of compromise
8

Malware and tooling in Jamf Threat Labs

Malware and tooling: Corellium, kalloc_type / xzone_malloc / libpas

How Jamf Threat Labs works

Jamf Threat Labs used ARM's Memory Tagging Extension (MTE) and Apple's Memory Integrity Enforcement (MIE) on iPhone 17-generation hardware (A19/A19 Pro, iOS 26.4) to root-cause a real use-after-free race condition in the iOS kernel's per-process network policy subsystem, where memory is freed while a per-object mutex is still held. The bug was silently masked on non-MTE hardware for years by allocator zeroing but produces consistent, reproducible kernel panics on MTE-enabled devices; no CVE has been assigned, no public PoC was released, and no in-the-wild exploitation is claimed.

On 2026-06-10, Jamf Threat Labs researchers Nir Avraham and Hu Ke published a technical case study on how ARM's Memory Tagging Extension (MTE), as implemented via Apple's Memory Integrity Enforcement (MIE), surfaces previously invisible kernel memory-safety bugs. Their MTE-based differential analysis pipeline began flagging an anomalous kernel-panic signal in recent months, which the team root-caused to a race condition deep in the subsystem that manages per-process network policy objects.

The mechanism: the subsystem uses a coarse reader-writer lock (Lock A) protecting a global tree-structured registry of policy objects, and a finer-grained per-object mutex (Lock B) protecting an individual object's internal state. Because the two locks cannot safely be nested in either direction (deadlock risk), one thread performs an object lookup under Lock A, releases it, and retains a raw pointer to the object; concurrently, a second thread acquires the object's own mutex (Lock B) and frees the object's backing memory while still holding that mutex. The first thread then dereferences the now-stale pointer through the unprotected window between the coarse lock's release and the fine-grained lock's lifecycle -- a classic use-after-free.

On non-MTE hardware this was a non-event: XNU's zone allocator (kalloc/kfree) zeroed freed memory, and the vulnerable code path happened to tolerate a zero-valued read, so the bug "has been executing somewhere between 'occasionally' and 'frequently' in production for an unknown length of time" with zero observable effect. On MTE-enabled iPhone 17/17 Pro/17 Pro Max/iPhone Air hardware (A19/A19 Pro chips), Apple's Enhanced MTE (EMTE, FEAT_MTE4) performs synchronous tag checking on every access -- unlike Google Pixel's asynchronous MTE mode, which logs faults rather than raising them immediately, Apple deliberately chose synchronous mode for MIE. When the stale pointer is dereferenced, the freed allocation's 4-bit tag (stored in bits 59:56 of the 64-bit address, exploiting the ARM64 Top Byte Ignore feature) no longer matches the pointer's tag, producing a synchronous tag-check fault. In the crash Jamf analyzed, the ARM64 X26 register held the stale pointer carrying its original allocation-time tag (0xF6 in their example), the Link Register (LR) pointed into the kernel mutex slow-path function lck_mtx_lock_contended (indicating the crash occurred mid-mutex-contention), the Exception Syndrome Register (ESR) encoded the tag mismatch, and the XNU thread-scheduling flag TH_SFLAG_RW_PROMOTED was set on the faulting thread -- evidence it had been priority-promoted due to reader-writer lock contention, confirming the race's concurrency signature. Tag writes/validation rely on the ARM64 STG/ST2G (Store Tag) instructions and the CASA atomic compare-and-swap instruction used in the mutex acquisition path. The result is a reliable, deterministic kernel panic rather than silent corruption.

Jamf built a working proof-of-concept that creates the relevant kernel network-policy objects from an unprivileged, sandboxed app, triggers qualification from a content filter, and rapidly destroys the objects to force the race -- precisely the pattern that produced the original panic, and demonstrating the vulnerable path is reachable without special entitlements. Jamf also notes a structural limit on MTE's exploit-mitigation value even where it does apply: a single tag has only 1-in-16 (6.25%) collision probability per bypass attempt, so multi-step exploit chains that need several successful bypasses in sequence become exponentially less reliable (roughly 0.024% for a three-step chain) -- but MTE is explicitly not a complete solution, since logical bugs, same-zone type confusions, and non-corruption info leaks fall outside its scope. For responsible-disclosure reasons the researchers withheld the exact code path and subsystem name, describing only "the shape of the bug," and did not publish PoC code. No CVE has been assigned to this specific finding as of publication.

This sits within Apple's broader MIE rollout: MIE (announced 2025-09-09, shipped with the iPhone 17 lineup on 2025-09-19) combines synchronous-mode EMTE with secure typed allocators (kalloc_type in the kernel, xzone_malloc at user level, and WebKit's libpas, all operating at 16KB page-level granularity to prevent attackers from controlling allocation positioning) plus Tag Confidentiality Enforcement (TCE) -- built via a Secure Page Table Monitor and frequent re-seeding of pseudo-random tag generators -- to defeat speculative-execution tag-leak attacks such as the previously published TikTag research, and to mitigate a Spectre V1-class side channel via forced type segregation. Coverage spans the kernel and 70+ userland processes, including apps identified as likely exploitation vectors (social/messaging apps); third-party apps can opt in via an Xcode entitlement. Apple states MIE explicitly targets the memory-corruption primitives that mercenary spyware chains (the only observed system-level iOS attack class) universally rely on for kernel-level access, and that in Apple's own evaluation MIE "cut off so many exploit steps at a fundamental level that it was not possible to restore the chains by swapping in new bugs." Corellium, a commonly used iOS emulation platform for security research, does not currently support MTE/MIE emulation, meaning this bug class is only reproducible on physical iPhone 17-generation hardware.

MITRE ATT&CK techniques used in TL-2026-2044

Discovery

T1082 System Information Discovery

Execution

T1106 Native API

Impact

T1499.004 Application or System Exploitation; T1529 System Shutdown/Reboot

Resource Development

T1587.004 Exploits; T1588.006 Vulnerabilities

Reconnaissance

T1592.001 Hardware; T1592.002 Software; T1595.002 Vulnerability Scanning

Affected products and versions in Jamf Threat Labs

  • Apple — iPhone 17
    Vulnerable versions: iOS 26.4 (A19)
  • Apple — iPhone 17 Pro
    Vulnerable versions: iOS 26.4 (A19 Pro)
  • Apple — iPhone 17 Pro Max
    Vulnerable versions: iOS 26.4 (A19 Pro)
  • Apple — iPhone Air
    Vulnerable versions: iOS 26.4 (A19)

Remediation for Jamf Threat Labs

Patches

  • None issued as of 2026-06-10; no CVE assigned

Immediate actions

  • No vendor patch or CVE exists yet; the only current mitigation is MIE itself, which fails closed via a deterministic kernel panic rather than allowing silent memory corruption on affected hardware
  • Track Apple security-content advisories for the next iOS release for a fix to this networking-subsystem use-after-free

Workarounds

  • None published; MIE/EMTE is a non-optional, always-on hardware feature on supported devices and cannot be user-disabled

Longer-term hardening

  • Prioritize fleet rollout of MTE/EMTE-capable hardware (iPhone 17-generation and later) given its demonstrated ability to surface kernel bugs invisible on legacy silicon
  • Extend MTE-based differential testing (MTE-enabled vs non-MTE devices under identical workloads) to other kernel subsystems beyond networking to find similarly masked bugs
  • Monitor Jamf Threat Labs and Apple Security Research disclosures for CVE assignment and follow-on technical detail
  • Do not treat MTE/MIE as a complete mitigation: it does not cover logical bugs, same-zone type confusions, or non-corruption information leaks, so defense-in-depth (typed allocators, sandboxing, entitlement review) remains necessary

Weaknesses (CWE) in Jamf Threat Labs

CWE-416, CWE-362

Timeline of Jamf Threat Labs

  • Apple ships Pointer Authentication Codes (PAC) in the A12 Bionic chip, the hardware code-flow-integrity mitigation Apple cites as the predecessor to its later memory-tagging work.
  • Jamf Threat Labs previously published a related class of iOS/OSX content-filter kernel use-after-free analysis with PoC, establishing the content-filter subsystem as a recurring source of kernel UAF bugs later revisited by the MTE-based research.
  • Apple unveils the iPhone 17 lineup (iPhone 17, 17 Pro, 17 Pro Max, iPhone Air) and publishes its Memory Integrity Enforcement (MIE) technical blog, disclosing Enhanced MTE (EMTE/FEAT_MTE4) protection for the kernel and 70+ userland processes on the new A19/A19 Pro chips, alongside secure typed allocators (kalloc_type, xzone_malloc, libpas) and Tag Confidentiality Enforcement.
  • iPhone 17, iPhone 17 Pro, iPhone 17 Pro Max and iPhone Air become generally available with MIE enabled by default and non-optional -- the first consumer hardware capable of surfacing this bug class.
  • Apple releases iOS 26.4, the OS build on which Jamf Threat Labs' proof-of-concept reliably reproduces the networking-subsystem race condition and triggers kernel panics on MTE-enabled hardware.
  • Jamf Threat Labs publishes 'ARM MTE, Apple MIE, and iOS Kernel Memory Safety Vulnerability Research,' authored by Nir Avraham and Hu Ke, documenting the use-after-free with sanitized technical detail for responsible-disclosure reasons; no CVE assigned, no public PoC released, no in-the-wild exploitation claimed.
  • Jamf Threat Labs states the anomalous kernel-panic signal began appearing in its MTE-based differential analysis pipeline 'in recent months' prior to publication, ultimately root-caused to a reader-writer-lock/per-object-mutex race in the network policy subsystem.

Sources cited for Jamf Threat Labs

Detection coverage for TL-2026-2044

As of 2026-06-10, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-2044 across Splunk SPL, Microsoft KQL and Sigma, covering 8 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.

9 detection rules (Splunk SPL, Microsoft KQL, Sigma) · Blue and above. Compare plans
8 indicators of compromise · Red and above. Compare plans

Threadlinqs Intelligence — Real-Time Threat Detection Platform

[ 0 threats ] [ 0 det ] [ CRIT: 0 ] [ HIGH: 0 ]
// threat_feed
$ sort --newest
Showing all threats

Live intelligence console

Threat level
Fig. 01 · Threat weatherIndexing the archive…
1 square = 1 threat · click to open

Latest Threats