Upload 23-executorch-freecall-oob.md with huggingface_hub

23-executorch-freecall-oob.md

@@ -0,0 +1,156 @@
+# Out-of-Bounds Array Access via Unvalidated FreeCall and MoveCall Indices in ExecuTorch PTE Loading
+
+## Target
+pytorch/executorch
+
+## Vulnerability Type
+Out-of-Bounds Read/Write (CWE-125, CWE-787)
+
+## Severity
+**HIGH** (CVSS 3.1: 8.6 -- AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
+
+A crafted .pte model file can contain FreeCall or MoveCall instructions with attacker-controlled indices that are never validated, causing out-of-bounds access on the runtime values array during program execution.
+
+## Summary
+
+During ExecuTorch method initialization (`Method::init()`), each instruction in the program is validated at load time. KernelCall, DelegateCall, and JumpFalseCall instructions all have their index fields bounds-checked against the values array. However, FreeCall and MoveCall instructions fall through to the `default` case in the init switch statement, which performs **no validation at all**. At execution time, FreeCall directly indexes `values_[]` without bounds checking, and MoveCall passes its indices to `get_value()`/`mutable_value()` which use `ET_CHECK_MSG` (an assertion that aborts the process on debug builds but may be compiled out in release builds).
+
+## Root Cause
+
+### File: `runtime/executor/method.cpp`, lines 1063-1065 (init-time)
+
+During `Method::init()`, the instruction setup loop validates indices for KernelCall (line 997-1027), DelegateCall (line 1028-1047), and JumpFalseCall (line 1048-1062). But MoveCall and FreeCall are handled by:
+
+```cpp
+          default: {
+            chain_instruction_arg_lists[instr_idx] = InstructionArgs();
+          } break;
+```
+
+No validation of the indices (`move_from`, `move_to`, `value_index`) is performed.
+
+### File: `runtime/executor/method.cpp`, line 1504 (execution-time, FreeCall)
+
+```cpp
+    case executorch_flatbuffer::InstructionArguments::FreeCall: {
+      auto free_call = instruction->instr_args_as_FreeCall();
+      auto t = values_[free_call->value_index()].toTensor();
+      internal::reset_data_ptr(t);
+    } break;
+```
+
+`values_[free_call->value_index()]` directly indexes the `values_` array using an attacker-controlled `value_index` from the FlatBuffer with **no bounds check**. If `value_index` exceeds `n_value_`, this reads out-of-bounds heap memory, interprets it as an EValue, calls `.toTensor()` on it (type confusion), and then calls `reset_data_ptr()` which writes to whatever the corrupted Tensor pointer points to.
+
+### File: `runtime/executor/method.cpp`, line 1495 (execution-time, MoveCall)
+
+```cpp
+    case executorch_flatbuffer::InstructionArguments::MoveCall: {
+      auto move_call = instruction->instr_args_as_MoveCall();
+      mutable_value(move_call->move_to()) = get_value(move_call->move_from());
+    } break;
+```
+
+`mutable_value()` and `get_value()` do have `ET_CHECK_MSG` assertions, but these are:
+1. Not present in production/release builds when `ET_CHECK_MSG` is compiled as a no-op
+2. Even when present, they call `abort()` rather than returning an error, causing a denial-of-service
+
+### Contrast with properly validated instructions
+
+JumpFalseCall is properly validated at init time (lines 1048-1062):
+```cpp
+          case executorch_flatbuffer::InstructionArguments::JumpFalseCall: {
+            auto index = ...->cond_value_index();
+            ET_CHECK_OR_RETURN_ERROR(
+                index >= 0 && static_cast<size_t>(index) < n_value_,
+                InvalidProgram,
+                "Index %zd negative or >= %" ET_PRIsize_t,
+                static_cast<ssize_t>(index),
+                n_value_);
+```
+
+Neither FreeCall's `value_index` nor MoveCall's `move_from`/`move_to` receive equivalent validation.
+
+### Validation gap in program_validation.cpp
+
+The `validate_program()` function in `runtime/executor/program_validation.cpp` validates Tensor values and TensorList indices, but does NOT validate any instruction indices (FreeCall, MoveCall, KernelCall op_index, DelegateCall delegate_index, etc.). The init-time validation in `method.cpp` is the only line of defense, and it has this gap for FreeCall and MoveCall.
+
+## Exploitation Flow
+
+1. **Attacker crafts a .pte file** containing a FreeCall instruction with `value_index` set to a large value (e.g., 0xFFFFFFFF or any value >= the values array size).
+
+2. **The program loads successfully** -- FreeCall indices are never checked during init.
+
+3. **During execution**, `values_[free_call->value_index()]` reads out of bounds:
+   - The read accesses heap memory beyond the `values_` array
+   - The bytes are reinterpreted as an `EValue` struct
+   - `.toTensor()` extracts a `TensorImpl*` pointer from the corrupted EValue
+   - `reset_data_ptr()` writes to the address pointed to by the corrupted TensorImpl's `data_` pointer
+
+4. **Result**: An attacker who controls both the PTE file and can predict/influence heap layout achieves arbitrary memory write. Even without heap control, this is a reliable crash (denial of service).
+
+### MoveCall variant
+
+A MoveCall with `move_to` set to a large value would:
+- In debug builds: trigger `ET_CHECK_MSG` -> `abort()` (DoS)
+- In release builds (if ET_CHECK_MSG is compiled out): write an EValue to an out-of-bounds location in the values array -> heap corruption
+
+## Impact
+
+- **Heap Out-of-Bounds Read**: Reading arbitrary heap memory via crafted FreeCall/MoveCall indices
+- **Heap Corruption / Arbitrary Write**: Writing to attacker-influenced memory locations
+- **Denial of Service**: Process abort via assertion failure or segfault
+- **Particularly dangerous on embedded targets**: ExecuTorch runs on mobile/embedded devices with limited memory protections
+
+## Affected Code Path
+
+```
+Program::load() -> Method::load() -> Method::init()
+  -> [instruction loop, default case -- NO VALIDATION for FreeCall/MoveCall]
+
+Method::execute() -> Method::step() -> Method::execute_instruction()
+  -> FreeCall: values_[free_call->value_index()] -- OUT-OF-BOUNDS
+  -> MoveCall: mutable_value(move_call->move_to()) -- ASSERT-ONLY CHECK
+```
+
+## Remediation
+
+Add init-time bounds validation for FreeCall and MoveCall, matching the pattern used for JumpFalseCall:
+
+```cpp
+case executorch_flatbuffer::InstructionArguments::FreeCall: {
+    auto index = static_cast<const executorch_flatbuffer::FreeCall*>(
+        instr_args)->value_index();
+    ET_CHECK_OR_RETURN_ERROR(
+        index >= 0 && static_cast<size_t>(index) < n_value_,
+        InvalidProgram,
+        "FreeCall value_index %d out of range",
+        index);
+    chain_instruction_arg_lists[instr_idx] = InstructionArgs();
+} break;
+
+case executorch_flatbuffer::InstructionArguments::MoveCall: {
+    auto mc = static_cast<const executorch_flatbuffer::MoveCall*>(instr_args);
+    ET_CHECK_OR_RETURN_ERROR(
+        mc->move_from() >= 0 && static_cast<size_t>(mc->move_from()) < n_value_ &&
+        mc->move_to() >= 0 && static_cast<size_t>(mc->move_to()) < n_value_,
+        InvalidProgram,
+        "MoveCall indices out of range");
+    chain_instruction_arg_lists[instr_idx] = InstructionArgs();
+} break;
+```
+
+Additionally, add a runtime bounds check at the FreeCall execution site (line 1504) as defense-in-depth:
+```cpp
+ET_CHECK_OR_RETURN_ERROR(
+    static_cast<size_t>(free_call->value_index()) < n_value_,
+    Internal,
+    "FreeCall value_index out of bounds");
+```
+
+## References
+
+- `runtime/executor/method.cpp:1063-1065` -- Missing init-time validation (default case)
+- `runtime/executor/method.cpp:1504` -- FreeCall unchecked array access
+- `runtime/executor/method.cpp:1495` -- MoveCall assert-only check
+- `runtime/executor/method.cpp:1048-1062` -- JumpFalseCall proper validation (for comparison)
+- `runtime/executor/program_validation.cpp` -- No instruction index validation