Skip to content

TEST_RESULTS.md

Latest commit

 

History

History
68 lines (49 loc) · 3 KB

TEST_RESULTS.md

File metadata and controls

68 lines (49 loc) · 3 KB

Patch Test Results

Test Environment

  • Test Date: 2025-10-28
  • dmffs Version: Latest from repository
  • dmod Version: From dmvfs dependency
  • Test Platform: fs_tester from dmvfs

Patches Tested

Patch 1: Basic Safety Checks

File: src/system/public/dmod_dmf_api.c Changes:

  • Added validation for API counts (< 1000)
  • Added NULL pointer checks for API sections
  • Added NULL check for signature pointers

Result: ❌ FAILED - Crash still occurs

Analysis: Safety checks passed but crash happened anyway. The issue is more fundamental - accessing Entries[j] structure itself causes the crash, not reading the Signature field.

Patch 2: Pointer Range Validation

File: src/system/public/dmod_dmf_api.c Changes:

  • Added pointer address range validation (0x1000 - 0x7FFFFFFFFFFF)
  • Skips entries with suspicious pointers

Result: ❌ FAILED - Crash still occurs before range check

Analysis: The crash happens when accessing InputsApi->InputSection->Entries[j] itself, before we can read the .Signature field.

Root Cause Analysis

The crash is NOT in the comparison logic but in how the Entries array is accessed. The issue appears to be:

  1. Array bounds corruption: The numberOfInputs reports 61 entries, but the actual allocated array might be smaller
  2. Memory layout issue: In complex multi-module environments (dmvfs + dmfsi + dmffs), the API entries array memory layout may be incorrect
  3. Uninitialized memory: The Entries array pointer might be pointing to partially initialized or corrupt memory

Evidence

[VERBOSE] Connected: DMOD_IsFunctionConnected@Dmod:1.0 0x0040A5D5
[VERBOSE] Connected: DMOD_Printf@Dmod:1.0 0x0040B187
[VERBOSE] Connected: DMOD_GetEnv@Dmod:1.0 0x0040BB5F
[VERBOSE] Connected: DMOD_ReadMemory@Dmod:1.0 0x0040AF59
[VERBOSE] Connected: DMOD_Free@Dmod:1.0 0x0040AD6D
[VERBOSE] Connected: DMOD_Malloc@Dmod:1.0 0x0040AC43
<< SEGFAULT >>

Successfully connects 6 APIs, crashes on ~7th iteration when j reaches a certain index while iterating through 61 input entries.

Recommended Next Steps

  1. Investigate Dmod_Api_GetNumberOfEntries(): Check if this function correctly calculates the number of entries based on section size
  2. Check memory allocation: Verify that the Entries array is properly allocated for all 61 entries
  3. Add array bounds checking: Before accessing Entries[j], verify that j * sizeof(Entry) < SectionSize
  4. Review module loading: Check if API sections are properly initialized during module loading in multi-module scenarios

Conclusion

The provided patches add defensive checks but do not fix the underlying issue. The problem requires deeper investigation into:

  • How API entry counts are calculated
  • How the Entries array is allocated and initialized
  • Why it works in simple environments (dmod_loader) but fails in complex ones (dmvfs)

The issue is in dmod's API management, specifically in how it handles API entries when multiple modules are loaded simultaneously.