# Null Pointer Dereference in ExecuTorch BackendDelegate::GetProcessedData() via Missing BackendDelegate.processed (.pte)

**Target:** ExecuTorch 1.3.1 (.pte, huntr Model File Vulnerability program)
**Severity:** Low-Medium (Denial of Service)
**CWE:** CWE-476 (NULL Pointer Dereference)
**Component:** `runtime/executor/method.cpp`
**Authentication Required:** No — requires a victim application to load a `.pte` file whose method has a backend delegate entry referencing a registered/available backend, while omitting the delegate's `processed` field (a routine deployment configuration, requiring nothing more than one compiled-in hardware-acceleration backend).

## Summary

`BackendDelegate::GetProcessedData()` dereferences `delegate.processed()` — the whole optional `BackendDelegateDataReference` field on a `BackendDelegate` table — via `->location()`, with no null guard. A `.pte` file with an `ExecutionPlan.delegates` entry whose `id` matches a backend the victim has registered and made available, but which omits the `processed` field entirely, crashes the moment `Method::init()` resolves that delegate — before any execution begins, and before compile specs are even examined.

This is the fifth distinct null-pointer-dereference bug found in this session's investigation of ExecuTorch's `BackendDelegate::Init()` delegate-resolution call chain (`method.cpp`), and the *shallowest*: unlike the sibling `CompileSpec.key`/`CompileSpec.value` findings (which require a populated `compile_specs` list) or the `Operator.overload` finding (which requires `EXECUTORCH_ENABLE_LOGGING=ON`), this crash needs only a bare `BackendDelegate.id` field with `processed` omitted — no compile specs, no logging flag, no kernel execution.

Confirmed **twice independently**: once against a freshly rebuilt, wholly unmodified pristine 1.3.1 source tree, and once against a separately-patched build (with unrelated compile-spec fixes applied), ruling out any local-patch artifact or coincidental interaction with prior fixes.

## Vulnerability Details

`runtime/executor/method.cpp`'s `BackendDelegate::GetProcessedData()`:

```cpp
static Result<FreeableBuffer> GetProcessedData(
    const executorch_flatbuffer::BackendDelegate& delegate,
    const Program* program) {
  const executorch_flatbuffer::BackendDelegateDataReference* processed =
      delegate.processed();
  switch (processed->location()) {   // <-- crash site: processed may be null
    case executorch_flatbuffer::DataLocation::INLINE: {
      ...
```

`BackendDelegate.processed` is declared as an optional table field in `schema/program.fbs`:

```
table BackendDelegate {
  id: string;
  processed: BackendDelegateDataReference;
  compile_specs: [CompileSpec];
}
```

None of the three fields are marked `required`, so a well-formed `BackendDelegate` entry can legally specify only `id` and omit `processed` entirely.

`GetProcessedData()` is called from `BackendDelegate::Init()`:

```cpp
static Error Init(
    const executorch_flatbuffer::BackendDelegate& delegate,
    const Program* program,
    BackendInitContext& backend_init_context,
    BackendDelegate* out) {
  ...
  BackendInterface* backend = get_backend_class(backend_id);
  ...
  ET_CHECK_OR_RETURN_ERROR(backend->is_available(), ...);

  // Get the delegate data.
  Result<FreeableBuffer> processed_data = GetProcessedData(delegate, program);
```

`GetProcessedData()` is the **first accessor called** in `Init()` after the backend-lookup checks — reached unconditionally for every delegate entry, unlike `PopulateCompileSpecs()` which is only invoked when `delegate.compile_specs() != nullptr`. This makes the bug the most directly reachable of the five delegate-resolution null-derefs found in this investigation.

`BackendDelegate::Init()` is in turn called from `Method::init()`'s delegate-resolution loop, reached during ordinary method **loading** (`Program::load_method()`), for any delegate whose registered backend is available (`get_backend_class(id) != nullptr && backend->is_available()`) — a standard condition for any deployment that has compiled in and registered at least one hardware-acceleration backend.

## Steps to Reproduce

### Environment
Linux x86-64, ExecuTorch 1.3.1 pristine source, clang-16, CMake, Ninja. No authentication, no host access.

### 1. Build ExecuTorch with sanitizers

```bash
cmake -B build_asan -DCMAKE_BUILD_TYPE=RelWithDebInfo \
  -DCMAKE_CXX_FLAGS="-fsanitize=address,undefined -fno-omit-frame-pointer -fno-sanitize-recover=all" \
  -DCMAKE_C_FLAGS="-fsanitize=address,undefined -fno-omit-frame-pointer -fno-sanitize-recover=all" \
  -DEXECUTORCH_BUILD_EXTENSION_FLAT_TENSOR=ON .
cmake --build build_asan -j
```

### 2. Build the execute-level harness (`poc/harness_execute_fuzzer.cpp`, included in this report)

This harness registers fake backends under common names (`XnnpackBackend`, `QnnBackend`, `CoreMLBackend`, etc.) that trivially succeed on `init()`, letting us exercise the real `BackendDelegate::Init()` code path:

