[11] libpas MTE Lockdown Mode initialization bypass

Severity: Medium | Component: libpas (bmalloc) MTE configuration | 1b1e4d0

Rated Medium because the observable effect is MTE hardening being silently disabled for the CaptivePortal WebContent process even when the user has opted into Lockdown Mode — weakening a defense-in-depth mitigation rather than directly enabling exploitation, but in a process that handles untrusted network traffic.

The sysctl check for Lockdown Mode state was always returning 0 due to a sandbox restriction on the process. The fix adds a fallback process name check for the CaptivePortal WebContent process.

Source/bmalloc/libpas/src/libpas/pas_mte_config.c

Patch Details

The fix adds a secondary check: if the process name (via getprogname()) matches "com.apple.WebKit.WebContent.CaptivePortal", is_lockdown_mode is set to true regardless of the sysctl result. The two checks are OR'd together.

Silent failure of a privilege-gated system call causing a security hardening feature to be unconditionally disabled.

Background

ARM MTE (Memory Tagging Extensions) is a hardware feature that assigns random tags to memory allocations and checks them on every access, catching use-after-free and out-of-bounds accesses at the hardware level. Lockdown Mode (LDM) is an opt-in iOS/macOS security mode that enables additional hardening for high-risk users. In WebKit's libpas allocator, MTE tagging in the WebContent process is disabled by default for performance reasons, but is re-enabled when the process is considered "hardened" — which occurs when Lockdown Mode is active or the process is an EnhancedSecurity variant. The CaptivePortal WebContent process handles web content displayed in captive portal network authentication flows — untrusted network environments where exploitation risk is elevated.

Analysis

The sysctlbyname call to query security.mac.lockdown_mode_state was blocked by the sandbox policy applied to the WebContent process (as the commit message states). The call always returned a negative value, so the >= 0 check always failed, and ldmState was never read. As a result, config->is_lockdown_mode was always set to false, even when the device was actually in Lockdown Mode. Downstream, is_lockdown_mode determines whether MTE tagging should be enabled. With it stuck at false, the CaptivePortal WebContent process never received MTE hardening, defeating a key exploit mitigation for Lockdown Mode users.

Audit directions