---
id: "CVE-2026-91041"
kind: "vulnerability"
aliases: ["CVE-2026-91041"]
title: "FAT filesystem log replay heap overflow gives instruction pointer control"
severity: "high"
cvss: 7.8
epss: null
exploited: false
status: "resolved"
category: "infrastructure"
products: [{"name": "filex", "fixed": ["6.5.2.202603"], "affected": "<= 6.5.1.202602", "ecosystem": "vendor"}]
ecosystems: []
tags: ["eclipse-threadx", "embedded", "fat", "filesystem", "filex", "fx-media", "infrastructure", "removable-media", "rtos", "threadx"]
not_affected_if: ["fault-tolerance-not-enabled", "no-fault-tolerant", "trusted-media-only"]
published_at: "2026-10-20T14:17:04+00:00"
first_seen_at: "2026-10-23T21:57:20+00:00"
updated_at: "2026-10-25T03:31:23+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-91041", "first_seen_at": "2026-10-23T21:57:20+00:00"}, {"source": "analyst", "url": null, "first_seen_at": "2026-10-25T03:31:23+00:00"}]
---

# FAT filesystem log replay heap overflow gives instruction pointer control

FileX fault-tolerant log replay (_fx_fault_tolerant_apply_logs) bounds the on-disk offset and size against the whole sector cache instead of one sector. A crafted FAT image therefore gets an out-of-bounds write that can overwrite the fx_media_driver_entry callback, which is called on the next line. On targets without an MMU, ASLR or W^X this gives code execution. A second, lesser bug is an out-of-bounds read of total_size when the log loads. Fixed in 6.5.2.202603.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- vendor:filex affected <= 6.5.1.202602 fixed 6.5.2.202603

## How to check

You are exposed if your firmware links FileX <= 6.5.1.202602 (check the FileX version string or your vendored source), is built with FX_ENABLE_FAULT_TOLERANT, and calls fx_fault_tolerant_enable() at runtime. Without either of those, no log is replayed and you are not affected.

## Fix

Upgrade FileX (Eclipse ThreadX) to 6.5.2.202603 or later. The fix bounds the log copy against fx_media_bytes_per_sector and validates total_size before the checksum path. Workaround: build without FX_ENABLE_FAULT_TOLERANT, or do not call fx_fault_tolerant_enable(), on products that mount media they do not control.

## Timeline

- 2026-10-23T21:57:20+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-91041
- 2026-10-25T03:31:23+00:00 analyst — Read maintainer advisory GHSA-c8cj-fj9j-426v and v6.5.2.202603 release notes: affects FileX <=6.5.1.202602 (release notes: 6.0.1 onward), fixed 6.5.2.202603. No exploitation or public PoC found (VulDB says none); no social search run.

## Documents

- [advisory] FileX GHSA-c8cj-fj9j-426v https://github.com/eclipse-threadx/filex/security/advisories/GHSA-c8cj-fj9j-426v
- [fix] FileX v6.5.2.202603 release notes https://newreleases.io/project/github/eclipse-threadx/filex/release/v6.5.2.202603_rel

## From the sources

Mounting an attacker-controlled FAT image with fault tolerance enabled causes an out-of-bounds heap write during log replay. The write is attacker-positioned and attacker-valued, and on a common embedded memory layout it reaches the FX_MEDIA driver callback, giving control of the instruction pointer.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_