Technical Advisory
– Meta Quest System-Wide DoS via Unprotected Memory

All snippets below are decompiled from com.oculus.systemresource 201.0.0.129.1682.

The exported SystemResourceReceiver.onReceive() is the entry point. It dispatches on the intent action with no caller check (no getCallingUid(), no getCallingPackage(), no permission), so any sender reaches the SR_SET_MODE handler:

public void onReceive(Context context, Intent intent) {
    String action = intent.getAction();
    ...
    switch (action) {
        case "oculus.intent.action.SR_STOP":     stopAction(context);          break;
        case "oculus.intent.action.SR_SET_MODE": setMode(intent);              break;
        case "oculus.intent.action.SR_START":    startAction(context, intent); break;
        ...
    }
}

setMode(intent) reads the attacker-controlled MODE string. When it equals “MEM” it switches the view-model to the Memory section (which starts the allocation engine via the view-model lifecycle), then unconditionally calls both memory-pressure handlers:

private void setMode(Intent intent) {
    String stringExtra = intent.getStringExtra("MODE");      // attacker-controlled
    if (stringExtra == null) return;
    String upperCase = stringExtra.toUpperCase(Locale.ROOT);
    if (upperCase.equals("CPU")) {
        this.mMainViewModel.onShowSection(Section.CPU);
    } else if (upperCase.equals("MEM")) {
        this.mMainViewModel.onShowSection(Section.Memory);   // -> MemoryPressureViewModel.show()
    }
    setGrouping(intent);
    logLowUsage(intent);
    logThreads(intent);
    setOutputType(intent);
    addConstantPressure(intent);          // sync pressure
    addConstantPressureAsync(intent);     // async pressure
}

The two handlers read attacker-controlled boolean extras and invoke the memory-pressure operations directly. There is no validation of the caller and no limit on the request:

private void addConstantPressure(Intent intent) {
    if (intent.getBooleanExtra("ADD_CONSTANT_PRESSURE", false)) {
        this.mMainViewModel.getMemoryViewModel()
            .getMemoryPressureViewModel().waitForMemoryPressure();      // blocks until pressure reached
    }
}

private void addConstantPressureAsync(Intent intent) {
    if (intent.getBooleanExtra("ADD_CONSTANT_PRESSURE_ASYNC", false)) {
        this.mMainViewModel.getMemoryViewModel()
            .getMemoryPressureViewModel().enableMemoryPressure(true);   // fire-and-return
    }
}

• ADD_CONSTANT_PRESSURE → waitForMemoryPressure() — the synchronous variant; it blocks the receiver thread while pressure builds.
• ADD_CONSTANT_PRESSURE_ASYNC → enableMemoryPressure(true) — the asynchronous variant; it sets the engine into constant-pressure mode and returns immediately (the variant used in the PoC).
• Both extras default to false and are read with no sender identity check.

In MemoryPressureViewModel, enableMemoryPressure(true) puts the engine into ConstantPressure mode, and show() (reached via onShowSection(Section.Memory)) constructs and starts the engine:

public void enableMemoryPressure(boolean z) {
    this.mMemoryPressureEnabled = z;
    internalEnableMemoryPressure(z);     // z=true -> mConfiguration.mAllocationMode = ConstantPressure
}

public void show() { startAllocationEngine(); }

private void startAllocationEngine() {
    if (this.mContext == null) throw new RuntimeException("Unexpected null Context");  // why SR_START is required
    if (this.mConfiguration == null) {
        this.mConfiguration = new AllocationEngine.Configuration();
        internalEnableMemoryPressure(this.mMemoryPressureEnabled);
    }
    if (this.mAllocationEngine == null) {
        this.mAllocationEngine = new AllocationEngine(this.mConfiguration);
    }
    this.mAllocationEngine.start(this.mContext);
}

• mContext is only set by the earlier SR_START broadcast (initialize(context)); without it, startAllocationEngine() throws — which is why the attack needs the SR_START step first.
• internalEnableMemoryPressure(true) sets Configuration.mAllocationMode = ConstantPressure; the running engine thread then drives the full-memory-map allocation.

AllocationEngine.Configuration picks a per-device allocation target from a hard-coded table — on Quest 3S the engine targets an 8.6 GB (8,589,934,592-byte) full-memory map — and start() points the native layer at a backing file and spins up the allocation thread:

private static final AllocationSize[] sAllocationSizes = {
    new AllocationSize(4294967296L,  3758096384L),   // 4 GB
    new AllocationSize(6442450944L,  5368709120L),   // 6 GB
    new AllocationSize(12884901888L, 11811160064L),  // 12 GB
    new AllocationSize(8589934592L,  7516192768L),   // 8.6 GB  <-- selected on Quest 3S
    new AllocationSize(8589934592L,  7516192768L)
};

public final void start(Context context) {
    ...
    NativeMethods.setFilePath(
        new File(context.getExternalCacheDir(), "full_memory_map").getCanonicalPath());
    Thread thread = new Thread(() -> {
        while (!this.mStopThread && access$200(this)) {   // ConstantPressure -> allocateConstantPressure()
            Thread.sleep(1L);
        }
    }, "AllocationEngine");
    thread.start();
}

With the mode set to ConstantPressure, the engine thread enters allocateConstantPressure(), which reads the entire 8.6 GB map back via NativeMethods.readPartialMemoryMap(…) in a loop, holding the pages resident and driving physical memory to exhaustion. No allocation cap, rate limit, caller check, or permission gate exists anywhere along this path, and the target size is read from device hardware parameters rather than bounded against available memory — so the single mapping exceeds the headset’s 8 GB of RAM and forces the LMK cascade shown in Figure 2.