Race condition leads to files in a wrong directory

[sschneideribs]

Greetings,

We are using ThreadX in combination with FileX, and we are making FileX calls from multiple threads, as FileX is advertised as being thread-safe when used with ThreadX. Recently, we encountered an issue where a call to fx_file_create created a file in the root directory instead of the specified subdirectory, even though the subdirectory did exist.

After an extensive debugging session, we discovered that a race condition between threads was overwriting the path name, leading to the behavior described. Here's how the issue can be reproduced:

1. Create a subdirectory, for example: /Alarms/
2. Create a file within that subdirectory: /Alarms/0001_alarm.json
3. While fx_file_create is searching for an existing file name inside _fx_directory_search, call another FileX function that modifies the media directory name, such as fx_directory_local_path_set.
4. As a result, the file 0001_alarm.json ends up being created in the root directory instead of /Alarms/.

The race condition is easier to trigger when many files exist in the same directory, since the search takes longer, increasing the likelihood of the conflict. The root of the problem appears to be that FX_PROTECT is called too late. It needs to be invoked at the very beginning—before the media directory entry name is nulled.

I have observed that several other functions may be susceptible to the same behavior. As a temporary workaround, we have wrapped all FileX function calls that are not properly protected with an additional mutex.

Some additional information: Our logic is functioning correctly—there is no issue in the application code. Additionally, FileX does not return any errors, as we are very meticulous in checking return values. The described behavior only occurs when specific timing conditions between different threads are met.

[fdesbiens]

Thank you for reporting this issue, @sschneideribs

@eclipse-threadx/iot-threadx-committers and @eclipse-threadx/iot-threadx-contributors: Please review and provide feedback.

[sschneideribs]

@fdesbiens Any Updates on this topic?

[fdesbiens]

Hi @sschneideribs. We discussed the issue, and this requires investigation and, probably, fixing.

However, right now, our focus is on several potential vulnerability reports we received in the last few weeks. Fixing those takes priority. We are a small team, so I am unsure when we'll be able to tackle this specific issue.

[billlamiework]

Thank you for providing this information. What is interesting about this issue is that the FileX API utilizes an internal mutex to protect itself from multiple-thread access. Can you verify that the mutex is being acquired correctly when you create the file in question? You would need to step into the fx_file_create API and see if the tx_mutex_get call is actually obtaining the mutex. In theory, any other attempted access from another thread would block until the mutex is released. In theory...

[IlkkaHokkanen]

Struggling with same/similar issue and implementation in _fx_directory_local_path_set() looks suspicious.

There seems to be usage of "media_ptr -> fx_media_name_buffer" which is not protected and the function is not re-entrant.

/* Setup pointer to a name buffer.  */
    dir_entry.fx_dir_entry_name =  media_ptr -> fx_media_name_buffer + FX_MAX_LONG_NAME_LEN;

For me it seems there should be FX_PROTECT before using "fx_media_name_buffer"?

[sschneideribs]

@billlamiework The mutex works as expected but it is called too late.

@IlkkaHokkanen You are right, this call needs to be proteced by the FileX mutex, which is not the case. Therefore wrapping all function calls and protect them with an own mutex seems to be the only solution for us right now.

[billlamiework]

Yes, I see what you are talking about now. A good approach is to move the FX_PROTECT call earlier in the function, so the global data is under protection. Please go ahead an move it on your side and we will get this fixed in the official release in parallel. Sorry for the hassle.

From: Sebastian Schneider @.> Sent: Friday, October 17, 2025 11:25 AM To: eclipse-threadx/filex @.> Cc: Bill Lamie @.>; Mention @.> Subject: Re: [eclipse-threadx/filex] Race condition leads to files in a wrong directory (Issue #69)

[https://avatars.githubusercontent.com/u/174452112?s=20&v=4]sschneideribs left a comment (eclipse-threadx/filex#69)https://github.com/eclipse-threadx/filex/issues/69#issuecomment-3416631407

@billlamieworkhttps://github.com/billlamiework The mutex works as expected but it is called too late.

@IlkkaHokkanenhttps://github.com/IlkkaHokkanen You are right, this call needs to be proteced by the FileX mutex, which is not the case. Therefore wrapping all function calls and protect them with an own mutex seems to be the only solution for us right now.

— Reply to this email directly, view it on GitHubhttps://github.com/eclipse-threadx/filex/issues/69#issuecomment-3416631407, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BDUEV3BWKBOWDPM2CCVU2K33YEYA3AVCNFSM6AAAAAB4QRTXBOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMJWGYZTCNBQG4. You are receiving this because you were mentioned.Message ID: @.@.>>