You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I ran into an issue while working on a binding from LFS <-> BLE for the Infinitime Firmware for the PineTime smart watch where in release builds my file variables were not getting Zeroed on instantiation. When I close the file opened with a bad *next pointer it caused LFS to behave weird causing crashes, OOB accesses and infinite loops.
The quick and simple fix was to make sure my lfs_file_t variables are zero initialized.
I wonder if LFS should be ensuring that the *next pointer points to a valid value in lfs_file_open, instead of doing nothing with it as it currently seems to do.
Some more technical information.
Opening the file seems to work properly, It can be read/written to just fine. Until I call close.
Inside close lfs_dir_commit gets called with the file handle, which then walked *next and proceeds to crash.
The text was updated successfully, but these errors were encountered:
Hi @geekbozu, thanks for pointing this out. You certainly shouldn't need to zero-initialize the lfs_file_t struct, so it sounds like this is a bug in littlefs.
Given that lfs_file_open always assigns the next point, I'm not sure how this could happen unless the mlist pointer in the lfs_t struct was already corrupted. Did you have any functions return errors before this crash happens?
I ran into an issue while working on a binding from LFS <-> BLE for the Infinitime Firmware for the PineTime smart watch where in release builds my file variables were not getting Zeroed on instantiation. When I close the file opened with a bad *next pointer it caused LFS to behave weird causing crashes, OOB accesses and infinite loops.
The quick and simple fix was to make sure my lfs_file_t variables are zero initialized.
I wonder if LFS should be ensuring that the *next pointer points to a valid value in lfs_file_open, instead of doing nothing with it as it currently seems to do.
Some more technical information.
Opening the file seems to work properly, It can be read/written to just fine. Until I call close.
Inside close lfs_dir_commit gets called with the file handle, which then walked *next and proceeds to crash.
The text was updated successfully, but these errors were encountered: