None
A buffer overflow vulnerability exists in the FileX RAM disk driver functionality of Eclipse ThreadX FileX git commit 1b85eb2. A specially crafted set of network packets can lead to code execution. An attacker can send a sequence of requests to trigger this vulnerability.
The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.
Eclipse ThreadX FileX git commit 1b85eb2
Eclipse ThreadX FileX - https://github.com/eclipse-threadx/filex
8.5 - CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buffer
FileX is a high-performance, FAT-compatible file system is seamlessly integrated with the Eclipse ThreadX RTOS and is available for all supported processors. Similar to Eclipse ThreadX RTOS, FileX is designed to be compact and efficient, making it perfect for modern deeply embedded applications that need file management capabilities. FileX supports a variety of physical media, including RAM, Eclipse ThreadX USBX, SD CARD, and NAND/NOR flash memories through Eclipse ThreadX LevelX.
The NetXDuo http server sample implementation is used to demonstrate this vulnerability. However, this vulnerability affects any application using the RAM disk driver with a vulnerable configuration. The initial values for configuring the RAM disk driver are copied from that sample code provided in the NetXDuo repository https://github.com/eclipse-threadx/netxduo/blob/master/samples/demo_netxduo_https.c.
The RAM disk driver is initialized during application start up with a call to the function fx_media_format. Below is an example of this initialization:
fx_media_format(&ram_disk,
_fx_ram_driver, // Driver entry
demo.ram_disk_memory, // RAM disk memory pointer /*[1] size 4096*/
media_memory, // Media buffer pointer
sizeof(media_memory), // Media buffer size
"MY_RAM_DISK", // Volume Name
1, // Number of FATs
32, // Directory Entries
0, // Hidden sectors
256, // Total sectors /*[2]*/
512, // Sector size /*[3]*/
8, // Sectors per cluster
1, // Heads
1); // Sectors per track
The Total sectors ([2]) multiplied by Sector size ([3]) equals 131,072 which is much larger than 4096 bytes allocated for the size of the RAM disk memory pointer at [1]. There are no checks performed to ensure that the RAM disk driver is configured properly, which leads to the vulnerability described below.
When receiving a PUT request, the NetXDuo http server implementation will create and write the specified file and it’s contents to the filesystem using the FileX API fx_file_write.
File: nx_web_http_server.c
4213: VOID _nx_web_http_server_put_process(NX_WEB_HTTP_SERVER *server_ptr, NX_PACKET *packet_ptr)
4214: {
...
4481: /* Write the content found in this packet. */
4482: status = fx_file_write(&(server_ptr -> nx_web_http_server_file), (packet_ptr -> nx_packet_prepend_ptr + offset),
4483: ((ULONG)(packet_ptr -> nx_packet_append_ptr - packet_ptr -> nx_packet_prepend_ptr) - offset));
After a series of intermediate functions, the RAM disk driver function _fx_ram_driver is called with a WRITE request, which corresponds to the switch case below.
File: fx_ram_driver.c
224: case FX_DRIVER_WRITE:
225: {
226:
227: /* Calculate the RAM disk sector offset. Note the RAM disk memory is pointed to by
228: the fx_media_driver_info pointer, which is supplied by the application in the
229: call to fx_media_open. */
230: destination_buffer = ((UCHAR *)media_ptr -> fx_media_driver_info) + /*[4]*/
231: ((media_ptr -> fx_media_driver_logical_sector +
232: media_ptr -> fx_media_hidden_sectors) *
233: media_ptr -> fx_media_bytes_per_sector);
234:
235: /* Copy the source to the RAM sector. */
236: _fx_utility_memory_copy(media_ptr -> fx_media_driver_buffer, destination_buffer, /*[5]*/
237: media_ptr -> fx_media_driver_sectors *
238: media_ptr -> fx_media_bytes_per_sector);
239:
240: /* Successful driver request. */
241: media_ptr -> fx_media_driver_status = FX_SUCCESS;
242: break;
243: }
At [4] a pointer to the memory location that should be written to is calculated. The pointer media_ptr -> fx_media_driver_info points to the buffer corresponding to the RAM disk which was provided when the application was initialized at [1]. The value for media_ptr -> fx_media_driver_logical_sector will be incremented until the value provided in the initialization [2]. The value for media_ptr -> fx_media_bytes_per_sector is the Sector size provided during initialization at [3]. The issue is that there is no validation performed to ensure that the calculation above at [4] will not result in the pointer destination_buffer pointing outside the bounds of the provided RAM disk buffer.
As you can see below, the function fx_utility_memory_copy at [5] is simply a wrapper for the libc memcpy function. The result is that user supplied data via an HTTP PUT request will overflow the RAM disk buffer. This buffer overflow could overwrite a function pointer in another object leading to code execution.
File: fx_utility_memory_copy.c
82: VOID _fx_utility_memory_copy(UCHAR *source_ptr, UCHAR *dest_ptr, ULONG size)
83: {
84:
85: /* Copy the memory. */
86: memcpy(dest_ptr, source_ptr, size); /* Use case of memcpy is verified. */
87: }
Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()
(gdb) i r
eax 0x5657c000 1448591360
ecx 0x1a 26
edx 0xffffd0f2 -12046
ebx 0x5657c000 1448591360
esp 0xffffd0dc 0xffffd0dc
ebp 0xffffd118 0xffffd118
esi 0x1 1
edi 0x5657c428 1448592424
eip 0x41414141 0x41414141
eflags 0x10287 [ CF PF SF IF RF ]
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x63 99
k0 0x0 0
k1 0x0 0
k2 0x0 0
k3 0x0 0
k4 0x0 0
k5 0x0 0
k6 0x0 0
k7 0x0 0
(gdb) bt
#0 0x41414141 in ?? ()
#1 0x5657667a in server_request_callback (server_ptr=0x5657c428 <my_server>, request_type=1,
resource=0x5657c434 <my_server+12> "/test.txt", packet_ptr=0x565881a0)
at nx_web_http_server/ramdisk_driver_overflow/http_server_app.c:122
#2 0x56570364 in _nx_web_http_server_get_process (server_ptr=0x5657c428 <my_server>, request_type=1,
packet_ptr=0x565881a0) at netxduo/addons/web/nx_web_http_server.c:3892
#3 0x5656e10d in _nx_web_http_server_receive_data (tcpserver_ptr=0x5657c660 <my_server+568>,
session_ptr=0xffffd2a0) at netxduo/addons/web/nx_web_http_server.c:3242
#4 0x5655a188 in _nx_tcpserver_start (server_ptr=0x5657c660 <my_server+568>, port=8080, listen_queue_size=4)
at nx_tcp_shims.c:970
#5 0x5656edc2 in _nx_web_http_server_start (http_server_ptr=0x5657c428 <my_server>)
at netxduo/addons/web/nx_web_http_server.c:2087
#6 0x5656ed6c in _nxe_web_http_server_start (http_server_ptr=0x5657c428 <my_server>)
at netxduo/addons/web/nx_web_http_server.c:2029
#7 0x565765cc in https_server_thread_entry (thread_input=0)
at nx_web_http_server/ramdisk_driver_overflow/http_server_app.c:235
#8 0x5655a533 in _txe_thread_create (thread_ptr=0x5657cd28 <server_thread>,
name_ptr=0x565772f2 "HTTP Server thread", entry_function=0x565761c0 <https_server_thread_entry>,
entry_input=0, stack_start=0x5658cca0, stack_size=4096, priority=4, preempt_threshold=4, time_slice=0,
auto_start=1, thread_control_block_size=212) at tx_shims.c:146
#9 0x565761aa in tx_application_define (first_unused_memory=0x565881a0)
at nx_web_http_server/ramdisk_driver_overflow/http_server_app.c:103
#10 0x5655a4aa in _tx_initialize_kernel_enter () at tx_shims.c:75
#11 0x56576096 in main () at nx_web_http_server/ramdisk_driver_overflow/http_server_app.c:52
(gdb)
Developers should ensure that the provided values for total sectors multiplied by sector size are less than the size of the buffer provided for the ram disk memory when initializing the ramdisk with the call to fx_media_format. In reference to the call above fx_media_format ensure that [2]*[3] < sizeof([1]).
2024-10-31 - Initial Vendor Contact
2024-10-31 - Vendor Disclosure
2025-07-28 - Vendor Patch Release
2025-07-30 - Public Release
Discovered by Kelly Patterson of Cisco Talos.