```bash
export ET_PARENT=/path/to/parent-of-executorch
C10_INC="$ET_SRC/runtime/core/portable_type/c10"
INCLUDES="-I$ET_PARENT -I$ET_BUILD -I$ET_BUILD/schema/include -I$ET_BUILD/extension/flat_tensor/include -I$ET_BUILD/third-party/flatc_ep/include -I$C10_INC"

clang++-16 -std=c++17 -fsanitize=fuzzer,address,undefined -fno-omit-frame-pointer -fno-sanitize-recover=all \
  $INCLUDES -DFLATBUFFERS_MAX_ALIGNMENT=1024 -DC10_USING_CUSTOM_GENERATED_MACROS \
  -c poc/harness_execute_fuzzer.cpp -o harness.o

clang++-16 -fsanitize=fuzzer,address,undefined -o poc_harness harness.o \
  "$ET_BUILD/extension/data_loader/libextension_data_loader.a" \
  "$ET_BUILD/libexecutorch_core.a"
```

### 3. PoC file

`poc/poc_backend_delegate_processed_null.pte` (248 bytes, **included in this report — sha256 `0377b7f4078dda503e5f2ae3e8b69f8332081f065964a45098fb0d95bba4b36`**) contains:
- One `ExecutionPlan` named `"forward"` with empty values/inputs/outputs/chains/operators
- One `BackendDelegate` entry with `id = "XnnpackBackend"` and **no `processed` field at all**
- The minimal `constant_segment`/`segments` boilerplate required by this build's `ET_ENABLE_DEPRECATED_CONSTANT_BUFFER=0` configuration

Built directly from the project's own `flatc` + `schema/program.fbs`, no manual byte-patching required.

### 4. Trigger the crash

```bash
export ASAN_OPTIONS="abort_on_error=1:symbolize=0"
export UBSAN_OPTIONS="halt_on_error=1:print_stacktrace=0"
./poc_harness -timeout=5 -runs=0 poc/poc_backend_delegate_processed_null.pte
```

### Expected result (secure behavior)
`Method::init()` should return `Error::InvalidProgram` cleanly when a delegate entry omits the `processed` field, rather than crashing while reading its `location`.

### Actual result — verified against BOTH an independently rebuilt pristine build AND a separately-patched build

```
runtime/executor/method.cpp:198:24: runtime error: member call on null pointer of type 'executorch_flatbuffer::BackendDelegateDataReference'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior runtime/executor/method.cpp:198:24 in
==<pid>== ERROR: libFuzzer: deadly signal
    BackendDelegate::GetProcessedData (method.cpp:198)
    BackendDelegate::Init (method.cpp:97)
    Method::init (method.cpp:971)
    Method::load (method.cpp:862)
```

**Reproduced 3/3 identical runs** against both the pristine rebuild and the separately-patched build:
```
run 1: member call on null pointer of type 'executorch_flatbuffer::BackendDelegateDataReference'
run 2: (identical)
run 3: (identical)
```

## Impact

**Who is affected:** Any application calling `Program::load_method()` on a method whose delegates include an entry that omits the `processed` field, where the victim has registered a backend under a name the attacker can predict (most deployments register at least one real hardware-acceleration backend). This is triggered during **loading**, not execution.

**What the attacker can do:** Cause a deterministic crash during method loading, unconditionally (no build-flag dependency, no compile_specs list required — the minimal possible malformed-delegate PoC).

**What's at risk:** Availability only.

**Why not Critical:** Controlled null-pointer dereference, no memory corruption or code execution demonstrated.

## Suggested Remediation

```cpp
static Result<FreeableBuffer> GetProcessedData(
    const executorch_flatbuffer::BackendDelegate& delegate,
    const Program* program) {
  const executorch_flatbuffer::BackendDelegateDataReference* processed =
      delegate.processed();
  ET_CHECK_OR_RETURN_ERROR(
      processed != nullptr,
      InvalidProgram,
      "Missing processed field for backend delegate %s",
      delegate.id() != nullptr ? delegate.id()->c_str() : "<unknown>");
  switch (processed->location()) {
    ...
```

**Design recommendation:** consider validating at `Program::load()` time (in `validate_program()`, `runtime/executor/program_validation.cpp`) that every `ExecutionPlan.delegates[]` entry has a non-null `processed` field — catching this, and potentially the sibling `compile_specs` null-key/value issues found in this same investigation, in one centralized pass rather than at each individual accessor deep in `BackendDelegate::Init()`'s call chain.

A regression test should build a `.pte` with one `BackendDelegate` entry (`id` matching a registered fake backend) that omits the `processed` field, asserting `Method::load()` returns a clean `Error::InvalidProgram` rather than crashing.

## Files Included in This Report

- `poc/poc_backend_delegate_processed_null.pte` — the 248-byte PoC file (sha256 `0377b7f4078dda503e5f2ae3e8b69f8332081f065964a45098fb0d95bba4b36`)
- `poc/harness_execute_fuzzer.cpp` — the harness used to trigger and reproduce the crash, including fake backend registration for exercising `BackendDelegate::Init()`

## huntr Submission Note

Per the huntr MFV program's submission requirements, this PoC needs to be uploaded to a public HuggingFace repository before filing. `poc/poc_backend_delegate_processed_null.pte` is ready for that upload.