CVE-2026-129490 in littlefs
Summary
by MITRE • 11/15/2026
littlefs through 2.11.3, when built with LFS_MIGRATE, contains a type confusion vulnerability in lfs_dir_traverse() that treats a stack lfs_diskoff struct as an lfs_attr array. Attackers can supply a crafted littlefs v1 image whose metadata is read as LFS_FROM_USERATTRS during migration, causing out-of-bounds stack reads and process crashes.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/15/2026
The vulnerability identified in the Little File System library versions up to 2.11.3 represents a critical type confusion flaw located within the lfs_dir_traverse function when the LFS_MIGRATE configuration option is enabled. This specific code path is responsible for traversing directory structures and handling metadata during filesystem migration processes, which are essential for upgrading or converting Little File System images between different versions or formats. The core technical defect arises from an incorrect assumption regarding data types within the stack memory allocation logic. Specifically, the function erroneously treats a local variable of type lfs_diskoff as if it were an array of lfs_attr structures. This misinterpretation occurs because the compiler and runtime environment do not perform strict type checking on pointer casts or structural interpretations in this context, allowing the code to proceed with operations that assume the memory layout matches that of attribute arrays rather than simple disk offsets.
The operational impact of this vulnerability is severe when an attacker supplies a crafted Little File System version 1 image designed to exploit this logic error. During the migration process triggered by LFS_MIGRATE, the system reads metadata from the provided filesystem image and interprets it as user attributes (LFS_FROM_USERATTRS). Because the code expects attribute structures but encounters data structured for disk offsets due to the crafted input, it performs out-of-bounds stack reads. These unauthorized memory accesses can lead to immediate process crashes, resulting in a denial of service condition. In more complex scenarios where the attacker has control over the content being read into adjacent stack variables or return addresses, this type confusion could potentially be leveraged for arbitrary code execution, although the primary documented impact is stability failure through crash conditions.
From a classification perspective, this vulnerability aligns with CWE-843, which covers access of incorrect memory location via pointer cast errors, and specifically relates to CWE-120, buffer over-read vulnerabilities where data is read beyond allocated boundaries due to improper type handling. In the context of the MITRE ATT&CK framework, this flaw facilitates reconnaissance or disruption tactics by allowing an adversary to crash embedded systems that rely on LittleFS for persistent storage management. The vulnerability highlights a common risk in low-level system programming where manual memory management and pointer arithmetic are used without sufficient validation mechanisms to ensure type safety during data migration operations.
Mitigation strategies must focus primarily on updating the underlying library to version 2.11.4 or later, where this specific logic error has been corrected by developers through stricter type checking and proper handling of disk offset structures versus attribute arrays. For systems that cannot immediately update due to dependency constraints, disabling the LFS_MIGRATE feature if migration is not actively required can serve as a temporary workaround to prevent exploitation of this code path. Additionally, implementing input validation mechanisms for filesystem images before initiating any migration or mount operations can help detect malformed metadata structures early in the process. Security audits should also review other areas of embedded file system implementations that perform similar type conversions on untrusted data sources to ensure no analogous vulnerabilities exist elsewhere in the stack.